> On Jul 28, 2021, at 12:41, Sean Turner <s...@sn3rd.com> 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
