On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario <hka...@redhat.com> wrote:
> On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > 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. > > because you have already parsed, verified and sanity-checked the first > hello, > you already decided what kind of parameters will the connection use and > you're > expecting just the values that can change to change and ignoring > everything > else, thus not wasting cycles on verifying the extensions twice... > As MT says, we use a stateless design, and we don't necessarily verify the entire CH prior to sending HRR. For instance, it's not necessary to do certificate selection and hence not to look at signature_algorithms. > so it's not clear to me why you'd ever want to use the second one > Well, clearly views differ on this, then. > > 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. > > so you don't think this qualifies for Errata? > What Ben said. -Ekr > > side note: it is actually possible to check if the 2nd CH has minimal > changes > in stateless HRR by replacing the extensions that can change with the > hashes > of their values and then storing the overall hash of CH message together > with > hashes of the extensions that can change. When receiving the 2nd CH, we > can > replace the extensions that can change with respective hash values and > then > check if the overall hash still matches. That translates to something like > 4 > hashes, two positions and two flags (for padding and early_data). Only > this > much is necessary to check perfectly if the CH is unchanged. The only > exception is pre_shared_key, but server behaviour with it is clearly > defined - > the server must use the values from 2nd CH as the selected_identity > wouldn't > match otherwise and binders couldn't be verified. With addition of one > more > hash in the cookie the server may easily ensure that the identity it > planned > to select remained in the CH. That's like 165 bytes when using > non-truncated > sha-256 hashes. > > -- > 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
