On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > Which brings us to some more undesirable layer violation in the current > draft. The language in question is appropriate for updates to RFC5280, > but does not belong in TLS. The problems in question are largely > already addressed elsewhere (as CAs no longer issue MD5, SHA1, ... > certificates, browsers no longer support them, ...) and continue to > be further remediated in the appropriate standards and products. > > Therefore delete: > > Section 4.2.3 (Legacy algorithms paragraph final sentence): > > ... TLS 1.3 servers > MUST NOT offer a SHA-1 signed certificate unless no valid > certificate chain can be produced without it (see > Section 4.4.2.2). > > Section 4.4.2.2: > > ... This fallback chain MAY use the deprecated SHA-1 hash > algorithm only if the "signature_algorithms" extension provided by > the client permits it. If the client cannot construct an acceptable > chain using the provided certificates and decides to abort the > handshake, then it MUST abort the handshake with an > "unsupported_certificate" alert. > > Section 4.4.2.4: > > Any endpoint receiving any certificate signed using any signature > algorithm using an MD5 hash MUST abort the handshake with a > "bad_certificate" alert. SHA-1 is deprecated and it is RECOMMENDED > that any endpoint receiving any certificate signed using any > signature algorithm using a SHA-1 hash abort the handshake with a > "bad_certificate" alert. All endpoints are RECOMMENDED to transition > to SHA-256 or better as soon as possible to maintain interoperability > with implementations currently in the process of phasing out SHA-1 > support.
No. I strongly oppose stripping all off this out. > I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES, > MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1 > or even MD5. They're not listed as possible field values anywhere directly in the TLS spec. If someone wants to add a line to one of the "MUST NOT" lists somewhere for all hashes weaker than SHA-1, that sounds fine to me. > Opportunistic unauthenticated TLS ignores the peer certificate and should > not have to fall back to cleartext just because some certificate in the > chain is not sufficiently sexy. There are other legitimate use cases where > the restrictions above are inappropriate. Opportunistic unauthenticated TLS isn't the protocol we're defining here. If your goal isn't authentication, then by all means violate the requirements laid out for authentication. I have no problem making that explicit, if desired, however this is not the primary desired operating mode of TLS. > The reason I am pointing this out is that I just had to waste a bunch of > time convincing the rest of the OpenSSL team to ignore the draft language > in question, and just stick with whatever "security level" (floor on > algorithm strength) the application or default settings requested. This > already excludes MD5 by default, and we'll likely adjust the collision > resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from > the recent Google collision announcement), after which SHA-1 will also > be excluded at security level 1. This will be done in the X.509 ala PKIX > code and not the TLS code, and applications that ignore the chain or do > DANE-EE(3), ... will not be affected. > > I propose that the current draft language is just a landmine for TLS > implementations, that addresses a non-problem (or more precisely a > problem that is more properly and well addressed elsewhere). TLS is already a minefield of problems. Enumerating many of them explicitly is a step forward to avoiding them more easily in the future. In a complex system, just fixing something in one place is not enough. If we list it as a possible option in the spec, we should be _very_ clear when it is crap. I'm aware that this is unavoidably messy. Viktor, your input has greatly helped improve the language here to accommodate varying use-cases, and I would personally prefer we work together to make the mess correct, rather than give up and delete the relevant text. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
