From nobody Fri Jan 29 11:08:29 2021 Return-Path: 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 BFED43A123D for ; Fri, 29 Jan 2021 11:08:23 -0800 (PST) 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 9j_aVV8p26iA for ; Fri, 29 Jan 2021 11:08:20 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 444503A123C for ; Fri, 29 Jan 2021 11:08:20 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id o18so7461340qtp.10 for ; Fri, 29 Jan 2021 11:08:20 -0800 (PST) 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=+XU+gdkKKMiEAdiSnxtZurknwyfS1OSKA6jkY8lpD64=; b=gKd/rEZrRO6ggt+GQgq6mcyi80gVF98smfJTjuAVhF9+15as33DMAQqCM/zwIGe5vL NlBZZy+tVynT1/X266fLB4BqdrneNUa+LluFbWYJRUCeaxfq/xFldQwLWjcuOfHinTyP YaeTwm5GaXa4U1MpNUTXtRi8a9mL6lBjBb4lM= 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=+XU+gdkKKMiEAdiSnxtZurknwyfS1OSKA6jkY8lpD64=; b=WVvpziqPuPATvJTy+htPNuF4+ai3OkULA6keiU686BmtTxvEquTSocJmfexDFJC8eG 6VEEntBaOM0v/EFxOjSSl+iQfWVST9yWShmnG/gme57IYqeYF72Ocf8BlPDuv37/mWdw 27cZf4DVS0ly0NHuJTQbcJRKXHwJGF9UBuu0bQ/OG+Jdao+7E+Gg0VSa+55pUxXPEGmR dxhigfysia+zD3qqa4+4Krf1uExeh0waOL7PId3hQPfjRILs8ZWDEgGt8/NHuLN4e66m Z3A6AKHbZEo5XvoLf3kglb/pGXRm0sRNoxayQ9i9acF5S3ZvdGggXNn0T2AcxblAvCig cbow== X-Gm-Message-State: AOAM531p036E6q80B9wW6rrgkzokAFNadQhVlTXwQy06q5v/FXKGnCSH RWyjJ2PWK+SetrDtLBSw7NFk6TFYobh2tQ== X-Google-Smtp-Source: ABdhPJyJcJm6gIXEy9zdh7ZMPC/MxbTJts77HDpQ+HU4gKRuwoBstnmdigEzkb4GC+unhYJYvIojpQ== X-Received: by 2002:ac8:71d6:: with SMTP id i22mr5694943qtp.206.1611947299069; Fri, 29 Jan 2021 11:08:19 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id u133sm1277049qka.116.2021.01.29.11.08.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jan 2021 11:08:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: Date: Fri, 29 Jan 2021 14:08:12 -0500 Cc: iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org, TLS List Content-Transfer-Encoding: quoted-printable Message-Id: References: <160380837029.27888.4435196327617929302@ietfa.amsl.com> <3448B476-23BF-4D38-B41C-3E6CD5CFB8AE@sn3rd.com> To: Daniel Migault X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 19:08:24 -0000 > On Jan 21, 2021, at 16:50, Daniel Migault wrote: >=20 > Hi,=20 >=20 > First I deeply apologize for taking so long to respond, I just = realized now these responses.=20 No worries it does happen that I miss email from time to time too ;) > I do not believe a review of IoT protocol is needed, I am more = thinking that TLS document should serve as a base guidance for TLS. = Specific needs for IoT are addressed based on the generic guidances. In = some cases specific extensions, cipher suites - not referenced by IANA = as recommended - will be needed to address specific corner cases.=20 I agree with you since the TLS RFC provides the general use case. Other = RFCs can specify other use cases. The way we handled this for CCM_8 = suites was to include the following note: Note CCM_8 cipher suites are not marked as "Recommended". These cipher suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments. spt > Yours,=20 > Daniel =20 >=20 > On Tue, Oct 27, 2020 at 11:32 PM Sean Turner wrote: >=20 >=20 > > On Oct 27, 2020, at 10:32, Daniel Migault = wrote: > >=20 > > To address the comment below, keeping weak security is likely to = weaken current and future IoT communications, so I do not think there is = room for compromise with performance. Of course this is in a context of = TLS. I expect protocol to leverage from TLS security, so the impact = should be rather negligible.=20 > >=20 > > """ > > As those hash algorithms were 'cheap' for TLS 1.2, I would = appreciate a review of impacted IoT protocols if those algorithms are = deprecated. > > """ >=20 > In terms of process, are you suggesting "a review of impacted IoT = protocols if those algorithms are deprecated=E2=80=9D MUST be completed = prior to advancing this document to the IESG? >=20 > spt >=20 > > Yours,=20 > > Daniel > >=20 > >=20 > > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker = wrote: > > Reviewer: Daniel Migault > > Review result: Ready with Nits > >=20 > > Hi, > >=20 > >=20 > > I reviewed this document as part of the IoT Directorate's ongoing = effort to > > review all IETF documents being processed by the IESG. These = comments were > > written primarily for the benefit of the Security Area Directors. = Document > > authors, document editors, and WG chairs should treat these comments = just like > > any other IETF Last Call comments. =20 > >=20 > > Review Results: Ready with Nits > >=20 > > Please find my comments below. > >=20 > > Yours, > > Daniel > >=20 > >=20 > > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 > > draft-ietf-tls-md5-sha1-deprecate-04 > > [...] > >=20 > > 1. Introduction > >=20 > > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is > > specified in [RFC5246]. MD5 and SHA-1 have been proven to be > > insecure, subject to collision attacks [Wang]. In 2011, = [RFC6151] > > detailed the security considerations, including collision attacks = for > > MD5. NIST formally deprecated use of SHA-1 in 2011 > > [NISTSP800-131A-R2] and disallowed its use for digital signatures = at > > the end of 2013, based on both the Wang, et. al, attack and the > > potential for brute-force attack. In 2016, researchers from = INRIA > > identified a new class of transcript collision attacks on TLS = (and > > other protocols) that rely on efficient collision-finding = algorithms > > on the underlying hash constructions [Transcript-Collision]. > > Further, in 2017, researchers from Google and CWI Amsterdam > > [SHA-1-Collision] proved SHA-1 collision attacks were practical. > > This document updates [RFC5246] and [RFC7525] in such a way that = MD5 > > and SHA-1 MUST NOT be used for digital signatures. However, this > > document does not deprecate SHA-1 in HMAC for record protection. > >=20 > > > > RFC6194 may be mentioned as a reference for > > not deprecating HMAC-SHA-1 as well as an > > additional reference to [NISTSP800-131A-R2].=20 > >=20 > > Reading the text the situation of HMAC with > > MD5 is unclear. Since we specify that SHA-1 > > is not deprecated for HMAC we may specify > > the status for HMAC with MD5. Given RFC6151 I > > hope the reason is that MD5 and HMAC-MD5 has > > already been deprecated but I have not found > > this. Maybe that would worth mentioning it > > is deprecated already. > >=20 > > > >=20 > > [...] > >=20 > > 2. Signature Algorithms > >=20 > > Clients MUST NOT include MD5 and SHA-1 in the = signature_algorithms > > extension. If a client does not send a signature_algorithms > > extension, then the server MUST abort the handshake and send a > > handshake_failure alert, except when digital signatures are not = used > > (for example, when using PSK ciphers). > >=20 > > > > It seems to me that the server behavior might > > be defined as well. In our case this could be > > something around the lines the server MUST > > ignore MD5 and SHA1 values in the signature > > algorithm extension.=20 > >=20 > > > >=20 > > 3. Certificate Request > >=20 > > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > > messages. > >=20 > > > > It seems to me that the same level of > > authentication should be provided for both > > peers and that server MUST NOT include MD5 > > or SHA-1. > >=20 > > A SHOULD NOT status might be welcome for a > > smooth transition. At that time, collision > > for MD5 and SHA1 are known for years. It is likely > > that software that still need MD5 or SHA1 are > > likely to never upgrade, so I doubt a smooth > > path worth being taken.=20 > > > >=20 > > 4. Server Key Exchange > >=20 > > Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange = messages. > > If a client receives a MD5 or SHA-1 signature in a = ServerKeyExchange > > message it MUST abort the connection with the illegal_parameter > > alert. > >=20 > > > > As per section 2, the client has clearly > > indicated it does not support signature with > > MD5/SHA1, so Server Key Exchange should not > > end up with signature with SHA1/MD5.=20 > >=20 > > """ > > If the client has offered the "signature_algorithms" extension, the > > signature algorithm and hash algorithm MUST be a pair listed in = that > > extension.=20 > > """ > >=20 > > It also seems to me that the constraint of > > including a MD5 and SHA-1 signature is > > related to the Certificate. I suspect that > > some clarification are needed here. =20 > >=20 > > Since the case where the extension becomes > > mandatory, the quoted text above of RFC 5246 > > might be updated as well, though this does > > not appear that necessary. > >=20 > > > >=20 > > 5. Certificate Verify > >=20 > > Clients MUST NOT include MD5 and SHA-1 in CertificateVerify = messages. > > If a server receives a CertificateVerify message with MD5 or = SHA-1 it > > MUST abort the connection with handshake_failure or > > insufficient_security alert. > >=20 > >=20 > > > >=20 > > 6. Certificate=20 > >=20 > > Unless I am missing something, it seems to me > > that signature may also be found in the > > Certificate messages for the chain as well in > > the restriction of the signature algorithm. > > The end certificate is associated to the peer > > while other certificate are related to a CA.=20 > >=20 > > It seems that client and server behavior may > > be specified. The quoted text below may be > > helpful to clarify.=20 > >=20 > > """ > > If the client provided a "signature_algorithms" extension, then all > > certificates provided by the server MUST be signed by a > > hash/signature algorithm pair that appears in that extension. > > """ > >=20 > > > >=20 > > 6. Updates to RFC5246 > >=20 > > [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. > >=20 > > In Section 7.4.1.4.1: the text should be revised from: > >=20 > > OLD: > >=20 > > "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." > >=20 > > NEW: > >=20 > > "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." > >=20 > >=20 > > > > I am reading the Note as an explanation on > > why sha was taken as the default hash > > function with the following rules.=20 > >=20 > > """ > > If the client does not send the signature_algorithms extension, the > > server MUST do the following: > >=20 > > - 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}. > >=20 > > - If the negotiated key exchange algorithm is one of (DHE_DSS, > > DH_DSS), behave as if the client had sent the value = {sha1,dsa}. > >=20 > > - If the negotiated key exchange algorithm is one of = (ECDH_ECDSA, > > ECDHE_ECDSA), behave as if the client had sent value = {sha1,ecdsa}. > > """ > >=20 > > 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. > > As a results, these rules and the "Note" may > > eventually all together be replaced by your > > text of section 2.=20 > >=20 > > The following text may also be removed: > >=20 > > """ > > If the client supports only the default hash and signature = algorithms > > (listed in this section), it MAY omit the signature_algorithms > > extension. > > """ > >=20 > > Regarding the Note, it seems to be that the > > removal of support for MD5/SHA1 will result > > in interoperability issues. At this point, > > the issue is due to the obsolescence of the > > implementation as deprecation of SHA1/Md5 has > > started a long time ago.=20 > >=20 > > It is unclear to me how normative is > > interpreted "can assume". Was the support of > > MD5/SHA1 a SHOULD or a MUST? In both case, if > > we were willing to maintain interoperability > > between software that only implemented > > MD5/SHA1, we should take a slower path and > > introducing SHA-256 and having were MD5/SHA1 > > kept for interoperability purpose before > > being deprecated. I do not think we should > > take that path as implementations that > > currently do not support SHA-256 are unlikely > > to be updated and that deprecation of > > SHA1/MD5 has started a long time ago.=20 > >=20 > > I would however mention the issue of > > interoperability in the section but not in > > the text to update. In the text to update I > > would maybe suggest that the support of > > SHA-256 comes with a normative MUST > > statement.=20 > >=20 > >=20 > > > >=20 > > Velvindron, et al. Expires April 12, 2021 = [Page 3] > >=20 > > Internet-Draft draft-ietf-tls-md5-sha1-deprecate October = 2020 > >=20 > >=20 > > 7. Updates to RFC7525 > >=20 > > [RFC7525], Recommendations for Secure Use of Transport Layer = Security > > (TLS) and Datagram Transport Layer Security (DTLS) recommends use = of > > SHA-256 as a minimum requirement. This update moves the minimum > > recommendation to use stronger language deprecating use of both = SHA-1 > > and MD5. The prior text did not explicitly include MD5 or SHA-1; = and > > this text adds guidance to ensure that these algorithms have been > > deprecated.. > >=20 > > Section 4.3: > >=20 > > OLD: > >=20 > > When using RSA, servers SHOULD authenticate using certificates = with > > at least a 2048-bit modulus for the public key. In addition, the = use > > of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] = for > > more details). Clients SHOULD indicate to servers that they = request > > SHA-256, by using the "Signature Algorithms" extension defined in = TLS > > 1.2. > >=20 > > NEW: > >=20 > > Servers SHOULD authenticate using certificates with at least a > > 2048-bit modulus for the public key. > >=20 > > In addition, the use of the SHA-256 hash algorithm is = RECOMMENDED; > > and SHA-1 or MD5 MUST NOT be used (see [CAB-Baseline] for more > > details). Clients MUST indicate to servers that they request = SHA- > > 256, by using the "Signature Algorithms" extension defined in TLS > > 1.2. > >=20 > > > > I understand the reason we do specify that > > hash algorithms that MUST NOT been used. This > > is fine in the context of this document, but > > it seems to me that if we were writing the > > updated specification we may have rather > > mentioned a minimum level of security hash > > function needs to be met - in our case > > SHA-256. I leave the co-authors make the > > appropriated choice. =20 > >=20 > > > >=20 > >=20 > > 8. IANA Considerations > >=20 > > The document updates the "TLS SignatureScheme" registry to change = the > > recommended status of SHA-1 based signature schemes to N (not > > recommended) as defined by [RFC8447]. The following entries are = to > > be updated: > >=20 > > +--------+----------------+-------------+-------------------+ > > | Value | Description | Recommended | Reference | > > +--------+----------------+-------------+-------------------+ > > | 0x0201 | rsa_pkcs1_sha1 | N | [RFC8446][RFCTBD] | > > | 0x0203 | ecdsa_sha1 | N | [RFC8446][RFCTBD] | > > +--------+----------------+-------------+-------------------+ > >=20 > > Other entries of the resgistry remain the same. > >=20 > >=20 > > > > It seems to me that TLS 1.2 is using the TLS > > hash and TLS signature registry TLS signature > > registry and TLS 1.3 is using Signature > > Scheme.=20 > >=20 > > I suspect that TLS hash values for sha1 and > > md5 should be deprecated. And RFCTBD should > > be added for sha1 and md5. Note that the=20 > > SHOULD NOT status for CertificateRequest > > may have prevented such deprecation.=20 > >=20 > > A side effect is these code points for > > signature scheme that were assigned for > > compatibility with legacy (TLS 1.2) > > signatures must not be used anymore - if > > there are no more valid with TLS 1.2.=20 > > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > >=20 > >=20 > > --=20 > > Daniel Migault > > Ericsson >=20 >=20 >=20 > --=20 > Daniel Migault > Ericsson