Change:
Also fix the build. Some references were a little off.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
THere's a TODO for reserving "ignore/" ALPN.
NAME are you thinking: Protocol: ignore/1 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference: (This document) ... Protocol: ignore/10 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference: (This document)
I didn't have a particularly clear picture in my mind, TBH. We're not sending fake ALPN values or anything right now. ignore/[numbers] seems fine. Or maybe it would be better to drop the "ignore/" thing and just use the same two-byte pattern. "ignore/" makes it look like you should do a prefix check, which isn't really what we want...
NAME NAME NAME NAME NAME NAME PTAL because I think this is really the last "technical" point remaining.
NAME not sure what you mean by two-byte pattern. You mean things like "qz" "db" "r$" etc? If so, I agree that that is better.
Yeah. For the sake of consistency, I figure it could just be the same old 0x?a, 0x?a pattern that everything else does. (Though they then wouldn't be ASCII. Could pick some pattern that's ASCII if that's preferred.)
i think two random bytes is good (testing for non-ascii seems greasy as well)
I also prefer the two-byte pattern, since ignore/ might indicate to people that this is somehow meant to be special-cased.
Two bytes it is! URL

Discussion:
1. <del> The TLS protocol RFC8466 includes several points of extensibility, </del> <ins> The TLS protocol RFC8446 includes several points of extensibility, </ins> including the list of cipher suites and the list of extensions.  The values in these lists identify implementation capabilities.  TLS follows a model where one side, usually the client, advertises

consistent pattern while avoiding collisions with any existing applicable registries in TLS. <del> The following values are reserved as GREASE values for cipher suites: </del> <ins> The following values are reserved as GREASE values for cipher suites and ALPN identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}

{TBD} 0xC5 {TBD} 0xE4 <del> Finally, this document reserves all ALPN identifiers RFC7301 beginning with the prefix "ignore/".  This corresponds to the seven- octet prefix: 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x2f. </del> 3. Most extension points in TLS are offered by the client and selected

cipher suite interoperability testing and it's suggested that IANA use these values for assignment. <del> [[TODO: How do I write IANA instructions to reserve all ALPN identifiers that begin with "ignore/"?  Perhaps it would be better to reserve a concrete handful of identifiers instead.]] </del> <ins> This document updates the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry, available from <https://www.iana.org/assignments/tls-extensiontype-values/tls- extensiontype-values>: </ins> 7.