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
