Re: [secdir] secdir review of draft-ietf-tls-grease

Benjamin Kaduk <kaduk@mit.edu> Tue, 13 August 2019 17:57 UTC

Return-Path: <kaduk@mit.edu>
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 3D9A0120145; Tue, 13 Aug 2019 10:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Vs6fYFy-YK90; Tue, 13 Aug 2019 10:57:01 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B3612013A; Tue, 13 Aug 2019 10:57:01 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7DHuu3Z007269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 13:56:59 -0400
Date: Tue, 13 Aug 2019 12:56:56 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Carl Wallace <carl@redhoundsoftware.com>
Cc: Sean Turner <sean@sn3rd.com>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-tls-grease.all@ietf.org
Message-ID: <20190813175655.GO88236@kduck.mit.edu>
References: <D978436E.E80A3%carl@redhoundsoftware.com> <1BF964FE-2217-4063-B8F5-1FAC1FE050E5@sn3rd.com> <CAGNP4Bn5tha02L9-G7MzSXDE+rFppn5tL_NkBm4CM1Ahew__VA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGNP4Bn5tha02L9-G7MzSXDE+rFppn5tL_NkBm4CM1Ahew__VA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nIv97eQenDf0vxPmnSPfCe3dPYE>
Subject: Re: [secdir] secdir review of draft-ietf-tls-grease
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 13 Aug 2019 17:57:03 -0000

It's definitely worth asking, so thank you.

The version number space here seems particularly unique, in that it's not
maintained in a registry and in general each "codepoint" in the space will
have its own dedicated protocol and protocol document.  So in that sense
any act on the version number space cannot be tied down to a single
protocol version's document, and is instead part of the broader ecosystem
for the family of protocols.

-Ben

On Tue, Aug 13, 2019 at 12:00:15PM -0400, Carl Wallace wrote:
> OK. Impacting the version number stream was a new thing to my eye. Seemed
> worth asking.
> 
> On Tue, Aug 13, 2019 at 11:52 AM Sean Turner <sean@sn3rd.com>; wrote:
> 
> >
> > > On Aug 13, 2019, at 10:37, Carl Wallace <carl@redhoundsoftware.com>;
> > wrote:
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the IESG.
> > > These comments were written primarily for the benefit of the security
> > area
> > > directors.  Document editors and WG chairs should treat these comments
> > > just like any other last call comments.
> > >
> > > This document describes a mechanism to prevent extensibility failures in
> > > the TLS ecosystem.  It reserves a set of TLS protocol values that may be
> > > advertised to ensure peers correctly handle unknown values. Aside from a
> > > nit/question, the document is ready.
> > >
> > > The question relates to language in section 2. which states: "The values
> > > allocated above are thus no longer available for use as TLS or DTLS
> > > [RFC6347] version numbers." Should this draft be marked as updating 6347
> > > and 8446 as a result? At present it is Informational and does not update
> > > any other specifications.
> >
> > I tend to think that an updates header is not required.  RFCs that
> > allocate and reserve code points do not need to update the RFC that
> > originally created them.  For example, RFC5764/RFC7983 reserve a block of
> > TLS ContentType space and neither of the those drafts updated the base TLS
> > spec.
> >
> > spt
> >
> >