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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
