Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner <[e-mail]>]

> On Jul 28, 2021, at 12:41, Sean Turner <[e-mail]> 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