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

Sean Turner <sean@sn3rd.com> Wed, 28 July 2021 16:41 UTC

Return-Path: <sean@sn3rd.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 7411E3A17B5 for <tls@ietfa.amsl.com>; Wed, 28 Jul 2021 09:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 FF6GRgIlq0U8 for <tls@ietfa.amsl.com>; Wed, 28 Jul 2021 09:41:51 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 35CB53A17AD for <tls@ietf.org>; Wed, 28 Jul 2021 09:41:51 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id x9so1775929qtw.13 for <tls@ietf.org>; Wed, 28 Jul 2021 09:41:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SUXaGGm/xeGoXaXBBwVvwToHQ1erXb7k+w58SKGGrIM=; b=EEIM85xkJWHTzjtgwIn2qilVCVWUOIvollG9HZwSfqcqO0xVkWr0t29wfiPYco8Cpl if1j/BHTTYLEIuuxa/MmrSOmNcRTkquJQACAs/EhAwi85MhswDx8YzfuBjXO8T2jG7M8 w+PrbHikUKyvCJgSvPZUyE0ByjYSVhOqcRYCQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SUXaGGm/xeGoXaXBBwVvwToHQ1erXb7k+w58SKGGrIM=; b=bFfkuf7N7sL77UnTUvP9plqmff+l6IZlWhkxFW/TLKat+/NVx7WJs9LpEAOcQmRm8f Me+pnLYO9fE00oB6cNOgbFJqhdp9ZjU07LOd76Dy/msN+jXKFRptCVS7NPxncUNXkTx5 kk9RSVxe4suP9pYyypqs3BXvo3nTaXRpzLV6F3rpdPq/l39rHCCMUCA7zeMVfKqKo5UE nflOSw9qjr1HD5aSd7fxvBEKbamZvFQPtiXaRy0P0LuiVktuRIf6LvFVC6/fI+H8DfPU pR9P0PRvGOG0wQNXr/M9ElO/g6D5KMzkICdbpEEGcDix5YtZCZVM+waYOQ65q7kNqbHo +1Ow==
X-Gm-Message-State: AOAM531mMSYhkiqY4iqsgxymr3cO4zTWvE8Yvo7GZt0KFsA9J5yHfuWr +IVa3NQeq/9YfZhtCkpKpWQGZA==
X-Google-Smtp-Source: ABdhPJwZwLgIaQOUplP40IcPCUyKHTDfPgHATVMxv3bSiiogDQPaAz3B7cYl0ngoyjOkR6Ok4gCu/w==
X-Received: by 2002:a05:622a:50:: with SMTP id y16mr419585qtw.322.1627490509776; Wed, 28 Jul 2021 09:41:49 -0700 (PDT)
Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id r29sm259434qkm.43.2021.07.28.09.41.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 09:41:49 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <CADZyTk=tgThJ7RJ_=K=gdDYcUWkhy0AjcLB_Nvf1=UEUBrzAUQ@mail.gmail.com>
Date: Wed, 28 Jul 2021 12:41:47 -0400
Cc: iot-directorate@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <32892AD4-EA0B-49F2-9CFD-FA9509FA3010@sn3rd.com>
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>
To: Daniel Migault <mglt.ietf@gmail.com>, Loganaden Velvindron <loganaden@gmail.com>, TLS List <tls@ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HhL1gFRCf1JHORMs3Ob3Yn3qLbs>
Subject: Re: [TLS] 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: Wed, 28 Jul 2021 16:41:57 -0000

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?