IETF Logo Mail Archive

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

Rob Sayre <sayrer@gmail.com> Thu, 14 July 2022 16:41 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 CA7A2C15949B; Thu, 14 Jul 2022 09:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_BLOCKED=0.001, 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 Ktdi-4ENSK9g; Thu, 14 Jul 2022 09:41:26 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 5875CC159485; Thu, 14 Jul 2022 09:41:26 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id fd6so3156256edb.5; Thu, 14 Jul 2022 09:41:26 -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=TiIzEEGnonp0dUWHqzAX6R5kHAJVIOH8xb1R0JZtVa0=; b=W2LM9E8R6I2Wkxd9o7IPlhUOLt2hWZ4aDHdfoHs3B5xNTYLtfT+gMdDgMO4I8RIdlB KYSEgSztDG6k0II3g2PElxq/rSRYrP/de1tMZcKlH7CN2WS8N69r5WmN2OXSAoam4Cd8 aaiw0zHKy4u/kg7VMq4B3T7LB27C7REnjIAAnG/7b26NwZrSKVQzqgQlHgLsL+x3DJ3I yT/ScJrKTNH9+CFpaKbjgNpK6sDNEt4KLqL2uqMlA0gACpvFs2osIucOdpoeZtNGp/Uf CuTcZXMGiGGkpRVljY3+gL2pYrc02VTJseN1O2wKOTCy9SxDdC3X7rR046qYcNwMyhni c0JA==
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=TiIzEEGnonp0dUWHqzAX6R5kHAJVIOH8xb1R0JZtVa0=; b=kDAaWyl6G2k7fTzRFKF8Rmy6uC++xpA2lsk7CgXLehEIJaEvHz6Heh4ZsW3OALufZq NIuOXdFWVgiNNq0pm7IUfRP/R800V/8qTZ9uWLrtBVHHJzorl7R85rwtgC6Swkj5QzFR s0k5PZQqhC+zHt4Vn6VN08R3pcgP7SCJvruxxRKYFq+Q4jfAVmGQEDmyjhQ8UhoAe+5u pdCOSyiZfF/QNUvXDKlHSkZwXT+2aw9uB/JuweQAFhc0tXWWWLqpcVrpwtAJ8zDKhbwp eP68wfdifyOYh3/BWfqWOGQkyL9i5C5cJ91BH/0ThwX4lANnSQtRmmcIEgw7RBza6AoZ pEDg==
X-Gm-Message-State: AJIora9blDD/NA9teF8xfg5PAk/ihByJ5r/8EGwxNKfph4APB2CK9SIB ME6Hsv+kMXf+5qtOQuwM0uSwlliw18p+5p/Csj4=
X-Google-Smtp-Source: AGRyM1t6gH1haJBdzMxD7TsRUjngtHIb5DKbKbUQx9Anf7c6q7kG0cDhk8O7ghSnAZ8nR682xwlLIx0RUAe3n6fG+H8=
X-Received: by 2002:a50:fa91:0:b0:43a:4f13:4767 with SMTP id w17-20020a50fa91000000b0043a4f134767mr13538390edr.10.1657816884624; Thu, 14 Jul 2022 09:41:24 -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> <CAChr6Sy2GmkGQfz93+EhfDGEVZuwvkE9NOMwn6XVr5qag_aVBQ@mail.gmail.com> <SY4PR01MB6251FE9DFBD849A9296D31AEEE889@SY4PR01MB6251.ausprd01.prod.outlook.com> <20220714050053.GT26442@kduck.mit.edu> <CAChr6SwBUFP==jMu9N6Ey9HfSJhExunB-0MtnWAAU7x=B=be1A@mail.gmail.com> <61cdc89b-fdb9-4c82-ae4a-a562cc66c12e@beta.fastmail.com> <CAChr6SxqxojHRM6YVk4dsrvghwSo5qf9i08khr4zsOoNDg8x1Q@mail.gmail.com> <DB9PR08MB65243D07D5CD032D3C02EC6F9C889@DB9PR08MB6524.eurprd08.prod.outlook.com>
In-Reply-To: <DB9PR08MB65243D07D5CD032D3C02EC6F9C889@DB9PR08MB6524.eurprd08.prod.outlook.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Thu, 14 Jul 2022 09:41:13 -0700
Message-ID: <CAChr6SwRydWZ6VGf+0A4sGcCG7MRNk3sNDksz505yM_AX4ca5A@mail.gmail.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>
Cc: Martin Thomson <mt@lowentropy.net>, Benjamin Kaduk <kaduk@mit.edu>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-uta-rfc7525bis.all@ietf.org" <draft-ietf-uta-rfc7525bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "uta@ietf.org" <uta@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000082c0c105e3c69291"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/uvQi2bWwHp55V3m_ul3D5fz2a2A>
Subject: Re: [secdir] [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: Thu, 14 Jul 2022 16:41:26 -0000

On Thu, Jul 14, 2022 at 4:34 AM Thomas Fossati <Thomas.Fossati@arm.com>
wrote:

> On Thursday, 14 July 2022 at 06:43, Rob Sayre <sayrer@gmail.com> wrote:
>
> > Sure, mandate TLS 1.2 support. That seems like a really good idea.
>
>
>
> This statement is slightly inaccurate: the document mandates support of
>
> a significantly restricted profile of (D)TLS 1.2 -- likely the same
>
> thing that Martin Thomson alluded to in another email when talking about
>
> the "good protocol hidden in there".
>

Right. Some believe that TLS 1.2 (2008) can be made acceptable with several
restrictions. One recent effort is from December 2021 (RFC 9155).

My point is that it should not be mandated in this new draft (revising a
2015 recommendation), but everything in the draft covering 1.2 is worth
documenting. I believe I made a very reasonable suggestion here: cover the
maximal-compatibility concerns for 1.2, but recommend 1.3 and don't require
1.2.

Further, the TLS WG doesn't tend to add new features to TLS 1.2, so by
requiring this older version the IETF would be mandating non-support for
TLS 1.3 features.

The document will send a message either way, though. I guess that's one way
of interpreting "rough consensus and running code".

thanks,
Rob

v2.23.0 | Report a Bug | By Email