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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> wrote:
> 
> >
> > > On Aug 13, 2019, at 10:37, Carl Wallace <[e-mail]>
> > 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
> >
> >