I think a good design is to have the client explicitly advertise any algorithms the client is willing/able to support, and for the server to honor the client's capabilities.
IMHO the existing specs already meet the above goal, with an unfortunate quirk that SHA1/MD5-only clients don't have to be explicit about their supported signature/hash combinations. This quirk has caused some confusion, but this should be easy to fix in 1.3 by requiring that all algorithms are advertised. > Which part are you objecting to? The subsequent proposal to suppress > SHA-1 advertisements (if the client supports only TLS 1.3 or later) when even > when the client is willing to accept a SHA-1 chain when all else fails? No, I don't care for SHA1; let's deprecate it ASAP. I do care for a straightforward and deterministic handshake where the client MUST advertise supported algorithms and the server MUST honor the client's capabilities. Having shipped a product that implements the strict interpretation of the current specs (WRT signature_algorithms) for a number of years now, I remember exactly 3 related problem reports. Without pointing fingers (as much as possible), here they are: 1. A version of a popular Web browser failed to interoperate because it did not include all of its supported algorithms in the signature_algorithms extension. Unfortunately, the browser had already been fixed by the time I reported the issue to them, so I could not use this incident as an opportunity to promote IE. :) 2. An open-source TLS stack that had just added TLS1.2 support, but did not implement extensions. I pointed them at the signature_algorithms section of the RFC and they quickly implemented this extension. 3. A vocal participant of this mailing list who seems to be opposed to the idea of making certain TLS extensions MTI, as a matter of principle. My preference would be to keep the client explicitly advertising its capabilities, and the server strictly honoring the client-advertised capabilities. And since the concept of "default algorithms" confuses people, let's just get rid of it in 1.3. Conveniently, most of this WG no longer wants SHA1 or MD5. Why not just make signature_algorithms (even more) clearly and unambiguously MTI in 1.3? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Viktor Dukhovni Sent: Sunday, July 12, 2015 9:41 PM To: tls@ietf.org Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) On Mon, Jul 13, 2015 at 04:11:04AM +0000, Andrei Popov wrote: > I'm not happy with this either. The spec already says: > > "If the client supports only the default hash and signature algorithms > (listed in this section), it MAY omit the signature_algorithms > extension. If the client does not support the default algorithms, or > supports other hash and signature algorithms (and it is willing to > use them for verifying messages sent by the server, i.e., server > certificates and server key exchange), it MUST send the > signature_algorithms extension, listing the algorithms it is willing > to accept." > > This seems to be pretty clear: if the client properly advertises the > algorithms it supports, then the handshake has a deterministic outcome. That's all fine, we're talking about what the server should do when it is certificate chain does not (in its entirety) match those algorithms. And in the context of TLS 1.3 which is not yet set in stone. Which part are you objecting to? The subsequent proposal to suppress SHA-1 advertisements (if the client supports only TLS 1.3 or later) when even when the client is willing to accept a SHA-1 chain when all else fails? That too seems sensible, and it was already noted that clients will need to send the SHA-1 codepoint when willing to accept TLS 1.2, since that spec does not contain the proposed new language for server-side behaviour. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
