On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin <david...@chromium.org> wrote:
> On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla <e...@rtfm.com> wrote: > >> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud < >> anto...@delignat-lavaud.fr> wrote: >> >>> Regarding whether the placeholder zeros should be part of the transcript >>> for the stuffed finished, an argument against it is that it violates the >>> incremental nature of the session hash. If the hash stops before the >>> placeholder, it can be resumed with the computed finished; otherwise, it >>> must be rolled back. >>> >> >> This isn't a big deal for me (or I think any other implementor) either >> way, because of the actual way we compute the hash. >> > > To expand on that, because the final PRF hash is not known at the time we > send ClientHello, most implementations I've seen just buffer the full > transcript before this point. > > But one could also keep a rolling hash of all the supported PRFs (there's > all of two of them if you lose TLS 1.1 and below), so I think that's a good > argument for using the prefix rather than zeros. For implementations > keeping a buffer, I don't think it matters, so let's keep both strategies > happy. > This is certainly fine with me. -Ekr > > David > > > >> -Ekr >> >> >>> >>> Best, >>> >>> Antoine >>> >>> >>> Le 2016-09-07 05:49, Joseph Salowey a écrit : >>> >>>> 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 [1] >>>>> >>>>> >>>>> 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 [2] >>>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls [2] >>>> >>>> >>>> >>>> Links: >>>> ------ >>>> [1] https://github.com/tlswg/tls13-spec/pull/615 >>>> [2] 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 >>> >> _______________________________________________ >> 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
