I should also mention that this makes the implementation a fair bit simpler because:
1. You can make all the decisions on the server side immediately upon receiving the ClientHello without waiting for Finished. 2. You don't need to derive early handshake traffic keys. >From an implementor's perspective, this outweighs the messing around with the ClientHello buffer. -Ekr On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla <e...@rtfm.com> wrote: > Folks, > > I have just posted a WIP PR for what I'm calling "Finished Stuffing" > > https://github.com/tlswg/tls13-spec/pull/615 > > I would welcome comments on this direction and whether I am missing > anything important. > > > OVERVIEW > This PR follows on a bunch of discussions we've had about the redundancy > of Finished and resumption_ctx. This PR makes the following changes: > > - Replace the 0-RTT Finished with an extension you send in the > ClientHello *whenever* you do PSK. > - Get rid of resumption context (because it is now replaced by > the ClientHello.hello_finished. > > > RATIONALE > The reasoning for this change is: > > - With ordinary PSK you don't get any assurance that the other side > knows the PSK. > > - With 0-RTT you get some (subject to the usual anti-replay > guarantees) via the Finished message. > > - If we were to include the 0-RTT Finished message in the handshake > transcript, then we wouldn't need the resumption context because > the transcript would transitively include the PSK via the Finished. > > So the natural thing to do would be to always send 0-RTT Finished > but unfortunately: > > 1. You can't just send the 0-RTT Finished whenever you do PSK because > that causes potential compat problems with mixed 1.3/1.2 networks > (the same ones we have with 0-RTT, but at least that's opt-in). > > 2. You also can't send the 0-RTT Finished with PSK because you can > currently offer multiple PSK identities. > > The on-list discussion has suggested we could relax condition #2 and > only have one identity. And we can fix condition #1 by stuffing the > Finished in an extension (with some hacks to make this easier). This > PR enacts that. > > > FAQS > - What gets included in the handshake transcript? > The whole ClientHello including the computed hello_finished extension. > > - Isn't this a hassle to implement? > It turns out not to be. The basic reason is that at the point where > the client sends the ClientHello and the server processes, it doesn't > yet know which Hash will be chosen for HKDF and so NSS (and I believe > other stacks) buffers the ClientHello in plaintext, so hashing only > part of it is easy. I've done it in NSS and this part is quite easy. > > > POTENTIAL VARIATIONS/TODOs > There are a number of possible variations we might want to look at: > > 1. Moving obfuscated_ticket_age to its own extension (out of > early_data_indication). This provides additional anti-replay > for the CH at the 0.5RTT sending point. I believe we should > make this change. > > 2. Tweaking the data to be hashed to just hash the ClientHello > prefix without the 0-filled verify_data. This is not significantly > harder or easier to implement and basically depends on whether > you prefer the invariant of "always hash complete messages" or > "always hash valid pieces of transcript". See above for notes > on buffering. > > 3. Allow multiple PSKs. Technically you could make this design > work with >1 PSK but stuffing multiple verify_data values in > the ClientHello. E.g,, > > opaque FinishedValue<0..255>; > > struct { > FinishedValue finisheds<0..2^16-1>; > } HelloFinished; > > Based on the list discussion, it seems like nobody wants >1 PSK, > so I think one is simpler; I just wanted to note that these > changes weren't totally coupled. > > 4. External context values. Several people have pointed out that it > might be convenient to have an external context value hashed > into the transcript. One way to do this would be to include > it under the Finished. That's not difficult if people want to, > with the default being empty. > > 5. Hugo brought up on the list that we need to make very clear that > the "hello_finished" is being used to bind the handshakes and > that it depends on collision resistance. I have not forgotten this > and text on that point would be appreciated. > > Comments welcome. > -Ekr > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
