Change:
padded_length The length to pad the ServerNameList value to prior to encryption.  This value SHOULD be set to the largest ServerNameList the server expects to support rounded up the nearest multiple of 16. <del> If the server supports wildcard names, it SHOULD set this value to 260. </del> <ins> If the server supports arbitrary wildcard names, it SHOULD set this value to 260.  Clients SHOULD reject ESNIKeys as invalid if padded_length is greater than 260. </ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in

Discussion:
See discussion at URL
I am not a fan of this change. I don't like encoding this kind of restrictive choice in the protocol.
OK, I've removed the protocol change and made the restriction purely advisory.
Stephen Farrell pointed out on the list that 260 is rather a lot of waste to stick into the ClientHello. URL 260 characters is this large of a hostname: It's probably reasonable to recommend a smaller default value like 64 or 96 or 128. (Numbers pulled out of a hat. I have no data on how big it actually should be.)
Yeah. The question is if we are happy with hostnames longer than the threshold (e.g., 64, 96, 128) sticking out. I think the current design of allowing the server to choose the correct value is the right approach. OTOH, regarding the size you'd use for greasing, I can understand the concern of wasting bytes. Maybe browsers can use smaller sized payloads when greasing the ESNI extension, under the premise that they would be sometimes using the maximum. The size of the extension being different from when it is actually used does not matter in practice, because an observer can typically tell if ESNI was used by checking if the unencrypted SNI record contains the fallback domain name (here I assume that we adopt ).
Agreed that letting the server choose the correct value makes sense. But I think the specification should also be opinionated about this, so we don't get wildly different values for everyone, and so implementors have something to pick if they don't really care. The closely thing the spec currently has to an opinion is 260, which is kind of large.
Absent data that shows there's a tighter upper bound, I would prefer to keep the 260 recommendation and perhaps suggest that servers may choose something smaller if they know better.
According to RFC 1035 host names can be up to 255 octets. I don't think this has changed. So if this document makes a recommendation it should cover the worst case. Someone could argue for something more efficient. For instance, if we were to do draw the distribution of name lengths we would find that the median is 13 characters. (An excellent number) Min is 4 and max is 117. (Source: URL) But this can change and the recommendation in this document will become outdated.

Maybe add something like the following: "servers COULD tailor the padding length to cover the longest name associated with the hosts they handle." (And keep the existing number)
In the current text, the "260" number only matters for GREASE; anyone who actually publishes ESNIKeys SHOULD choose the smallest number that covers their names, "rounded up to the nearest multiple of 16". Given NAME data, the most common choices will likely be 16 and 32. This state of affairs makes GREASE less effective, because (1) it doesn't resemble real usage and (2) it isn't exercising the length "joint". As a solution, I would propose recommending that GREASE clients choose a valid length at random. If we want to get fancy we could say that the random choice may be non-uniform (to favor shorter ClientHellos) but should have at least x% chance of choosing each length option. Also, instead of saying that the paddedlength "SHOULD" be 16*N or 260, I think we should consider a "MUST", and/or a denser encoding (e.g. enum with values 0..16). Otherwise, we have to figure out what clients should do if is huge. (I wonder how that interacts with QUIC and DDoS...)
Another proposal is mentioned in of just compressing these bits instead
NAME this should be fixed, with new recommendation text, via . Please re-open if not!
LGTM. Thank you for the text!The recommended text LGTM. NAME NAME NAME please have a look. Hiya, Various bits'n'pieces below... On 13/02/2019 23:55, David Benjamin wrote: Not just that. ESNIKeys is a fairly complex structure that has a number sets/sequences of values. There are various possible deployment models. The current structure assumes that it's ok to encode all that stuff up in one TLS style blob and then put that in the DNS. That might not make sense for some deployments in particular where the DNS operator is not closely tied to the TLS server admin or where there's 1 DNS operator and N TLS server admins (for the same origin). And then there's the use of the TXT RR.

But I agree this is orthogonal - I was mostly saying that in agreeing with this PR I continue to think the DNS RR stuff needs other work. Then delete it:-) Disagree. "Just describing" does not match the use of a meaningless marketing term like "trusted blah proxy" sorry. Better to avoid all that fuss really, no? I don't recall that having a concept of it being possible to "correctly" implement breaking the TLS protocol? (As is inherent in being an MITM.) It may be ok to live with such fallback whilst ESNI is being introduced but I think ongoing support for it would be unwise. And such a fallback requires no discussion of MITM attacks. (Other than as an attack.) I object to that term again, sorry:-) It's marketing meaninglessness. "MUST NOT surface" seems like bad phrasing then. That would be ok. Saying that requires no discussion of MITM attacks. (My openssl code would actually make that visible to the application if the application called a status API, but the TLS h/s would have failed from the application POV even if the h/s looks like it worked on the wire.) I'd guess that some implementers may be put off by the wasted bandwidth. Others won't care but if it's the case that sending a bogus ESNI x% of the time gets as good a result as sending all the time (which is how I interpret what the SHOULD calls for) then it seems better to encourage x% and not 100%. "The client" in almost all IETF specs means a thing that really implements the spec. So in this case, yeah, I think it might be good to say that a TLS client implementer who only has time to grease and not do the real thing is still doing good overall by just doing that.

(That said, I've no idea if there'd ever be such an implementer, though when we did DKIM there were many mail receivers who parsed but didn't actually check signatures - maybe mail implementers are more slapdash though:-) Yeah, and I disagree with that too:-) Regardless of the above disagreement about 260, if a client has been sending a bunch of CH's including real ESNI that are about 400 bytes because some server's ESNIKeys says to pad to 160, and that client then sends 600 bytes CH's to everyone else, I think it'd be crystal clear which is grease and which not. Cheers, S. >