I think the GREASE bits still need more work to avoid sticking out[*], but you're right that there's a length leakage. But, rather than 50:50 of 16 bytes and ESNIKeys, I think it's better to pad all three cases up to an ESNIKeys size. Whether this is done via bespoke padding within the ESNI extension or the existing record-level padding, I don't have strong opinions. With the server Certificate message, the draft currently just says to pad at the record layer, so that would be consistent here too.
Additionally, the exact sizes of the TLS messages also needn't be so obviously leaked. Servers can and should pack EncryptedExtensions, Certificate, CertificateVerify, and Finished together into fewer records, likely just one. This is worthwhile independent of ESNI. An encrypted record is 22 bytes of overhead, so packing four messages into one record saves 66 bytes. I don't know about other implementations, but BoringSSL already does this. Of course, unpadded, an attacker that knows the expected size of the other messages for a particular server can recover the EncryptedExtensions length, so this isn't perfect. [*] I filed https://github.com/tlswg/draft-ietf-tls-esni/issues/177 last week with a sketch of an idea. Steven or I should hopefully have a more concrete PR later. On Mon, Jul 29, 2019 at 7:03 PM Stephen Farrell <[email protected]> wrote: > > 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 < > [email protected]> > > 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. > >> > > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
