> On Jul 28, 2021, at 12:41, Sean Turner <sean@xxxxxxxxx> wrote: > > Daniel, > > Thanks for following up on this (I meant to and dropped the ball). Triminng to the remaining issue. > > spt > >> </mglt> >>>>>>> 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." >>>>>>> >>>>>>> >>>>>>> <mglt> >>>>>>> I am reading the Note as an explanation on >>>>>>> why sha was taken as the default hash >>>>>>> function with the following rules. >>>>>>> >>>>>>> """ >>>>>>> If the client does not send the signature_algorithms extension, the >>>>>>> server MUST do the following: >>>>>>> >>>>>>> - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, >>>>>>> DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had >>>>>>> sent the value {sha1,rsa}. >>>>>>> >>>>>>> - If the negotiated key exchange algorithm is one of (DHE_DSS, >>>>>>> DH_DSS), behave as if the client had sent the value {sha1,dsa}. >>>>>>> >>>>>>> - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, >>>>>>> ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. >>>>>>> """ >>>>>>> >>>>>>> The current document does not update the >>>>>>> default hash function from sha to sha256 to >>>>>>> avoid interoperability issue where one peer >>>>>>> takes sha while the other one takes sha-256. >>>>>> >>>>>> You are right that this section, which is updating TLS1.2 [RFC5246], is not changing the default to SHA-256, but the recommendations for configuring TLS 1.2, which are provided in RFC 7525/BCP 195, is being updated to recommend SHA-256 in the very next section. >>>>>> >>>>> <mglt> >>>>> Updating the update works. It believe that saying a section should be remove is not too hard, and it seems to me that mentioning the default behaviour is important. I would say that could get implementers confused to implement part of the specifications that do not hold any more. I would prefer to have this being addressed. >>>>> >>>>> I am reading RFC7525 as recommending a non default parameter while this document removed the support of default parameters. So to me the updating the status of the default parameters seems more updating the 5246 then 7525. >>>>> </mglt> >>>>> >>>>>>> As a results, these rules and the "Note" may >>>>>>> eventually all together be replaced by your >>>>>>> text of section 2. >>>>>>> >>>>>>> The following text may also be removed: >>>>>>> >>>>>>> """ >>>>>>> If the client supports only the default hash and signature algorithms >>>>>>> (listed in this section), it MAY omit the signature_algorithms >>>>>>> extension. >>>>>>> """ >>>>>> >>>>>> So we might do it, but the question is whether implementers are going to be confused if we don’t do it. I think because s1 already says that client MUST send a signature_algorithms extension that we don’t have to indicate that that particular sentence be dropped/removed from the draft. I will admit this document mixes the two ways to do a bis document, i.e., old/new and describing blanket changes, but I think the intent is pretty clear based on the brevity of the draft. >>>>>> >>>>> >>>>> <mglt> >>>>> I agree we may be able to find all the dots. I think this provides more insight to clarify the reading of 5246. I agree the intend is clearly stated in the title and section 2 addresses most of it and I believe that some flexibility is permitted, but that is unclear to me where to put the bar. I still believe that could be easily be addressed. >>>>> </mglt> >>>>> >> <mglt> >> I think I have lost a bit where we are, but I tend to agree that clarification of 5246 would be clearer here. That is mentioning the text that needs to be removed / changed. >> </mglt> >> <mglt> >> I do not see 07 mentioning the text to be removed - that is now dead text. I think that would be clarifying. >> </mglt> > > To recap: > > You are suggesting that we add the following in s6 before the existing OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": > > In Section 7.1.4.1: the following text is removed: > > If the client supports only the default hash and signature algorithms > (listed in this section), it MAY omit the signature_algorithms > extension. > > Since it’s a MAY, I am a-okay with deleting. Anybody else see harm? Should have added see: https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/13 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call