Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[Benjamin Kaduk <[e-mail]>]

On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> Hi all,
> 
> Apologies for the probably record time delay in actually updating this
> thing. I like the graph... apparently -00 was expired for nearly twice as
> long as it was valid? Oops!
> 
> Per the discussion from a really really long while ago, I've rebased the
> document atop TLS 1.3 and added values for the many more bits added in TLS
> 1.3.
> 
> Since TLS 1.3 has server-offered extensions, this needed a bit of
> reorganization. For the one-bit PSK KE values, I borrowed the pattern from
> draft-bishop-httpbis-grease-00.
> 
> Let me know if folks have any comments. Additionally, I'm curious what
> folks thoughts are on the following (not incorporated into the document):
> 
> 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to
> parse out the "ignore/" string. Instead, what do folks think about just
> using two byte strings. Perhaps the same two byte pattern we're currently
> doing?
> 
> 2) This is somewhat of a "how much badly I abuse the registries" thing. :-)
> I have observed one TLS implementation which just transcribed the registry
> directly into their source code. This was done all the way down to mapping
> "Reserved for Private Use" to some dedicated symbol. They successfully
> ignored the private use value, but the actual unallocated values for each
> of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and
> treated as syntax errors!
> 
> This was just a single implementation, but it suggests GREASE works better
> when it's not so obviously allocated in the registry. Of course, not
> recording the values at all is unreasonable as we must avoid allocating the
> values for real. What do folks think about leaving them out of the table
> but instead adding a note in the registry like:
> 
> "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A,
> 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used
> by [[this document]] for testing implementation correctness. They should be
> left permanently unassigned."
> 
> An implementor infinitely bad at reading may well still special-case the
> and defeat all these measures, but that was always the case. Rather, the
> goal is to find inexpensive ways to lower the failure probability. It seems
> inexpensive to me, but I don't know how much trouble it would cause for
> IANA.

Unfortunately, (my understanding is that) IANA is moving towards a proper database
for codepoints, and prefer to actually have all values matched up with their
corresponding metadata; I expect that they would not be happy to do something
like this.  But, of course, we should actually ask instead of guessing...

-Ben