Hi Folks, The chairs want to make sure this gets some proper review. Please respond with comments by Friday so we can make some progress on this issue.
Thanks, J&S On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin <david...@chromium.org> wrote: > I think this is a good idea. It's kind of weird, but it avoids giving the > early Finished such a strange relationship with the handshake transcript. > Also a fan of doing away with multiple PSK identities if we don't need it. > > As a bonus, this removes the need to route a "phase" parameter into the > traffic key calculation since we'll never derive more than one epoch off of > the same traffic secret. Combine that with the two-ladder KeyUpdate and we > no longer need any concatenation or other label-munging at all. Simply use > labels "key" and "iv" and the record-layer just exposes a single > UseTrafficSecret function which saves the traffic secret (for KeyUpdate), > derives the traffic keys, and engages the new AEAD in one swoop without > mucking about with phases, traffic directions, whether we are client or > server, etc. > > David > > On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla <e...@rtfm.com> wrote: > >> 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 >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
