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

[Sean Turner <[e-mail]>]

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?