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

Sean Turner <sean@sn3rd.com> Wed, 28 July 2021 16:45 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 CD4AC3A17D7 for <tls@ietfa.amsl.com>; Wed, 28 Jul 2021 09:45:41 -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 bLEg0Ptj7GRu for <tls@ietfa.amsl.com>; Wed, 28 Jul 2021 09:45:36 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 D0B9C3A17F0 for <tls@ietf.org>; Wed, 28 Jul 2021 09:45:27 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id a12so1809763qtb.2 for <tls@ietf.org>; Wed, 28 Jul 2021 09:45:27 -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=qd/u0KylEdoXgtsf4cBCAvMxi9NE6sYmqIrj43+JstA=; b=dju77HKqU8rq/dp8b6b9+wXBYszYd3RHFEvlr9LJD5Q4FBCe7fk619wDVSsmjeX3ap d9ZXdUJDoI4QkfiAGgNxc/JZoxm9ByAQTaebUr8CAT2fguA4UUbWMbQe2SkoncMlMnBM XKBZ59n17qKuboNMir8ZRyzxNCZIHQqvaH1sY=
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=qd/u0KylEdoXgtsf4cBCAvMxi9NE6sYmqIrj43+JstA=; b=eqw59W/OwPFqNwijMk+AdBJ+M2ieyuvALewt72KcgjxXB/ookqIAwMmVLO9EhDZttA 0JNk3BzZWpyL7sxhgdQHyGF/xnkxA8L8URnhC9mbgAeMpoeIDUnGqZX+BruzUufTuUnG Ez+ahR8gvGpK65K18DzdLGNUGXvgO+qpvs8c+niGVO65v8GkUXXfz1CmjUoIbKTeu4Gf EuSVxyZpLL6USsEuIKejW00XMqrqmyTsed1DgntGY7VG72QqRjG0UuNAmS0k62JoGI6P 7N6FnPMJVlsFpcYEl6lRwuvCjPb4fMLaaWQlIeaS4CPMbZMKj4e8lmRnxH7JFSC3p31D uHMg==
X-Gm-Message-State: AOAM532Lx9uk6pqr5sepZMYJIK5tk3NyB9F98FXY7Fm3WflFhxm/mNpm snnqX5lzkupsjXceuOroILqu9Q==
X-Google-Smtp-Source: ABdhPJxXYo6a3B4un7qjOVMd5edr//HnbF6yB3+xOFBiRyGcmtd1PG+T3hw5XMIWwU7iak9SDS2fZw==
X-Received: by 2002:ac8:4e45:: with SMTP id e5mr405886qtw.63.1627490726252; Wed, 28 Jul 2021 09:45:26 -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 5sm275251qko.53.2021.07.28.09.45.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 09:45:25 -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: <32892AD4-EA0B-49F2-9CFD-FA9509FA3010@sn3rd.com>
Date: Wed, 28 Jul 2021 12:45:24 -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: <48D7834A-5235-4CD6-8786-09A189BFD4F5@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> <32892AD4-EA0B-49F2-9CFD-FA9509FA3010@sn3rd.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/kIduqIwgdB38ITHvVu9UE0WQ0JE>
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:45:42 -0000


> On Jul 28, 2021, at 12:41, Sean Turner <sean@sn3rd.com> wrote:
> 
> 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?

Should have added see:

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