Re: [secdir] [EXTERNAL] Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

Rob Sayre <sayrer@gmail.com> Sat, 16 July 2022 06:32 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F8BC14CF1E; Fri, 15 Jul 2022 23:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xk98nEBLxBp; Fri, 15 Jul 2022 23:32:43 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EB9C159480; Fri, 15 Jul 2022 23:32:43 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id m16so8725394edb.11; Fri, 15 Jul 2022 23:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GA5Z7X55EQQLzCdhErdSXgpIhEKDu6zNx/m41xclv68=; b=UFvDsdlBHzgfwoWDMxAT8J2BMuTwp7hznDgwHJYZRBgY4xi/Ta3MLN3zdKjH8rr1Wy dxsOCPxojKGl+CRoL8HYlI6IhOTekvSovgXNbS90jKH41yd6toUNu9pPVlZJeQWKhpcV wVjjAwBXQShWWrg2uNmxFMl2RAAdUbVuSz/3LmbOYOvXYNOXCa89oJLUCVe1rN+LQjb+ ndS3IvAgQ8xa5IIPax+VdxyKdzkOHci0ErFxWbHv61TfbxCqvo/lVUeISLQCecUChUSj FS5uVnfbjzsHvxiyTmjZ6aY0TJ+TFCpydJBSj8ICeKuJ42lc6ra/3kgY8USZaLrocYrC iAoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GA5Z7X55EQQLzCdhErdSXgpIhEKDu6zNx/m41xclv68=; b=KspbkCQW9K8R+V/WiIOV8Zy1Ar98+J4bZ6S5mE1nSixztdiNrUafDjuodD03s5Om41 Kz8hElNaYHApjNYYJkmlXpSCUNd4/bDFNUpnJvUKTxrrg+xt2uC9c7WAJOPkK8eof36p rwPIXOCRGok6y0sMDOumQi5hol7wdkA+NtKPv8OHjbG5G8sSZXnfQyZQA53pl882wDzi BEhrAvph7VUAE6ZtkIeABMMvplsP1rj74FcsGx4t28vY8PM8XWsphNyuag2vrqNkI4VJ c/RkTG41bidCzranBYqjoi4LcyzxCs82KupIHFZa/SH16QVWj9gr2yOy0aerx/fd5ZF4 CKiQ==
X-Gm-Message-State: AJIora+KnQMkaybZvvagUBLimrhd/p1qsCDI1wrW64NcjeGViVEUjTHq 9J29ETQS6X4oQy2vZCTzEkIYGldEv5U5RppG4T4=
X-Google-Smtp-Source: AGRyM1txlf/LijAKwI/EQhXcSjB9KtHN5NBTO1xiXDWPmYvVIGCdi8ZgO3V+Qqo+Mjct/diSYhtmFooqPBQFCtfoUJ0=
X-Received: by 2002:aa7:c98b:0:b0:43a:944f:5db6 with SMTP id c11-20020aa7c98b000000b0043a944f5db6mr23890442edt.34.1657953162212; Fri, 15 Jul 2022 23:32:42 -0700 (PDT)
MIME-Version: 1.0
References: <165766858084.5251.12485129434316295805@ietfa.amsl.com> <b24e2934-200f-4f80-5261-aa2a977da39b@stpeter.im> <CAChr6Syq+uOTJsvqWuSustq_HdTaXCtDepyCuRWx+jGoEB06Fw@mail.gmail.com> <CAChr6SzkAmbjGK4XOwPkSwssLoG4NW1yG-6b2aFdFr43yF2zwQ@mail.gmail.com> <SY4PR01MB625186377F07976EFEF775F7EE889@SY4PR01MB6251.ausprd01.prod.outlook.com> <BY5PR00MB0707E1335EB621253DB3BDA98C889@BY5PR00MB0707.namprd00.prod.outlook.com> <CAChr6SwoHicUAWQYggbVe_pg+TncE_mdq31ShoxgvJpywBXfbw@mail.gmail.com> <CH2PR00MB0711752EE2AB5B2EE20C91538C889@CH2PR00MB0711.namprd00.prod.outlook.com> <SY4PR01MB6251B5FFBC00A47B44AECB0CEE8A9@SY4PR01MB6251.ausprd01.prod.outlook.com>
In-Reply-To: <SY4PR01MB6251B5FFBC00A47B44AECB0CEE8A9@SY4PR01MB6251.ausprd01.prod.outlook.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Fri, 15 Jul 2022 23:32:31 -0700
Message-ID: <CAChr6Syq=kX1b==dbGBS5VpoOhYKMTPbdQTVmpOgQD4N7E146Q@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, Benjamin Kaduk <kaduk@mit.edu>, Peter Saint-Andre <stpeter@stpeter.im>, "draft-ietf-uta-rfc7525bis.all@ietf.org" <draft-ietf-uta-rfc7525bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "uta@ietf.org" <uta@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049baae05e3e64de7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_jHsLB3jYTr5UPaagkVSLEXMqyY>
Subject: Re: [secdir] [EXTERNAL] Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jul 2022 06:32:44 -0000

On Fri, Jul 15, 2022 at 19:48 Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> Andrei Popov <Andrei.Popov@microsoft.com> writes:
>
> >The TLS 1.3 adoption document you reference seems to be based solely on
> Web
> >browser data:


Firstly, this comment is not true. The document covers many interactions.
There are non-browser clients, embedded products, and server-to-server
interactions in there.


>
> This seems to be near-universal when TLS is discussed, see several previous
> examples of this on this list.  Just as any new medical breakthrough
> announcement needs to have the word "in mice" appended to it, so any
> discussion of TLS usage should have "on the web" appended to it unless it's
> explicitly not so.


I am not sure what to make of this comment that mixes a science reference
with a reference to the French Revolution.

I would say that it is common IETF behavior to claim that clients can’t be
updated, so everyone must shoulder the burden of backward compatibility.
Browsers show this is not the case, but this also true of my watch, router,
and power strip.

Maybe specifications shouldn’t do backflips to require support for 15yr old
protocols. I think it is fine to describe the results of dropping support.
That’s just the truth.

thanks,
Rob

>