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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
From:       Sean Turner <sean () sn3rd ! com>
Date:       2021-07-28 16:45:24
Message-ID: 48D7834A-5235-4CD6-8786-09A189BFD4F5 () sn3rd ! com
[Download RAW message or body]

> On Jul 28, 2021, at 12:41, Sean Turner <sean@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

[prev in list] [next in list] [prev in thread] [next in thread] 