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

David Benjamin <davidben@chromium.org> Sat, 31 July 2021 03:11 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04AF3A0BAB for <tls@ietfa.amsl.com>; Fri, 30 Jul 2021 20:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.706
X-Spam-Level:
X-Spam-Status: No, score=-8.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfMTi99MUH-W for <tls@ietfa.amsl.com>; Fri, 30 Jul 2021 20:11:04 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBBC3A0BAC for <tls@ietf.org>; Fri, 30 Jul 2021 20:11:04 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id t21so13240454plr.13 for <tls@ietf.org>; Fri, 30 Jul 2021 20:11:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=coTjzqiPb2KR859B6Pb+ikylCF878MQTUDtnCt/eZXI=; b=gzEP6AOyh9BFHkoIt3urhhzlp/rm8XGM2EAMFByHP6cYvxDOC+24VraRmjUNqRWWat i+Bw2aMd7kw+N8FBMfMX53E0zh/n55dWFgWMpKk6h+mwTk5hjAybN0vl1+QRfr5KD/wx am7Q9DXHiV/NGkQ6rfgw9SxcCQ4TPfdwWdHHs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=coTjzqiPb2KR859B6Pb+ikylCF878MQTUDtnCt/eZXI=; b=Kjdk73O0zqJbBDKaah42OSKfy1waz1U7pczXI2msLSvt49Ghi+ErFi8f/PaiyXZLaZ O++XxyQAugvmRyRp7yHfeMBmQEsvRv7mF4ZL1Wrig7y7/krNcqZx4gHq/ktqe1RO8pz7 AOOy924F6DQZWr4/W3fZzMDRJZ9WXS948N1kPqP3fbN+HjZYqqB4TL8mVk9Y38GZva0p pYO43SNTYepFCz+oDp9+XKDaYLx5uSKF3mYppNtbshrebQ5sMEtXYmOHmFtQuMppQ200 KzTr3X7jggp4yOCtUcjfHJMAa4Sk5d85nAzzn4CsvW8AkhqZWgCy/wYWe2JBVA043JEq zSTA==
X-Gm-Message-State: AOAM532WEDYHzi4Tef0gMSwBGEGugJ08HjPZSs6Dbn7864OEUFLs2z63 L97CJ+8XidxHwKkRW/A9FmhbHQQkh4aMISlCUwB0
X-Google-Smtp-Source: ABdhPJyvOIgrMT+z92yzg6J+ETQe4Yt1Cxgd+EZxXFl9Gl//5NeQsw95Tu7Nv8cIBsy3QvDFXCm1XMEN4WZ/1KmEea0=
X-Received: by 2002:a62:1946:0:b029:3ac:ec92:e680 with SMTP id 67-20020a6219460000b02903acec92e680mr5894582pfz.51.1627701063360; Fri, 30 Jul 2021 20:11:03 -0700 (PDT)
MIME-Version: 1.0
References: <160380837029.27888.4435196327617929302@ietfa.amsl.com> <9EA8797E-2487-4465-9608-6CCB6E565BEE@sn3rd.com> <CADZyTk=_WSrc+UfKmZ6b=HzmfEvitu1p6Q9N7GvkHUn3619dnw@mail.gmail.com> <CAOp4FwRyd7tAcbQJR3Td_N=SgdUionwvbXfva2_tnvXcvHWkvA@mail.gmail.com> <CADZyTknQhh=yNf2isOutZa1XKoHtk6dOvE6hgXni8JowsJm=eQ@mail.gmail.com> <C93021E9-3F50-4448-8659-EE6688C3A9E0@sn3rd.com> <C9D655C0-BD5E-4E52-BFF4-BD88D281B34B@sn3rd.com> <CADZyTknWs-kNp4EO39souKQwHsT=EAWOQ_E5Z4J77KFgudhhhg@mail.gmail.com> <CADZyTk=tgThJ7RJ_=K=gdDYcUWkhy0AjcLB_Nvf1=UEUBrzAUQ@mail.gmail.com> <32892AD4-EA0B-49F2-9CFD-FA9509FA3010@sn3rd.com> <A48DAF03-F2CB-4448-B9E8-6AE4ECB77565@vigilsec.com> <DBBPR08MB5915AE02B525DE00B05F9EBEFAEC9@DBBPR08MB5915.eurprd08.prod.outlook.com> <CADZyTkm1Qmb2VDMiQN82oOojYrhRJA_95j=T3pxpxZ5oFCAiew@mail.gmail.com> <524E28CE-92D6-4E25-A85E-B5D1C1A6919F@sn3rd.com>
In-Reply-To: <524E28CE-92D6-4E25-A85E-B5D1C1A6919F@sn3rd.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 30 Jul 2021 23:10:46 -0400
Message-ID: <CAF8qwaDrfiPghXmSr0GbKU9DZF334iexxaH8vqqPK=S4pcXG1A@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Daniel Migault <mglt.ietf@gmail.com>, TLS List <tls@ietf.org>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "draft-ietf-tls-md5-sha1-deprecate.all@ietf.org" <draft-ietf-tls-md5-sha1-deprecate.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af696b05c862af09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gYy1LxzVtxitWaAfzi1jCbVx8MI>
Subject: Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jul 2021 03:11:10 -0000

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