Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
Benjamin Kaduk <kaduk@mit.edu> Thu, 10 October 2019 16:17 UTC
Return-Path: <kaduk@mit.edu>
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 BCD7412006E; Thu, 10 Oct 2019 09:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 ceiKy_S2xuvK; Thu, 10 Oct 2019 09:17:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 352A71200DF; Thu, 10 Oct 2019 09:17:08 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9AGGw78005156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 12:17:00 -0400
Date: Thu, 10 Oct 2019 09:16:57 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rob Sayre <sayrer@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>, Sean Turner via Datatracker <noreply@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>, IESG Secretary <iesg-secretary@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Message-ID: <20191010161657.GA76545@kduck.mit.edu>
References: <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <CAChr6Sx4AVjkoKWiD2-cT2ZBNg=mKzeOX603gVs0f7vQ_FgN7A@mail.gmail.com> <CABcZeBNOVOBifOSnWdxSDTLizUUUn6ctLrBT43CHK+4B7KWGiQ@mail.gmail.com> <CAChr6SzT3GqmidPbmVjmrZX=u1UpBee4e8K2C-zHuNHEqgB7uQ@mail.gmail.com> <CABcZeBOGjPYy9FaOzaf-bHKaoMtXpO0SjQO5RTx9fMUo3r8vUg@mail.gmail.com> <CAChr6SwjdhpL2jQgNVjjuLosa8ycZEi9rGHuZ=K8=ToRy-gfJw@mail.gmail.com> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> <CAChr6SyhpUWoyhDiCp-UQ49HYVK-=Mk8DdXSpcAGK9hm+p00MQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAChr6SyhpUWoyhDiCp-UQ49HYVK-=Mk8DdXSpcAGK9hm+p00MQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1cuCwn4taAwCf11EwErNxP75dyU>
Subject: Re: [TLS] Publication has been requested for 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, 10 Oct 2019 16:17:10 -0000
On Tue, Oct 08, 2019 at 08:25:51PM +0700, Rob Sayre wrote: > On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > it's largely up to the sponsoring AD. > > > > Is that true? I'm not sure which procedure you're describing. Per https://www.rfc-editor.org/current_queue.php , draft-ietf-rctweb-security-arch is in the RFC Editor queue, state "EDIT*R" (copyediting, with some extra task for the RFC Editor staff, presumably v2-->v3 XML conversion). As far as the IETF is concerned, the document is done and approved, and the only changes expected are editorial ones made by the RFC Editor and editorial ones made during AUTH48. Any substantive or technical changes during AUTH48 require at a minimum approval by the sponsoring AD, and if substantial enough, approval from the WG and possibly re-running IETF LC and IESG review. While it's true that we can do the latter procedures at any time until the RFC is officially published, it's a pretty heavyweight process and we generally only do it when there are actual technical errors, and not just for things that we might do differently if we were starting from scratch now. The decision about whether to make changes to the technical content thus lies with the sponsoring AD for that document. > At any rate, I think one issue is with the abstract > of draft-ietf-tls-oldversions-deprecate: > > "This document also deprecates Datagram TLS (DTLS) version 1.0 [RFC6347] > (but not DTLS version 1.2, and there is no DTLS version 1.1). > This document updates many RFCs that normatively refer to TLSv1.0 or > TLSv1.1 as described herein. This document also updates RFC 7525 and hence > is part of BCP195." > > What it doesn't do is state that it updates RFCs that normatively refer to > DTLS 1.0 and/or DTLS 1.2. It seems like it should, since RFC 6347 states: > "Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate > with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS > 1.2 implementations can interoperate with previous versions of TLS...". I disagree that draft-ietf-tls-oldversions-deprecate needs to update all consumers of DTLS 1.0/1.2, at least for the reason you give. Those documents properly refer to RFC 6347 (or 4347), and it is that RFC that we are updating now. We do not directly change those consuming documents' needs, but rather do so indirectly. > Although I favor deprecating DTLS 1.0 conclusively and thoroughly, there is > an argument for eliding DTLS entirely > in draft-ietf-tls-oldversions-deprecate, NIST SP800-52r2 explicitly states > that it doesn't cover DTLS, but that document is the only citation in the > "Support for Deprecation" section of draft-ietf-tls-oldversions-deprecate. That's a fair question to ask, and I trust the chairs to shepherd any additional discussion needed. That said, since DTLS is basically a small delta on top of TLS, if we are deprecating a TLS version for cause, it seems likely to me that it is also appropriate to deprecate the closely related DTLS version. > Updating in-flight documents to avoid citing soon-to-be-deprecated TLS RFCs > is something I expect Area Directors to be doing. It's a predictable > problem. Sure -- drafts coming in for IESG review are going to get flagged for any (D)TLS 1.0 usage. However, I disagree with characterizing draft-ietf-rtcweb-security-arch as "in flight" -- from the IETF perspective it's approved and done, and the barrier to making any further substantive changes is extremely high. -Ben
- [TLS] Publication has been requested for draft-ie… Sean Turner via Datatracker
- Re: [TLS] Publication has been requested for draf… John Mattsson
- Re: [TLS] Publication has been requested for draf… Kathleen Moriarty
- Re: [TLS] Publication has been requested for draf… Stephen Farrell
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Sean Turner
- Re: [TLS] Publication has been requested for draf… Stephen Farrell
- Re: [TLS] Publication has been requested for draf… John Mattsson
- Re: [TLS] Publication has been requested for draf… Benjamin Kaduk
- Re: [TLS] Publication has been requested for draf… Cullen Jennings
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… John Mattsson
- Re: [TLS] Publication has been requested for draf… John Mattsson
- Re: [TLS] Publication has been requested for draf… John Mattsson
- Re: [TLS] Publication has been requested for draf… Benjamin Kaduk
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Stephen Farrell
- Re: [TLS] Publication has been requested for draf… Sean Turner
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… John Mattsson
- Re: [TLS] Publication has been requested for draf… Stephen Farrell
- Re: [TLS] Publication has been requested for draf… Benjamin Kaduk
- Re: [TLS] Publication has been requested for draf… Daniel Migault
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Martin Thomson
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Eric Rescorla
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Benjamin Kaduk
- Re: [TLS] Publication has been requested for draf… Rob Sayre
- Re: [TLS] Publication has been requested for draf… Benjamin Kaduk
- Re: [TLS] Publication has been requested for draf… Rob Sayre