> GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist.
The GREASE mechanism is useful, but it will definitely make its way into code and become ossified itself. Example: https://github.com/salesforce/ja3 --Roelof ---- On Thu, 07 Jun 2018 17:05:47 -0400 David Benjamin <david...@chromium.org> wrote ---- On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk <bka...@akamai.com> wrote: 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.... I suppose the question is what the database is meant to be used for. I can imagine wanting it to be properly queryable so you can transform it into code. GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist. I can also imagine wanting to make it easier to allocate values mechnically. Then, yeah, you want the GREASE values in there. But the allocations need occasional human input anyway (e.g. 26 and 40), so maybe it's fine not to have those in there in a completely structured way? David _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
