Re: [TLS] Key separation and privacy

[Karthikeyan Bhargavan <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls