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

From: Sean Turner <[email-masked]>
Date: Wed, 28 Jul 2021 12:41:47 -0400

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?

---

From: Sean Turner <[email-masked]>
Date: Wed, 28 Jul 2021 12:45:24 -0400

> On Jul 28, 2021, at 12:41, Sean Turner <[email-masked]> wrote:
> 
> Daniel,
> 

Should have added see:

https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/13

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Jul 2021 19:52:15 +0000

>    Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?

Whew, that' a lot of recipients just for me to say: I don't see any problem in removing this if folks still think it's understood/implied.

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Jul 2021 16:33:45 -0400

>   Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?

I don't see any harm.

Russ

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jul 2021 09:08:02 +0000

I have no problem with the suggestion.

A few other observations:

1. FWIW: The reference to [Wang] is incomplete.

2. The references to the other papers use the websites of the authors or project websites. I would use more stable references.

3. Kathleen's affiliation is also outdated.

4. Is the update to RFC 7525 relevant given that there is an update of RFC 7525 in progress (see https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even near completion?

5. The title of the draft gives the impression that this update only refers to TLS 1.2 but later in the draft DTLS is also included via the reference to RFC 7525. Should the title be changed to "Deprecating MD5 and SHA-1 signature hashes in TLS/DTLS 1.2"?

Ciao
Hannes

-----Original Message-----
From: Iot-directorate <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, July 28, 2021 10:34 PM
To: Sean Turner <[email-masked]>; IETF TLS <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

I don't see any harm.

Russ

--
Iot-directorate mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iot-directorate
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 30 Jul 2021 12:25:42 -0400

Hi,

Just to sum, up my initial comment proposed to mention as being removed
remove the texts mentioned below. Since Sean mentioned that removing a text
with MUST can be problematic, for the first text we can also just explain
that in the context of this draft, the first text ends in being some dead
code. I would be interested to understand - and only for my personal
understanding - why removing a text with MUST is harder than a text with
MAY.

My understanding is that the current proposal is to remove the second text,
and that the case of the first text has not been concluded - of course
unless I am missing something. As a result, I think I hope we can converge
for the two texts and I am fine the first text being mentioned as removed
or ending as  dead code.

 """

"""

Yours,
Daniel

On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig <[email-masked]>
wrote:

> 2. The references to the other papers use the websites of the authors or
> project websites. I would use more stable references.
>
> 4. Is the update to RFC 7525 relevant given that there is an update of RFC
> 7525 in progress (see
> https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and
> even near completion?
>
> 5. The title of the draft gives the impression that this update only
> refers to TLS 1.2 but later in the draft DTLS is also included via the
> reference to RFC 7525. Should the title be changed to "Deprecating MD5 and
> SHA-1 signature hashes in TLS/DTLS 1.2"?
>
> Ciao
> Hannes
>
> Cc: [email-masked];
> [email-masked]; [email-masked]
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Daniel Migault
Ericsson

---

From: Sean Turner <[email-masked]>
Date: Fri, 30 Jul 2021 19:31:57 -0400

> On Jul 30, 2021, at 05:08, Hannes Tschofenig <[email-masked]> wrote:
> 

The same ref was used in RFC 6194, but we could also use:
https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf

> 2. The references to the other papers use the websites of the authors or project websites. I would use more stable references.

We can replace:

http://shattered.io/static/shattered.pdf

with 

https://eprint.iacr.org/2017/190

and (is the INRIA site better?)

ttps://www.mitls.org/downloads/transcript-collisions.pdf

with

https://hal.inria.fr/hal-01244855/document

> 3. Kathleen's affiliation is also outdated.

Ah I thought we fixed that. Anyway we’ll change it to: CIS

> 4. Is the update to RFC 7525 relevant given that there is an update of RFC 7525 in progress (see https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even near completion?

I do not have a problem moving the text. I might also solve the can a standard update a BCP question.

What do people think?

> 5. The title of the draft gives the impression that this update only refers to TLS 1.2 but later in the draft DTLS is also included via the reference to RFC 7525. Should the title be changed to "De…

We could do (D)TLS 1/2 too.

---

From: Sean Turner <[email-masked]>
Date: Fri, 30 Jul 2021 19:55:59 -0400

Daniel,
 
So the current proposal is that signature_algorithms is always included.  I understand that with that in mind it might make sense to also remove the other text as well.

What do others think?

spt

> On Jul 30, 2021, at 12:25, Daniel Migault <[email-masked]> wrote:
> 
> Hi,
> 
> Just to sum, up my initial comment proposed to mention as being removed remove the texts mentioned below. Since Sean mentioned that removing a text with MUST can be problematic, for the first text we can also just explain that in the context of this draft, the first text ends in being some dead code. I would be interested to understand - and only for my personal understanding - why removing a text with MUST is harder than a text with MAY. 
> 
> My understanding is that the current proposal is to remove the second text, and that the case of the first text has not been concluded - of course unless I am missing something. As a result, I think I hope we can converge for the two texts and I am fine the first text being mentioned as removed or ending as  dead code.  
> 
>  """
> On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig <[email-masked]> wrote:

---

From: David Benjamin <[email-masked]>
Date: Fri, 30 Jul 2021 23:10:46 -0400

I'm having a bit of a hard time following email quotes containing diffs of
diffs, so I may be misinterpreting who is arguing for what, but I think I
agree with Daniel? I'm not sure. :-) I think:

- We can't usefully change the interpretation of ClientHellos without the
sigalgs extension. In particular, clients that support just SHA-256 need to
send it, so that existing servers do not interpret it to mean SHA-1.

- Since we're saying the client cannot offer SHA-1, the client's rules on
when to to omit sigalgs are effectively a no-op. That, in turn, means the
server rule's are a no-op.

- I agree that the sentence "Note: [...] as a practical matter one can
assume that the peer supports MD5 and SHA-1" reads like it's talking about
the server rules. Thus I think the diff applied in Section 6
of draft-ietf-tls-md5-sha1-deprecate-07 isn't right. We're explicitly not
redefining the missing extension, so it's not right to change the
assumptions one can make.

As for the actual diffs on RFC5246, I don't feel strongly, but my overall
inclination from this thread is that diffs are too confusing. How about we
drop Section 6, and leave all the mess around how to interpret a missing
extension alone? Missing extension remains another way to say SHA-1-only,
and we've said servers reject SHA-1-only. And then the first sentence of
Section 2 can be amended to say "Clients MUST include the
signature_algorithms extension and MUST NOT include MD5 and SHA-1 in it",
because I think we haven't actually forbidden clients from omitting the
extension.

If we want to call out where we're updating RFC5246, we can perhaps
introduce a new "Updates to RFC5246" section whose subsections are the old
Sections 2-5. Those indeed update the rules of RFC5246, just not as a bunch
of diffs.

David

On Fri, Jul 30, 2021 at 7:57 PM Sean Turner <[email-masked]> wrote:

> Daniel,
>
> So the current proposal is that signature_algorithms is always included.
> I understand that with that in mind it might make sense to also remove the
> other text as well.
>
> What do others think?
>
> spt
>
> > My understanding is that the current proposal is to remove the second
> text, and that the case of the first text has not been concluded - of
> course unless I am missing something. As a result, I think I hope we can
> converge for the two texts and I am fine the first text being mentioned as
> removed or ending as  dead code.
> >
> >  """
> > 4. Is the update to RFC 7525 relevant given that there is an update of
> RFC 7525 in progress (see