On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote: > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > the cookie can be up to 2^16 bytes long, even if client sends all 50 > > extensions and spaces them with unknown extensions between, that's at most > > 20 bytes per extension = 1000 bytes total extra space needed in cookie > > (32 bytes and 1600 bytes if you want to be very conservative) > > Yeah, that's ridiculously large. With quite a few extensions supported, and > many more unknown to us, the only way we might realistically ensure that > the ClientHello doesn't change is to save a hash snapshot at every boundary > where the cookie extension might be inserted or where an extension might be > changed. SHA-2 has a fairly small state to capture, but that's still > nearly unbounded state. With an amplification factor of up to 8, meaning > that it could be more efficient to send the client its entire ClientHello > in the cookie.
I definitely won't claim that it is easy or straight-forward to do, I do claim that it is possible. Yes, sometimes it may mean that sending the literal CH in cookie may be more bandwidth efficient. And regarding the specific extension in question, to verify that it didn't change between Hello's it is only 2 bytes extra in cookie. If that is too much already, I don't think that stateless HRR is something we will see in implementations for years to come. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
