Re: [TLS] AD review of draft-ietf-tls-md5-sha1-deprecate-03

Sean Turner <sean@sn3rd.com> Mon, 05 October 2020 15:19 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 8EA023A0100 for <tls@ietfa.amsl.com>; Mon, 5 Oct 2020 08:19:20 -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=ham 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 KXNFEXYtHwHo for <tls@ietfa.amsl.com>; Mon, 5 Oct 2020 08:19:18 -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 98DFB3A07C4 for <tls@ietf.org>; Mon, 5 Oct 2020 08:19:18 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id q26so4640574qtb.5 for <tls@ietf.org>; Mon, 05 Oct 2020 08:19:18 -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=R1UXLjzX2WSJUwXZ//zOxaKF5mFfX5SaXBCrtL3ksTE=; b=Xlv4mPK5+YmNJPA9EnbpDulxNY9QIflEXl9YQyNdflzbwEIU1fjSoXakCBTxCTrn6W sQoaBw185LFCpcATKU4Iy4vYAxqsg+Cy2Z90c3IJRTBXejdnfzoObyttyN1oeBEU2xPd yUebB5cL7GUQbNQCnjNrOscDqeW4Vx7BWYMDU=
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=R1UXLjzX2WSJUwXZ//zOxaKF5mFfX5SaXBCrtL3ksTE=; b=kqRw1cdu8/NspbYpObeGw2VSDhWoD7LrWbOp1l6Q8XGGWWRYB/sszOImdhWrmVypP8 XJ1vP93sBoxZbb9ISJwddVTZygM1YjLJUq1Vxo9zVtoXP5jMXrSYElSte+jVmB8TTkFd rUm2vrhN3LGQniDlJeLn4ip4hx0peAtxl7vKz67CGeN/I4zL3u/Mt63DnVL5ATxBzFgP bA5cqm71ljgTnT3tnPRIezg0dk0XFbJ4UYU73J4LGhMa0P1hP6WRxIABnI5cMUot0mRQ mYGuQk5tW8SH5+bq2qcqYeCIrQl9xwW+1OCK/aFSkFJru+btJtvtz9ywrsbpZ2Tn/YKL st5Q==
X-Gm-Message-State: AOAM530dI4KvcnsQY+UlppMIvsTMXBGn8SRqlycFmzjMht1f28w/MrmQ 1/WW6pF6TgJpVU0i89w0tKZ8RG+140plqw==
X-Google-Smtp-Source: ABdhPJyu79+LPCGSVUbW0PBKhHVeIqdkpiTdt+QtcP51M6BuTIqMS47NoGsIBMcbwLLrTMST/9I34g==
X-Received: by 2002:ac8:cc4:: with SMTP id o4mr325312qti.21.1601911157303; Mon, 05 Oct 2020 08:19:17 -0700 (PDT)
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 c11sm272633qkb.58.2020.10.05.08.19.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2020 08:19:15 -0700 (PDT)
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 <sean@sn3rd.com>
In-Reply-To: <5fc530396594430f81e8f609a1f11ea6@cert.org>
Date: Mon, 05 Oct 2020 11:19:14 -0400
Cc: TLS List <tls@ietf.org>, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BD7AF63-C680-404A-A590-BF7402C886CE@sn3rd.com>
References: <5fc530396594430f81e8f609a1f11ea6@cert.org>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/goSiyq4bLtnzSTXgpdl0_CnpWS8>
Subject: Re: [TLS] AD review of draft-ietf-tls-md5-sha1-deprecate-03
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: Mon, 05 Oct 2020 15:19:21 -0000

Roman,

Thanks for your review. Some comments inline.

spt

> On Oct 2, 2020, at 19:42, Roman Danyliw <rdd@cert.org> wrote:
> 
> Hi!
> 
> I've assumed the role of responsible AD on this document.  As such, I performed an AD review of draft-ietf-tls-md5-sha1-deprecate-03.  
> 
> Thanks for writing this document to address an important crypto maintenance tasks in TLS v1.2.  I have a few clarifying and pro forma editorial items of feedback.  
> 
> ** Please address the following IDNits:
> 
> -- The document seems to lack an IANA Considerations section.  (See Section
>     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
>     when there are no actions for IANA.)

Addressed via:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7

Comments about one below, but the remaining are addressed via:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/8

> -- The draft header indicates that this document updates RFC5246, but the
>     abstract doesn't seem to mention this, which it should.
> 
> -- The draft header indicates that this document updates RFC7525, but the
>     abstract doesn't seem to mention this, which it should.
> 
> ** Section 1.  Editorial. 
> -- s/RFC 5246 [RFC5246]/[RFC5246]/
> 
> -- s/RFC 6151 [RFC6151]/[RFC6151]/
> 
> -- s/RFC7525 [RFC7525]/[RFC7525]/
> 
> ** Section 1.  Editorial.  For symmetry with the rest of the text:
> 
> OLD
> RFC 6151 [RFC6151]
>   details the security considerations, including collision attacks for
>   MD5, published in 2011.  
> 
> NEW
> In 2011, [RFC6151]  detailed the security considerations, including collision attacks for MD5.  
> 
> ** Section 1.  Please provide a reference for "Wang, et al".  Is there a reference to provide for the "the potential for brute-force attack"

For the Wang attack we used the following reference when updating the SHA-0 and SHA-1 considerations. I put it where the collisions are first noted. I am unsure if it’s the latest and greatest:

Wang, X., Yin, Y., and H. Yu., "Finding Collisions in
                 the Full SHA-1", Crypto 2005.

<rant: I am not entirely sure I did the XML right for the reference.>

I am not sure there is a reference for the brute force potential attack, but somebody correct me if I am wrong. The way I see it if you know the collision space is much smaller well you might launch said attack.

In s1.1, I also updated the paragraph to use the new paragraph and fixed the references.

> ** Section 6.  Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/
> 
> ** Section 6.  Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is  a clear cut-and-paste.
> 
> ** Section 7.  Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/
> 
> ** Section 7.  SHA-1 is also not mentioned in RFC7525.  Recommend:
> 
> OLD
> The prior text did not explicitly include
>   MD5 and this text adds it to ensure it is understood as having been
>   deprecated.
> 
> NEW
> The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated.
> 
> ** Section 7.  Editorial.  Grammar.
> 
> OLD
> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED,
>   SHA-1 or MD5 MUST NOT be used
> 
> NEW
> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used
> 
> ** Section 10.2  Please make RFC5246 a normative reference.
> 
> Regards,
> Roman
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls