On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <h...@ee.technion.ac.il> wrote:
> I don't understand the proposal. > Are you proposing to eliminate resumption_context (RC) from All its > current uses and replace it with the hello_finished extension? > Yes. > Or is this to affect only certain uses of RC? Which ones? > One important property of RC is that it serves as a binding with the > original context that generated a resumption PSK, in particular a binding > with the server's identity (certificate). This is not achieved by the > hello_finished extension, is it? > It is supposed to do so. The reasoning is: - RMS is unchanged and therefore derived from the server certificate - The HelloFinished computation is HKDF(F(RMS), <ClientHello>) and therefore also is derived from the server certificate. Is that insufficient. I also have a problem with names. "Resumption context" is very explicit > about providing, well, resumption context. > "Hello_Finished", in turn, means nothing. > Also, RC may better match the notion of "binder" hence more naturally > requiring collision resistance, while all Finished uses in TLS (1.3 and > before) have a MAC functionality (for which, say, 128 bits are good enough) > and it would be better not to abuse them for other uses. > Two points about this: 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is SHA-256, so I believe we have enough strength here. We could of course require a minimum size. 2. I wouldn't object to changing names here, of course. Best, -Ekr > Anyways, maybe this is just the result of my misunderstanding of the > proposal. > > Hugo > > > On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> 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 >> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
