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... so it's not clear to me why you'd ever want to use the second one > 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? 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
