On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> given need for GREASE and two dozen flags across OpenSSL history for
> workarounds for bugs in different implementations, the lesson seems to be
> that
> the receiving side should be as strict as it can (within protocol confines)
> or
> we risk making the non-conforming behaviour common
I take something different from that experience. There is value in having some
implementations do strict checks, certainly. However, in this case, I don't
believe that it is reasonable to perform these checks (more below).
> > With that answer in mind, if the second ClientHello might differ, I assert
> > that the server uses that. Hubert observes that this behaviour is not
> > specified at all, which is entirely true. I think that using the first
> > ClientHello would be nonsensical, because the server needs to use the
> > second ClientHello for those extensions that can change, like key share.
>
> And I say that when you have already parsed, verified and sanity-checked the
> first set of extensions, it is much saner to reuse that work and only update
> the values that can change and ignore all other extensions...
As I mentioned, NSS does that work, at least partially, and then throws all of
that state away when it sends HelloRetryRequest. It does that so that
HelloRetryRequest can be truly stateless (an advantage for DTLS). Doing that
work all over is trivial, bundling the necessary state, not.
> There are multiple ways to look at this, and given that the standard is very
> firm that the 2nd CH needs to be as similar to the first one as possible, it
> is thus silent on which takes precedence in case they differ in general,
> because they can't.
> > If we require or allow checking - and I think that we should definitely
> > allow a check - the details of the conditions under which a check might
> > fail aren't completely obvious for new extensions. A new extension might
> > be defined that has special handling in HelloRetryRequest, so it might be
> > reasonable to allow new extensions to be changed.
>
> yes, and we already had discussion on this ML about this: if the extension
> needs to change (based on protocol definition), the server MUST include it in
> HRR to signal to client, "yes, I do know about it, you can update it" and
> client MUST NOT change it otherwise
I remember having that discussion, but I guess the only way it made it into the
spec was as:
- Other modifications that may be allowed by an extension defined in
the future and present in the HelloRetryRequest.
Which isn't particularly direct, but I guess that's enough.
> 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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
