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

[David Benjamin <[e-mail]>]

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 <[e-mail]> 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
>
> > On Jul 30, 2021, at 12:25, Daniel Migault <[e-mail]> 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.
> >
> >  """
> > 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}.
> > """
> >
> >
> > """
> > If the client supports only the default hash and signature algorithms
> > (listed in this section), it MAY omit the signature_algorithms
> > extension.
> > """
> >
> > Yours,
> > Daniel
> >
> > On Fri, Jul 30, 2021 at 5:10 AM Hannes Tschofenig <
> [e-mail]> wrote:
> > 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 <[e-mail]> On Behalf Of
> Russ Housley
> > Sent: Wednesday, July 28, 2021 10:34 PM
> > To: Sean Turner <[e-mail]>; IETF TLS <[e-mail]>
> > Cc: [e-mail];
> [e-mail]; [e-mail]
> > Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review
> of draft-ietf-tls-md5-sha1-deprecate-04
> >
> > >   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?
> >
> > I don't see any harm.
> >
> > Russ
> >
> > --
> > Iot-directorate mailing list
> > [e-mail]
> > 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.
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > --
> > Daniel Migault
> > Ericsson
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>