Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

Daniel Migault <daniel.migault@ericsson.com> Tue, 08 October 2019 13:22 UTC

Return-Path: <mglt.ietf@gmail.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 5EF6212004E; Tue, 8 Oct 2019 06:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.476
X-Spam-Level:
X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 iqucOV7uzDeW; Tue, 8 Oct 2019 06:22:41 -0700 (PDT)
Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) (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 CEC5E120086; Tue, 8 Oct 2019 06:22:38 -0700 (PDT)
Received: by mail-vs1-f68.google.com with SMTP id z14so11249742vsz.13; Tue, 08 Oct 2019 06:22:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=89+P+fMyM2I6EF/E0+oplCDwbQ0Ubi9ZRzk+OnnBsW0=; b=hBPusKXcngGEe1xPZkshlszAU6hPnCSIKRkClGNnFOPz8B/ej40ThJz7/g7mocZ+ow vuHHfQtXV8JuOjYHoCArx20Dj9lZpTsMAusjYGxtu2UnhXnZgxd9Zood6pWuioZmHlIT kZcM/FDy66Stg9F2sJ28LoHqqxnBqabv9qsracMYyAXaVfkWKzG40ySk8dZfmnfip2R+ 67FzPISq/Tb4MUPsYGjGOeSv4AtWbxmJby5sMp0hUFloxbQ5bYNH8YbPLKkOiT8k4j0Z /nH5t1HMCqwVwSL0Ii8jeY5tj+VGHkiVpoxNmZFUO7curAk3VclSuIc3A5HMz4/dFBuf VGbw==
X-Gm-Message-State: APjAAAVyvbjHwnJlIYVMnIOCikqsfmv7SRLJST8tZwqPDUaCG7Be7Il9 JUOzTnLzngSPtC80RX8YCwngbnXDfgE3EdIcP7PQ4p93L7g=
X-Google-Smtp-Source: APXvYqzE4RHPi4CeKY+nubvAmsT77NhS1XwGuzjtb7IgB21U/M7gPFmcnOnvgLnXQlprieh3pUyhcqfuy5IsesW60N4=
X-Received: by 2002:a67:c297:: with SMTP id k23mr17634430vsj.31.1570540957838; Tue, 08 Oct 2019 06:22:37 -0700 (PDT)
MIME-Version: 1.0
References: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <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>
In-Reply-To: <20191008120506.GF76545@kduck.mit.edu>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 8 Oct 2019 09:22:23 -0400
Message-ID: <CADZyTkkvVk-0t-x0YNQwNcHYbK_kUqPNLk2xzy9VrKB694oqGg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Sean Turner via Datatracker <noreply@ietf.org>, IESG Secretary <iesg-secretary@ietf.org>, "tls@ietf.org" <tls@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e5b2dd0594660f7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nvIeroYH8XgFuYVdOrad3vjKHyY>
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: Tue, 08 Oct 2019 13:22:42 -0000

Hi,

For clarity to the WG I am summarizing the discussion of the "lesson learnt
from deprecation" thread.

There is in my opinion a consensus that the current text does not emphasize
enough that TLS 1.3 is the current version of TLS. There is also a
consensus that the current draft limits the wording in emphasizing that TLS
1.3 obsoletes TLS 1.2 and is the current version to consider.

The current texts that are subject to changes are the following:

TEXT A:

"""The expectation is that TLSv1.2 will continue to be used for many years
alongside TLSv1.3."""

Proposed alternatives are:
a) remove the sentence
b) leave the sentence as it is
c) clarify the sentence for example with the following text:
""" While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is
strongly RECOMMENDED to consider the adoption of TLSv1.3"""


TEXT B:

"""TLSv1.2 has been the recommended version for IETF protocols since 2008,
providing sufficient time to transition away from older versions."""

Proposed alternatives are:
a) leave the sentence as it is
b) clarify the sentence for example with the following text:
"""The current recommended version for TLS is 1.3 and version 1.2 has been
recommended since 2008, providing sufficient time to transition away from
older versions."""

TEXT C:


"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

Proposed alternatives are:
a) leave the sentence as it is
b) clarify the sentence for example with the following text:
"""Deprecation of these versions is intended to assist developers as
   additional justification to no longer support older TLS versions and
   to migrate to a minimum of TLSv1.2. At the time of writing this document
this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly
RECOMMENDED. If TLSv1.2 were not supported yet, adoption of TLSv1.3 is
RECOMMENDED.  Deprecation also assists product
   teams with phasing out support for the older versions to reduce the
   attack surface and the scope of maintenance for protocols in their
   offerings.
"""

My personal opinion is to have some text that reflects what we think.

Yours,
Daniel

On Tue, Oct 8, 2019 at 8:05 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > On 07/10/2019 18:29, Rob Sayre wrote:
> > > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> > > wrote:
> > >> we can't "UPDATE" an I-D.
> > >
> > > Not true. If you need to refer to something that's been IESG-approved
> but
> > > still in the RFC queue, you can leave a note for the RFC editor to
> update
> > > the reference to the eventual RFC number.
> >
> > That would be an UPDATE on the eventual RFC and not on the
> > I-D. And in this case, it'd IMO not be a good plan as a) the
>
> Recent IESGs have been taking the stance that it's weird to have "Updates:"
> to a document that's not yet an RFC, mostly preferring to pull the document
> in question back and get changed directly.  But ...
>
> > relevant WG didn't want that, b) the I-D in question is part
> > of a mega-cluster, so any dependency on it (as you suggest)
> > risks loadsa delay if the cluster doesn't get unstuck, which
> > can happen and c) our draft already stretches the header
>
> .... given that C238 is unblocked, dependencies-wise, that seems
> questionable in this case.  (The whole set of documents does have to go
> through the xmlv2-->xmlv3 conversion, though.)
>
> > enough updating 85 RFCs - trying to add an I-D to that list
> > would break tools and cause much pointless process-angst.
> >
> > Mostly (a) is the reason to not do it though. If you want
> > to disagree with (a), then the right list for that would be
> > the rtcweb list I guess, even though the WG is now concluded
> > (which could, I guess, be (d);-)
> >
> > Overall, the cost isn't worth the benefit IMO.
>
> That's roughly where I'm landing, too, though as noted previously, it's
> largely up to the sponsoring AD.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>