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 <sean@xxxxxxxxx> 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 <mglt.ietf@xxxxxxxxx> 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 <Hannes.Tschofenig@xxxxxxx> 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 <iot-directorate-bounces@xxxxxxxx> On Behalf Of Russ Housley
> Sent: Wednesday, July 28, 2021 10:34 PM
> To: Sean Turner <sean@xxxxxxxxx>; IETF TLS <tls@xxxxxxxx>
> Cc: iot-directorate@xxxxxxxx; draft-ietf-tls-md5-sha1-deprecate.all@xxxxxxxx; last-call@xxxxxxxx
> 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
> Iot-directorate@xxxxxxxx
> 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
> TLS@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tls
>
>
> --
> Daniel Migault
> Ericsson
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
