These are good questions. More generally, when do we care about distinguishing handshake data from application data?
I just posted another email about using plaintext end_of_early_data alerts to avoid trial decryption, and similar questions come into play there. Best, Karthik > On 29 Mar 2016, at 22:50, Björn Tackmann <btackm...@eng.ucsd.edu> wrote: > > Dear TLS Working Group, > > this message relates mostly to (real-world) privacy, so I'd be particularly > grateful for comments from people concerned with that. > > The TRON workshop [1] re-initiated a discussion about the handling of keys > among cryptography researchers involved with TLS. Although there is no > unanimous opinion on this matter, I think it is fair to say that the majority > of cryptographers support the principle of key separation, that is, using > each cryptographic key derived within the protocol (only) for its specific > purpose. (This simplifies the analysis significantly, but it also helps to > avoid unintended interactions between different protocol parts and to keep > things nice and modular.) We are particularly concerned with the traffic keys > used for handshake and for application data. > > The current TLS 1.3 draft is somewhat inconsistent here. While the ordinary > handshake messages are encrypted under a handshake traffic key HTK, "late" > handshake messages (NewSessionTicket and post-handshake client > authentication) are intermixed with application data messages and encrypted > under the application traffic key ATK. Encrypting late handshake messages > with HTK instead of ATK would cause the problem that the receiver must know > which key to use for decrypting a received message; the somewhat most > straightforward way would be to make the messages clearly distinguishable, > another way would be to do trial decryption for each incoming message with > ATK and, in case of failure, decrypt with HTK. This key HTK could be the very > same key as the one used for encrypting the messages during the initial > handshake. > > The plain "record type" field has been retired when the new padding mechanism > was introduced, with the idea of better protecting privacy. So the main > question here is: how important is it to make handshake and application data > messages indistinguishable? And is it realistic? > - The late handshake messages are "new ticket," "late client auth," and "key > update." I guess the most sensitive of them is "late client auth?" Is it > important that this be hidden within application data? Are "new ticket" and > "key update" also considered privacy-sensitive? > - Beyond the plain record type, the message may also be identifiable by other > traffic characteristics such as length or timing. While the length can be > hidden using padding, this requires co-operation with the application layer, > because TLS can hardly know what the characteristic traffic pattern of the > particular application is. Is this, realistically, ever going to happen in a > way that will significantly cover the characteristic pattern of the handshake > messages? > > In a nutshell, three possibilities for this are: > (a) Do not separate keys, i.e., set HTK = ATK. This makes cryptographic > analysis harder and renders the protocol less modular, but it may have > privacy advantages. > (b) Separate keys, set HTK != ATK, and resurrect the “record type” field to > the extent that it allows to differentiate HTK-encrypted packets from > ATK-encrypted packets. This seems the cryptographically cleanest way but may > come with worse privacy guarantees. > (c) Separate keys, set HTK != ATK, leave “record type” field disabled, and > trial-decrypt. This is messier than both of the above, but seems a possible > compromise between modularity and privacy. > > What do you think? > > Thanks & best, > Björn > > > [1] > http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme > > -- > Björn Tackmann > Postdoctoral Research Scholar > Computer Science & Engineering, UC San Diego > > > > > > _______________________________________________ > 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
