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
