Removing certificate_types and adding certificate_extensions #290
Conversation
| able to verify, listed in descending order of preference. Any | ||
| certificates provided by the client MUST be signed using a | ||
| hash/signature algorithm pair found in | ||
| supported_signature_algorithms. |
There was a problem hiding this comment.
We have relaxed this restriction for the server and made it a strong SHOULD. Should we do the same here?
There was a problem hiding this comment.
I think algorithm negotiation should be definitive, both for the server and the client. What was the reason for relaxing this requirement for the server?
From: ekr [mailto:notifications@github.com]
Sent: Wednesday, October 14, 2015 2:08 PM
To: tlswg/tls13-spec tls13-spec@noreply.github.com
Cc: Andrei Popov Andrei.Popov@microsoft.com
Subject: Re: [tls13-spec] Removing certificate_types and adding certificate_extensions (#290)
In draft-ietf-tls-tls13.mdhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%23discussion_r42053320&data=01%7c01%7candrei.popov%40microsoft.com%7c6cdffca510b641aa0fbb08d2d4db7ba4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fMWN1xfAm7OxSYibpoJTQcTF0L77fS%2fLRRpm0f%2b37n0%3d:
supported_signature_algorithms
: A list of the hash/signature algorithm pairs that the server is
- able to verify, listed in descending order of preference.
- able to verify, listed in descending order of preference. Any
- certificates provided by the client MUST be signed using a
- hash/signature algorithm pair found in
- supported_signature_algorithms.
We have relaxed this restriction for the server and made it a strong SHOULD. Should we do the same here?
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%2ffiles%23r42053320&data=01%7c01%7candrei.popov%40microsoft.com%7c6cdffca510b641aa0fbb08d2d4db7ba4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1HGBdz8tYk6A0R52veLDZKtrs7tmGHCC%2bvtrQNNMWTg%3d.
There was a problem hiding this comment.
The reasoning was that you have some limited number of certificates and that it's better to provide something than fail the handshake.
I don't care much either way, but I wanted to raise it.
There was a problem hiding this comment.
On Wednesday, October 14, 2015 05:13:52 pm Andrei-Popov wrote:
I think algorithm negotiation should be definitive, both for the server and the client. What was the reason for relaxing this requirement for the server?
On Wednesday, October 14, 2015 05:16:36 pm ekr wrote:
The reasoning was that you have some limited number of certificates and that it's better to provide something than fail the handshake.
The goal was to not fail so the client could make the final decision to abort or not, rather than the server, as the server doesn't always have enough information to make that decision properly.
Doing this in the opposite direction as well could make sense, but giving the client the option to abort rather then send its certificates might be useful in other cases.
There was a problem hiding this comment.
I think it was not a good change for the server. The client explicitly indicated lack of support for the algorithms in the server’s certificate(s), and sending unsupported certificate(s) is an attack on the client. Hopefully, the client will prevent this attack, but the protocol should not put a compliant server in the position of an attacker☺.
For client auth, the argument of “let’s not break the handshake” makes even less sense: a client including an empty certificate does not necessarily fail the handshake. The client simply says “I can’t satisfy this CertificateRequest”.
From: Dave Garrett [mailto:notifications@github.com]
Sent: Wednesday, October 14, 2015 2:30 PM
To: tlswg/tls13-spec tls13-spec@noreply.github.com
Cc: Andrei Popov Andrei.Popov@microsoft.com
Subject: Re: [tls13-spec] Removing certificate_types and adding certificate_extensions (#290)
In draft-ietf-tls-tls13.mdhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%23discussion_r42056072&data=01%7c01%7candrei.popov%40microsoft.com%7c90a90bfaead544bc1a5508d2d4dea5ba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bMJNchGUterSW3etN45PpBWn54LBwAYYZ8%2fuS0GmTJY%3d:
supported_signature_algorithms
: A list of the hash/signature algorithm pairs that the server is
- able to verify, listed in descending order of preference.
- able to verify, listed in descending order of preference. Any
- certificates provided by the client MUST be signed using a
- hash/signature algorithm pair found in
- supported_signature_algorithms.
On Wednesday, October 14, 2015 05:13:52 pm Andrei-Popov wrote: > I think algorithm negotiation should be definitive, both for the server and the client. What was the reason for relaxing this requirement for the server? On Wednesday, October 14, 2015 05:16:36 pm ekr wrote: The reasoning was that you have some limited number of certificates and that it's better to provide something than fail the handshake.
The goal was to not fail so the client could make the final decision to abort or not, rather than the server, as the server doesn't always have enough information to make that decision properly. Doing this in the opposite direction as well could make sense, but giving the client the option to abort rather then send its certificates might be useful in other cases.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2ftlswg%2ftls13-spec%2fpull%2f290%2ffiles%23r42056072&data=01%7c01%7candrei.popov%40microsoft.com%7c90a90bfaead544bc1a5508d2d4dea5ba%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=oK%2bBna9j3zDuTHR736SK0JDZw%2bF3%2fDhxrZ%2bcevbfmlo%3d.
There was a problem hiding this comment.
I can live with Andrei's proposed text.
There was a problem hiding this comment.
On Wednesday, October 14, 2015 05:51:07 pm Andrei-Popov wrote:
I think it was not a good change for the server. The client explicitly indicated lack of support for the algorithms in the server’s certificate(s), and sending unsupported certificate(s) is an attack on the client.
It's not an attack if it knows it's a possibility because it's part of the spec. One of the prime reasons to make the change was to handle things like DANE & opportunistic encryption better, as there's no way for the client to sufficiently inform the server of what it supports (if it cares at all). See the mailing list discussions on this topic, as we're getting off-topic now.
There was a problem hiding this comment.
Off-topic? Somewhat true.
Not an attack? I respectfully disagree; will keep thwarting:).
There was a problem hiding this comment.
The current version of TLS includes MUST language here, so I suggest that (pending people raising other concerns in the next few days) we land this PR and then we can have a separate issue about whether to relax this requirement.
Removing certificate_types and adding certificate_extensions
This PR includes CertificateRequest changes discussed at the TLS WG Interim: