Hi Martin, On Thu, Oct 15, 2020 at 11:56:05AM +0200, Martin Rex wrote: > The IESG <iesg-secret...@ietf.org> wrote: > > > > The IESG has received a request from the Transport Layer Security WG (tls) > > to > > consider the following document: - 'Deprecating MD5 and SHA-1 signature > > hashes in TLS 1.2' > > > > <draft-ietf-tls-md5-sha1-deprecate-04.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > comments on this action. Please send substantive comments to the > > last-c...@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may > > be sent to i...@ietf.org instead. In either case, please retain the > > beginning > > of the Subject line to allow automated sorting. > > > The new, backwards-incompatible and interop-fatal behaviour proposed in
"Backwards-incompatible" I can see, but "interop-fatal" seems yet to be proven... > section 2 of the current draft must be changed to reflect the updated > rationale from section 6 of the very same document, and to promote > safe and secure interoperability instead of a needless total interop failure. > > Requesting interop failure where instead safe and secure interop can > be easily obtained, as the current draft does, would be in serious > violation of section 6 of RFC 2119 about where an imperative MUST > is not allowed for the given situation. > > > > Section 6 of the current draft says: > > 6. Updates to RFC5246 > > [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2, > suggests that implementations can assume support for MD5 and SHA-1 by > their peer. This update changes the suggestion to assume support for > SHA-256 instead, due to MD5 and SHA-1 being deprecated. > > In Section 7.4.1.4.1: the text should be revised from: > > OLD: > > "Note: this is a change from TLS 1.1 where there are no explicit > rules, but as a practical matter one can assume that the peer > supports MD5 and SHA- 1." > > NEW: > > "Note: This is a change from TLS 1.1 where there are no explicit > rules, but as a practical matter one can assume that the peer > supports SHA-256." > > > and therefore the behaviour in section 2 about the "Signature Algorithms" > extension ought to say: > > 2. Signature Algorithms > > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms > extension. If a client does not send a signature_algorithms > extension, then the server MUST use (sha256,rsa) for > digitally_signed on the ServerKeyExchange handshake message for > TLS cipher suites using RSA authentication, and the server MUST use > (sha256,ecdsa) for TLS cipher suites using ECDSA authentication. ... since your propsal here seems to be resulting in TLS servers prior-to-this-RFC and TLS servers implementing this RFC using a different interpretation for what the absence of a "signature_algorithms" extension means. That itself, seems like a recipe for interoperability failure, absent some comprehensive case-by-case analysis showing that it is safe. I, for one, will not support publication of a document including your proposed change in the absence of such an analysis. Furthermore, there is perhaps some awkward interaction between the way this document refers to the contents of the "signature_algorithms" extensions and the changes to that extension (and the corresponding IANA registry) made by RFC 8446. In the current state of the registry, there is not a separate 'hash algorithm' field, and instead we must deal with combined SignatureScheme codepoints. One might argue that this document should specifically enumerate the 16-bit SignatureScheme codepoints that are prohibited. (The SignatureScheme formulation also allows signature types other than RSA and ECDSA, of course.) > The server behaviour ought to be consistent for both, receipt of an > extension-less SSLv3+ ClientHello handshake message, and for a > backwards-compatible SSL VERSION 2 CLIENT-HELLO (which can not convey > any TLS extensions) as described in Appendix-E.2 of rfc5246, > and as permitted in bullet 2 in section 3 of RFC6176. I note that we prohibited SSLv2-compatible ClientHello for TLS 1.3 implementations. If we are to assume the current formulation of the draft where absence of the "signature_algorithms" extension continues to imply inferred support for SHA-1 and MD5, which are now forbidden, then it is a natural consequence that the SSLv2-compatible ClientHello cannot successfully negotiate a handshake, and is de facto forbidden. I am not entirely sure why you feel there is a need in the ecosystem to continue to support the SSLv2-compatible ClientHello; do you, perhaps, know of some implementation that cannot generate an SSLv3/TLS ClientHello but would otherwise interoperate (using your formulation where no "signature_algorithms" means inferred SHA-256 support) with a server that adheres to this draft's strictures? > > > As desribed in RFC6151, collision attacks on MD5 were appearing in > publications already in 2004, 2005, 2006 & 2007, the TLSv1.2 spec > rfc5246 should have never *NEWLY* added support for (md5,rsa) in > TLSv1.2 digitally_signed. > > Similarily, since the sunset date for SHA1-signatures had been > announced by NIST *before* TLSv1.2 (rfc5246) was published, > TLSv1.2 (rfc5246) should have never *NEWLY* added support for > (sha1,rsa) in TLSv1.2 digitally_signed, but have used (sha256,rsa) > from the beginning. sha256 has been required for the TLSv1.2 PRF > and for HMAC-SHA256 of several cipher suites anyway, so there > was no excuse for not using sha256 in TLSv1.2 digitally_signed > in the first place. I've lost count of the number of times that you have mentioned this. Saying it again is not going to change what RFC 5246 says or help us in coping with the fallout of what RFC 5246 says. Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
