Hi both, On 29/07/2019 23:52, Steven Valdez wrote: > Without GREASE, a server who doesn't have keys can't respond with any of > the existing responses (esni_accept is wrong since it can't decode the > ESNI, esni_retry_request is wrong since it can't provide keys for the > client to use on the retry). The only valid response would be a new record > type that says it doesn't support ESNI, which becomes equivalent to just > not sending the ESNI extension back in the EncryptedExtensions. > > With GREASE, I don't know if it's particularly useful to fake the response > in the EncryptedExtensions, since network adversaries won't be able to see > the contents, I suppose its presence might slightly change the size of the > encrypted payload, though record padding could prevent that.
Right it's the size that matters;-) I don't care if that's via this extension or not. ISTM that yes, producing a response to greased ESNI that doesn't stand out is an accepted requirement. And for the case in point, I think (but don't claim to be right) that a 50:50 distribution of ~16 payload octets or else ESNIKeys-sized things seems right. On 29/07/2019 23:53, Ben Schwartz wrote:> It sounds like you're asking for a middle ground for servers between > "supports ESNI (and has ESNIKeys)" and "doesn't support ESNI". > Maybe you could explain the utility of this middle ground? > > From my perspective, I'd rather encourage real implementations > of ESNI than enable fake ones. Agreed. Not that documenting a corner case is encouraging the corner case of course:-) That seems more like being as complete as one can. I suspect this is more an issue about what code to write for a server instance that boots but hasn't yet gotten the values for ESNIKeys loaded for whatever reason. Or where disk access fails for a while. Or where... <insert weird case here>, but the server code still has to do something. Cheers, S. > > > On Mon, Jul 29, 2019 at 3:34 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> >> On 29/07/2019 23:32, Steven Valdez wrote: >>> A server that doesn't have ESNI keys configured shouldn't be responding >> to >>> ESNI and should instead just ignore the ESNI extensions (as if it didn't >>> know what it was). >> >> Why? >> >> Thanks, >> S. >> > >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
