Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

Daniel Migault <daniel.migault@ericsson.com> Fri, 27 September 2019 15:07 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 86AAD12086E for <tls@ietfa.amsl.com>; Fri, 27 Sep 2019 08:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 43m3aEP-NokN for <tls@ietfa.amsl.com>; Fri, 27 Sep 2019 08:07:23 -0700 (PDT)
Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 0D00A120869 for <tls@ietf.org>; Fri, 27 Sep 2019 08:07:18 -0700 (PDT)
Received: by mail-ua1-f49.google.com with SMTP id l13so2042470uap.8 for <tls@ietf.org>; Fri, 27 Sep 2019 08:07:18 -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=dGTcH215wna+wMngd8flamZYTB24hTyEkSLibvt8azk=; b=uTxzOT9uK2DvrwLcT2Y4Ep8KeKkrjdHLrd18yPdFv8zhRLtypBQrPnN7hFowe8T6TZ vWY3EY2vu+u01qcIZVeR91h7f6m4rM2PhteIu+9Eegcf5IajfMTX/TAWLL3Zdhzonib9 cehve4CQ700Y1jsgi4PqGhuuPreT2ZKTnbXF+ErOFibN4vIjxMVlgqIz4d0hfNnbP9JP jpChm84JlZPnWfSnS6vTXvAfGZ/atnmIedwVAiaKdWXbQlzXOeTwCXvdi63QM+c0ZMdQ LhEkjaK5fbGfQ9i2OHfaTJgzWsIODgYyNuy9pVkp8KIQWNY9lQB6QkYxgJ8Adl/itnQR Wn3g==
X-Gm-Message-State: APjAAAUqlCmfNWJjywIH8LYBUrV39t3rXf4orilSAO6CHJNLofcLd8sj auEUmZe+QCjgu35nArXE9DrsNlspNX2tDP8iUXL891yK
X-Google-Smtp-Source: APXvYqzTW9MC0QXGvLD1OhuOPc4Vg2YzMsh3CQCCTrmQZYwLHDCq7LbDmHdwCq9mpey+o0Ypz/kQ7/OYQodaqeH99hU=
X-Received: by 2002:ab0:6897:: with SMTP id t23mr4808841uar.88.1569596836742; Fri, 27 Sep 2019 08:07:16 -0700 (PDT)
MIME-Version: 1.0
References: <BF5F63A6-105B-47C6-8B65-29A290A16E76@akamai.com> <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <CADZyTknH0ivQc-xW-di1XKC7w-9A5TCF8vhLLCrR9jQbcqY5dw@mail.gmail.com> <d4b01c69-6047-467b-8538-9780f6872fe1@www.fastmail.com> <80881fa1-97df-56c9-10c5-f9e754b6cdb6@cs.tcd.ie> <d865244a-9ce8-4d95-b62c-ba52fa198126@www.fastmail.com> <77112123-822b-0aaa-6cc7-159167637916@cs.tcd.ie>
In-Reply-To: <77112123-822b-0aaa-6cc7-159167637916@cs.tcd.ie>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 27 Sep 2019 11:07:05 -0400
Message-ID: <CADZyTkmn1jq5YW4owp-yv3tA20ZgU_m4yQ1ophnkKNzhsYiB7A@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Martin Thomson <mt@lowentropy.net>, tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e50aa405938a3daf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/la8ojMmI59sLMkUApn4c-uUjZKE>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation
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: Fri, 27 Sep 2019 15:07:32 -0000

Hi,

Maybe I am missing the point, but I do not see any reasons to not
explicitly recommend adoption of the latest version (i.e. TLS 1.3).

While the document deprecates old version, providing explicitly the status
of the non deprecated versions seems to me in scope of the document. As
such, clearly stating that TLS 1.3 or the latest version is expected seems
to me better, but I am happy to hear otherwise.

Removing the sentence that mentions TLS 1.2 and TLS 1.3 will coexist for a
long time, does not carry exactly the same message as explicitly
recommending the adoption of the latest version. I believe explicit
statement will help adoption of TLS 1.3.

To be clearer, I am providing the alternate text I had in mind. Of course
feel free to change the wording.

abstract:


OLD:

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

NEW:

"""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."""

Introduction:

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

NEW:
""" While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is
strongly RECOMMENDED to consider the adoption of TLSv1.3"""


OLD:

"""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.
"""

NEW:

"""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 TLSv12.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.
"""

Yours,
Daniel

On Fri, Sep 27, 2019 at 4:46 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
>
> On 27/09/2019 04:50, Martin Thomson wrote:
> > On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote:
> >>>> """The expectation is that TLSv1.2 will continue to be used
> >>>> for many years alongside TLSv1.3."""
> >>
> >> So is your proposed change to only remove that sentence?
> >
> > I just checked, and it seems like the only thing the document says
> > along these lines, so yeah.
>
> Grand so. Like I said I don't think it's a biggie so I've
> commented out that sentence in the GH version. [1]
>
>   [1]
>
> https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt
>
> BTW - for the chairs/AD - how are we doing on getting IETF LC under
> way? I realise the world won't end if this isn't super-fast but it's
> been 3 months since publication was requested which seems like a bit
> of a while.
>
> Cheers,
> S.
>
>
> >
> >> Personally, I'm not that fussed. Including or omitting that seems
> >> not a big deal to me. If the WG are however keen on such a change
> >> that's fine too. OTOH, we've already done a bunch of process-steps
> >> with this process-draft so I do wonder if that change really
> >> amounts to a worthwhile thing.
> >
> > I do.  Or I wouldn't have written the email.  Do you think that this
> > is a valuable statement?  I think that it says that the IETF lacks
> > confidence in the suitability of TLS 1.3 as a replacement for TLS
> > 1.2.
> >
> > If you want a smaller change, s/many years/some time/
> >
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>