Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Eric Rescorla <ekr@rtfm.com> Sat, 28 November 2020 04:58 UTC

Return-Path: <ekr@rtfm.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 491B53A0F09 for <tls@ietfa.amsl.com>; Fri, 27 Nov 2020 20:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 cXf-y3-3F90M for <tls@ietfa.amsl.com>; Fri, 27 Nov 2020 20:58:51 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 185083A0F0B for <tls@ietf.org>; Fri, 27 Nov 2020 20:58:51 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id f18so8186213ljg.9 for <tls@ietf.org>; Fri, 27 Nov 2020 20:58:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MMqriOaRG4TwvIwY4j27nmpodzEFgKjYggw9y1jmLbI=; b=rKw8BMFCJ87WcUWiChfMQYNayNqmKv1z7jupEbIz85Pfx2GKX6yn9EQU4CzmhGpSSq V9XpEOCabjEVzk5/b8SbkqUDviw6suAC6iX/Qui310JRpV4chj9o50vH2EhyszaQIfbL AQkzbR21TM9s5OYTr3Bal7fLQ4MGAl1v0aPs1dhqZGetnzxJ/9CU10M3KnYKeF+hLFDH Bfectl4ZoX5OKkadyZ0CKvW1Swug3PD3mtXXgGxgZz/PaDcQOm0pgW+nmdmadTpRFnlw jOTa9ROqzDMnOy8jvTOnb0ovfrpSxOkrnNYU6c6IRgP1zY8dqSt5Wo6kyjqbeXRLx/DU JKvg==
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=MMqriOaRG4TwvIwY4j27nmpodzEFgKjYggw9y1jmLbI=; b=aKejbGNtDSzRS8TevYwvGqrNBpAzmV942dwccrMlEsuT4jHB/cIxJTtgbjvGoZQTD8 vrfodZXli0vSYlA+00/mte4pZlgHq79t0Y1c9bDiIhrddUeLRzaB5CIxUmlqQYM+liOU TXsObV6tcCMOVkmhSFyU0ug7RY1CekTeGb89gzboKFo3+aJbiJg5VbtHvZRMxhcuTWeS hulxoo0xsFdoWmi0h0hwG7IKtx79QiX+9NORCq+jo1uPSXL5nEAa3lhZrLiEKyvmkKkv WhpPfwFS31BEsdaZCh6nv700Ynuu8mx7lPyd4B4bYJoeAknhI8nwMoxnm3DPSas37dIf eZig==
X-Gm-Message-State: AOAM533g14hSSsWzDfjvq/am6ow59tgyOi9TDZS/LqMFHoiXf3W/HTWh Wk7gFtczpDlQ0Eml/6u0cpq51sqAZjW//MH5qc1vmg==
X-Google-Smtp-Source: ABdhPJwQecP+3y9QZFM7rzb7pdmbBoU3FGOhAemqvT1YIzXYuJhz6r+Rjc+nv0D68LYIsBOUvqtgb2NK5sJGa9Gnom0=
X-Received: by 2002:a2e:9614:: with SMTP id v20mr5072114ljh.13.1606539529355; Fri, 27 Nov 2020 20:58:49 -0800 (PST)
MIME-Version: 1.0
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <49d045a3-db46-3250-9587-c4680ba386ed@network-heretics.com> <CABcZeBPCccfDuGyZC-y88-dapjWYy57YRWWK3vsFOGM5Bxa+8Q@mail.gmail.com> <584c7749-6986-0329-873c-2d1ff8b55251@network-heretics.com> <CABcZeBNmzSV38Hm+cpas=hAO3RvV2V6nCkRUM2NkBM8mG7bdBg@mail.gmail.com> <7e1af512-ba45-5d9a-6538-518179ab2c3a@network-heretics.com>
In-Reply-To: <7e1af512-ba45-5d9a-6538-518179ab2c3a@network-heretics.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 27 Nov 2020 20:58:13 -0800
Message-ID: <CABcZeBMW9H=mxRyY=2OKAP1FkGpaniuH2FXCW5mUcAVx=GVRgA@mail.gmail.com>
To: Keith Moore <moore@network-heretics.com>
Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate@ietf.org, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f7152705b523a10d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TXT3EmIu_gjp3uLJRDiaDdxDU7k>
Subject: Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
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: Sat, 28 Nov 2020 04:58:53 -0000

Well, I think our respective positions are clear, so I'll just limit myself
to one point.

On Fri, Nov 27, 2020 at 8:43 PM Keith Moore <moore@network-heretics.com>
wrote:

> >
> >
> > > > I'm not sure what clients you're talking about, but for the clients
> > > > I am aware of, this would be somewhere between a broken experience
> > > > and an anti-pattern. For example, in Web clients, because the origin
> > > > includes the scheme, treating https:// URIs as http:// URIs will
> have
> > > > all sorts of negative side effects, such as making cookies
> unavailable
> > > > etc. For non-Web clients such as email and calendar, having any
> > > > kind of overridable warning increases the risk that people will
> > > > click through those warnings and expose their sensitive information
> > > > such as passwords, which is why many clients are moving away from
> > > > this kind of UI.
> > > UI design is a tricky art, and I agree that some users might see (or
> > > type) https:// in a field and assume that the connection is secure.
> >
> > In the Web context this is not primarily a UI issue; web client
> > security mostly does not rely on the user looking at the URL (and in
> > fact many clients, especially mobile ones, conceal the URL). Rather,
> > they automatically enforce partitioning between insecure (http) and
> > secure (https) contexts, and therefore having a context which is
> > neither secure nor insecurecreates real challenges. Let me give you
> > two examples:
>
> To clarify, my suggestion was that https with TLS < 1.2 be treated as
> insecure, not as neither secure nor insecure or any kind of "in between".
>

Well, the problem is that it is secure from the perspective of the site
author
but insecure from the perspective of the client. That's not going to end
well
for the reasons I indicated above.

Regardless, this is not likely to happen on the Web: browsers are already
converging on simply disabling older versions, and I doubt are going to
have any interest in the approach you propose.

-Ekr