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

From: Carl Wallace <[email-masked]>
Date: Tue, 13 Aug 2019 10:37:34 -0400

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.

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Aug 2019 11:52:27 -0400

> On Aug 13, 2019, at 10:37, Carl Wallace <[email-masked]> wrote:
> 

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

---

From: Carl Wallace <[email-masked]>
Date: Tue, 13 Aug 2019 12:00:15 -0400

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 <[email-masked]> wrote:

> 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
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 12:56:56 -0500

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