Re: [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: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92A03A0F0B for <last-call@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 1QNeR8aElMa0 for <last-call@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 1B63C3A0F0C for <last-call@ietf.org>; Fri, 27 Nov 2020 20:58:51 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id b17so8175643ljf.12 for <last-call@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=lNnlqpOwBieIKseFlhreXjrDhW7lwpiyBvmW4kr2RM8Q+dvLB58wqZ5C0uZSyorKxy kv1pJVy/8dsMkve2BfbWa3FvTqgyyXEPGa/ocCf/G3e4sHA1CYpW86FTpI52I8Kf+Kyd tZz57KjmR8E6XrEDhRi5QSsv4JuAvh2KeRzikQLSam+5gTyksJZ88bNz2Hq93II8RD+8 V6/AEN3f+CPwQ2wNYKD2thd1/p+oepg6Wjl8+8DU9fCcAoiBo2qsMALhr3Lic+e/x7NZ iT/BWt3BIHszOj4U8ilNqBy2asN5RAvTXD37ggPraoUH79iDydddJmaq8+pQvAVGv8QD C2OA==
X-Gm-Message-State: AOAM531FnWfO1XWyZn11LQ58Z1cvPieKUlB0NESmrKMVFDlOBaN5b9kh Kt77ov4+J9bBE9nIypQT9Xdu3uqL4Z/doq08zViJyw==
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/last-call/QEqFpF4IXcmt_P-vVMjPqTj1Mpg>
Subject: Re: [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Nov 2020 04:58:54 -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