IETF Logo Mail Archive

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

Rob Sayre <sayrer@gmail.com> Thu, 14 July 2022 00:29 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892DC159480; Wed, 13 Jul 2022 17:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, 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 YjX9NB0CRLZ5; Wed, 13 Jul 2022 17:29:20 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 5D7EAC157B43; Wed, 13 Jul 2022 17:29:20 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id oy13so638524ejb.1; Wed, 13 Jul 2022 17:29:20 -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=BsWohbYpH4Z/Ufpz/OygvTjDR8elpyp0Wpd8lQG44RM=; b=BhjQ5ig0eg6+2hui7ffNhkWndrnKQ81hnNcRTmtVnMIb8U2bBIFppigRkqEAIDCCxK AfNARFzYUQELbERR9hGKFXxyb/VaoisMahV9q+gi1gVB9gE6wLz2afQ5muxkwBMEzjN9 ilYFFyHJfEtQz2CmyfsjptTEGNxtMKXr9fdeJ0glkUleRj+qsfHCWNoGVc5MjFi36ogb Y4AtoSrMpSj3it1hHVxiB3DVCgZUIpsGG1H/tIt8uo++p6k5yU9y4rmfKUu5uZ/6FR1N v8JG6a0WD5+J58vb02awiwoFyBZRd7ajP6YGhPg6Wse+bY7lE5mye8IBz8FuX1WBrmYw A4JA==
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=BsWohbYpH4Z/Ufpz/OygvTjDR8elpyp0Wpd8lQG44RM=; b=V6ivqHJswnd9XJ12xIbhmIyo1JxXXIy9QKFWgHpLa6mQ5qdeWnlEtUrfI6JXaRKhGK hIPCsKbUmVmYJCvzO2kVGQKgXH14ZZCGxyN0KuZ+s1I9NHHsBivV+PV7XXNVKgFw83TZ ljFhJLky4ZdBHFYEUpfJoBJywudbNxAzu49BLnnq1pe4hUmxFL0xkAoqgBnAOybD+LqG ocsAMhNTRoamDJWESbHmCScpjF7U5BQ7TvQifshIi1A6JeMUMbGohaxVssgWphgvFvMW 3XTD0rAGBiyCBho2KYTOFGBC+eJZr9+LEJQksSToz2tbFsVYjJvaT4QHIDn15HXibYPH xq7w==
X-Gm-Message-State: AJIora9zOhppRYuQJ5cYz4YfKU4G4sICzGF4yUbcMmDz+SX6SBQEzKWy 6Zs2GMvYkNrRLpvphHa8ZWNvb6cd1+I4jajuNzw=
X-Google-Smtp-Source: AGRyM1v6apdchFvBA9kUvsh0iGOD9cGsxhT2rOvbxT0i1y08Gej5O154u/foaEM8oWl2aubjq+bULCrTVop4tVeL21o=
X-Received: by 2002:a17:907:6d8b:b0:72b:5f51:a9e7 with SMTP id sb11-20020a1709076d8b00b0072b5f51a9e7mr6194234ejc.628.1657758558362; Wed, 13 Jul 2022 17:29:18 -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> <c516d0e4-f477-a4fb-2638-3615434f48f2@stpeter.im> <CAChr6SwgwknvgAycr6s=6tCRQZoZdiJxRXJpoTejEcW7g+bv=A@mail.gmail.com> <359BC9EA-FB6D-49E8-8CA6-AA395114838B@akamai.com> <cd793161-3535-41f8-a6f3-ed5b160048c6@stpeter.im>
In-Reply-To: <cd793161-3535-41f8-a6f3-ed5b160048c6@stpeter.im>
From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 13 Jul 2022 17:29:07 -0700
Message-ID: <CAChr6Sy=Jm-jTRxcyy8fTY_6qFxufFcmwK_3NoRai-1Qe=h_kw@mail.gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "Salz, Rich" <rsalz@akamai.com>, "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="000000000000fea2f605e3b8fd74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/_uU1ao4wsmbKySEvilrJodTEvNg>
Subject: Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2022 00:29:20 -0000

Hi,

I think the main problem would be that the handshake is vastly different.

I don’t care which document the deprecation happens in, because I am right.

thanks,
Rob

On Wed, Jul 13, 2022 at 17:20 Peter Saint-Andre <stpeter@stpeter.im> wrote:

> On 7/13/22 3:00 PM, Salz, Rich wrote:
> >   * It is definitely the "BCP" already--there are good reasons not to
> >     support TLS 1.2 on a server, and good reasons for clients not to
> >     connect to a server that negotiates it.
> >
> > What are they?
>
> Good question.
>
> This document has been through two WGLCs and IETF Last Call, and is now
> in IESG review. It seems somewhat late in the process to be making a
> controversial change like deprecating TLS 1.2 *in this document* given
> that as far as I can see there is no IETF consensus to do so (e.g., such
> a consensus could be established by publishing an RFC that declares TLS
> 1.2 to be obsolete, as RFC 8996 did for TLS 1.0 and TLS 1.1). IMHO we
> could take this step whenever we publish rfc7525ter (the document that
> obsoletes draft-ietf-uta-rfc7525bis, whenever that happens).
>
> Peter
>
>

v2.23.0 | Report a Bug | By Email