On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario <hka...@redhat.com> wrote:
> 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? > I'n not sure I understand your question, but I'll try to answer what I think it says. 1. I do think that whether you continue the connection or abort it is an implementation decision and I think that the way the spec is written says that. 2. I think the spec leaves open whether you should use the first or second values, but I think implementations should use the second value. It's not clear why one would want to use the first. To my knowledge, there was never a WG discussion about this exact question, so we only have the spec to guide us. Were we pre-publication I would have advocated for (a) leaving open whether to abort and (b) requiring you to use the second value. -Ekr > > -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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
