On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > I concur with what I take to be MT's position here: > > 1. The client is clearly prohibited from changing most elements of the CH > (except for listed exceptions). > 2. It's reasonable to check for and fail the handshake on any spec > violation except those where checking is explicitly forbidden (e.g., Must > Be Zero but Must be Ignored) > 3. Nothing in the spec requires the server to check for this condition.
and what about values that technically can't change (as you noted yourself) but they do change and the server does use them? you are not suggesting that which value will be used (from first or second CH), or if the connection will be aborted, to be implementation dependant *by design* , do you? > -Ekr > > On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario <hka...@redhat.com> wrote: > > 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_______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls -- 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
