Hi Eric, Looks like Watson already gave a definitive reply on my behalf. Thanks Watson, for being such an effective and proactive amanuensis.
For the avoidance of doubt: what Karthik suggests would avoid the problem we've been discussing, so I'd be quite happy with it. Cheers Kenny On 20/02/2016 20:30, "Eric Rescorla" <e...@rtfm.com> wrote: >Kenny, > > >Would you have a problem with doing as Karthik suggests and generating >separate traffic and handshake keys but at the same time? > > >-Ekr > > > > >On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny ><kenny.pater...@rhul.ac.uk> wrote: > >Hi > >My 2c below... > >On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet" ><tls-boun...@ietf.org on behalf of >four...@microsoft.com> wrote: >> >> >>Besides, in our analysis of the handshake, we get precisely the same >>“fresh, never-used secret” property you are advocating, with or >> without the simplification, each time the handshake provides keys to the >>record layer. These points are well-specified and delimited. They just do >>not coincide with the end of the handshake. So I don’t see any >>fundamental difference in term of generic-security. >> >>We are left with scenarios whereby the record layer, given both the >>handshake and application-data traffic keys, somehow leaks only >> one of the two. I don’t mind keeping the key change if someone is >>concerned about it. > >Like Hugo, I am also concerned about removing the key change. Let me try >to explain why. > >I would emphasise the point that while we *can* provide formal security >analyses in the situation where the application key is used during the >handshake itself, it is made significantly more complex. > >In particular, it means we cannot simply combine security results arising >from separate analyses of the Handshake Protocol and of the Record >Protocol to obtain security guarantees for the composition of these two >protocols. So for example, if we chose to refine our modelling of the >Record Protocol in some way, then we would need to re-do the analysis of >TLS (Handshake + Record Protocols) as a monolithic effort. That's hard >work and error prone. This situation would not arise if the application >keys were NOT used in the handshake. > >This is not merely a conjectured issue. As one example, several papers >(including [1,2]) in the "provable security" paradigm have used the ACCE >framework as a security model within which to conduct analysis of >fragments of previous versions of TLS. ACCE was specifically designed to >deal with keys that are used across the Handshake and the Record >protocols. But ACCE views the Record Protocol in a particular way - >essentially as a stateful encryption scheme that processes "atomic" >messages. This modelling does not take into full account the streaming >nature of the TLS Record Protocol - in fact, what the Record Protocol >actually guarantees is significantly different from what is implied by the >ACCE modelling of it - see [3] for details, and also the cookie cutter >attack from the Triple Handshakes paper for an example of what can go >wrong. > >One implication of this is that the results of [1,2] for existing versions >of TLS really need to be reworked in a modified version of the ACCE >framework that better reflects the streaming nature of the Record >Protocol. That need for rework would have been avoided had TLS not used >application keys in the Handshake Protocol, because the compositional >guarantees would have enabled us to "plug and play" with our results. > >The same pertains in TLS 1.3 going forward: keeping the strict key >separation - no use of the application keys in the Handshake - will make >future - and on-going - analyses of TLS 1.3 easier. This is >notwithstanding the fact that several research teams, including Cedric's >and [1,2] below, have managed to produce analyses that do handle the use >of the application key in the Handshake. > >Regards, > >Kenny > >[1] Tibor Jager, Florian Kohlar, Sven Schäge, Jörg Schwenk. On the >Security of TLS-DHE in the Standard Model. CRYPTO 2012. >[2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of >the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013. >[3] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G. >Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2) >2015. > > >_______________________________________________ >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
