Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05
Benjamin Kaduk <bkaduk@akamai.com> Thu, 14 November 2019 20:53 UTC
Return-Path: <bkaduk@akamai.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 C1AE8120921; Thu, 14 Nov 2019 12:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 n2Ku1x2TKUpp; Thu, 14 Nov 2019 12:53:19 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A139512080D; Thu, 14 Nov 2019 12:53:18 -0800 (PST)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAEKqNgc001269; Thu, 14 Nov 2019 20:53:16 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=sYaksfaMYU157lOqmn1/OqrbV7ojboMnqG2SK19gF28=; b=Ca0Azfm3jBEUhGxOW67O6o9XsA8k4D4DEkzxRRxaULEzGgdXrRkmVGnyLLo09GePVTrP UlGSkptT/NFRGpQhluYJx0bLaN2rMaSiJt3QH19t+7W/j6O8Ghk8q8NZbnNYj0Tiq63z g2K/iDdeuuIgLVlyAxAewtNkQmbin0yaG/Fu+3amM8pmn9OofvUWZsnp8v1dVHmRzWc+ DOiBE3AqU5p8SHzvT7prv9cfI2vkl4E9dNEpDYQusLSzY9EpegLRjMMCeWusf+EcSiZQ VEQaz1vr495cN8ILjOjoxFq+CDSmqAmurNGqeOmCQkgG6AobAgMN/Qe6QJVQxfBU6uha SA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2w5p6ead1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Nov 2019 20:53:16 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAEKlPAP017956; Thu, 14 Nov 2019 15:53:15 -0500
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2w5sp0n73m-1; Thu, 14 Nov 2019 15:53:13 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BB0D91FC6A; Thu, 14 Nov 2019 20:53:13 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1iVM76-00058P-CI; Thu, 14 Nov 2019 12:53:12 -0800
Date: Thu, 14 Nov 2019 12:53:11 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-tls-oldversions-deprecate.all@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20191114205311.GP20609@akamai.com>
References: <20191111195325.GE32847@kduck.mit.edu> <CAHbuEH5mCW9aUJva=+umYeTLbOvHQUTSexxVjhn3zNDOv5Sb7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHbuEH5mCW9aUJva=+umYeTLbOvHQUTSexxVjhn3zNDOv5Sb7A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-14_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140172
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-14_05:2019-11-14,2019-11-14 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911140172
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3tBpm1YHY1rVK13BS6TULuVPiWg>
Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05
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: Thu, 14 Nov 2019 20:53:24 -0000
On Wed, Nov 13, 2019 at 06:29:44AM -0500, Kathleen Moriarty wrote: > Hi Ben, > > Just replying to the parts of the tread that were not responded to already > as Stephen will likely be looking at the headers/updates per his message. > Thanks for your careful review. > > On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > Hi all, > > > > This is a "preliminary" review only because there's some strangeness > > relating to the Updates: (and Obsoletes:) headers, and any changes there > > would make me need to go and recheck the relationship of this document to > > the ones listed. So, I haven't done any of that yet, in an attempt to only > > have to do it once. > > > > Specifically, there's skew between the list of documents updated in the top > > header and the list in Section 1.1. Evern more annoyingly, the (tools) > > HTML version seems to be missing some numbers from the document header, > > that are present in the TXT version. (Henrik is going to take a look, per > > > > https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU > > .) > > > > Thanks. > > > > > Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but > > there is no "Obsoletes:" header at the top of the document. > > > > I think nits is right about references (square-bracketed "[RFC6347]") in > > the Abstract; we should change those to normal textual (parenthesed > > "(RFC 6347)") before IETF LC. > > > > Some other notes from a quick pass over the main text (though I'll probably > > read it again once the above are addressed) follow. > > > > Section 1 > > > > It feels a little backwards for a "primary technical reason" to > > deprecate a protocol version being that "at least one widely-used > > library has plans to drop [it]". > > > > I see what you are saying. The major library dropping it has to do with > the number of versions available and supporting them all is cumbersome and > could lead to configuration errors on the part of the user. Would you just > like "primary" removed or would you prefer more of a change to the text? The main reason I raised it is that it doesn't feel like a *technical* reason; it's done for expediency and perhaps with a bit of politics, but there's nothing technical about the protocol involved. > > > > > I do appreciate that we give discussion about what we intend > > "deprecation" to mean and for whom -- thank you for that! > > > > Section 2 > > > > TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant > > change to TLS that aims to address threats that have arisen over > > the years. Among the changes are a new handshake protocol, a new > > key derivation process that uses the HMAC-based Extract-and-Expand > > Key Derivation Function (HKDF), and the removal of cipher suites > > that use static RSA or DH key exchanges, the CBC mode of > > operation, or SHA-1. The list of extensions that can be used with > > TLS 1.3 has been reduced considerably. > > > > While it's true that the initial list of extensions usable with TLS 1.3 > > is smaller than the list of extensions usable at TLS 1.2 taken at the > > same time, it's also true that the requirements for allocating a new > > extension codepoint have been reduced dramatically. So I think I'd say > > that this reflects not a desire to reduce the attack surface (as > > "measured" by number of extensions) but rather a paradigm shift in how > > the protocol works, which leaves some existing functionality > > incompatible with the new model. I don't really get a clear sense of > > what this current last sentence is trying to say (i.e., whether it's one > > of those two descriptions I offered above). > > > > Would you prefer "a significant change", be "a paradigm shift"? If not, > could you propose text? I'm trying to say that the reduced size of the list of extensions is just a side effect, not an end in its own right. But, I seem to have missed that this paragraph is part of a quotation from a NIST document, so I don't get to wordsmith it :) > > > > Section 3 > > > > Similarly, the authentication of the handshake depends on signatures > > made using SHA-1 hash or a not stronger concatenation of MD-5 and > > SHA-1 hashes, allowing the attacker to impersonate a server when it > > is able to break the severely weakened SHA-1 hash. > > > > My recollection of the WG discussions (which I will go review) is that > > we don't really have consensus on the "not stronger" portion of this. > > Is that a key component of the document here? (N.B. this is *not* an > > invitation to rehash that discussion again! The chairs or I can provide > > a summary of points not resolved by previous discussion and points > > believed to be adequately agreed upon, which would be a trigger for any > > additional discussion that might be needed.) > > > > Since you are already looking at the consensus of this with the chairs, we > can wait for your guidance. Okay. That might not happen until after Singapore, though. -Ben
- [TLS] preliminary AD review of draft-ietf-tls-old… Benjamin Kaduk
- Re: [TLS] preliminary AD review of draft-ietf-tls… Stephen Farrell
- Re: [TLS] preliminary AD review of draft-ietf-tls… Kaduk, Ben
- Re: [TLS] preliminary AD review of draft-ietf-tls… Rob Sayre
- Re: [TLS] preliminary AD review of draft-ietf-tls… Martin Thomson
- Re: [TLS] preliminary AD review of draft-ietf-tls… Rob Sayre
- Re: [TLS] preliminary AD review of draft-ietf-tls… Eric Rescorla
- Re: [TLS] preliminary AD review of draft-ietf-tls… Eric Rescorla
- Re: [TLS] preliminary AD review of draft-ietf-tls… Rob Sayre
- Re: [TLS] preliminary AD review of draft-ietf-tls… Eric Rescorla
- Re: [TLS] preliminary AD review of draft-ietf-tls… Rob Sayre
- Re: [TLS] preliminary AD review of draft-ietf-tls… Kathleen Moriarty
- Re: [TLS] preliminary AD review of draft-ietf-tls… Benjamin Kaduk
- Re: [TLS] preliminary AD review of draft-ietf-tls… Stephen Farrell
- Re: [TLS] preliminary AD review of draft-ietf-tls… Kathleen Moriarty
- Re: [TLS] preliminary AD review of draft-ietf-tls… Stephen Farrell
- Re: [TLS] preliminary AD review of draft-ietf-tls… Stephen Farrell
- Re: [TLS] preliminary AD review of draft-ietf-tls… Benjamin Kaduk