On Fri, May 19, 2017 at 09:43:19PM -0400, Dave Garrett wrote: > 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.
This requirement is bad layering violation. It is even further made problematic by: - TLS and PKIX libraries are often decoupled, making this difficult to implement. - It requires code to support MD5, which as weak algorithm is hazardous. I do have written TLS implementation. It does not follow this, because I regard the aborting requirements as insane (it does not have any code to support MD5, and is not architecturally capable of aborting based on signature algorithm). The code treats MD5 as unknown signature algorithm, which does not require hazardous code. Pathbuilding avoids MD5 signatures and it is not possible to validate signatures using MD5 (algorithm conversion will return an error). (The SHA-1 handling is more complex, as RSA-PKCS#1v1.5-SHA1 is actually validateable, but only in certain context. Suffice to say, I would love to just dump the SHA-1 code). > > 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. These are values internal to PKIX. And the draft _does_ allow sending a certificate contaning those (hint: If the server does not have any other chain using only signaled algorithms). And MD5 isn't listed as possible field value either. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
