On Jun 3, 2016, at 17:54, Joseph Salowey <j...@salowey.net> wrote: > > Unfortunately, the TLS record framing is not easily compatible with having > multiple keys used simultaneously: because we encrypt the content type, it is > not possible to use it to determine which key to use to decrypt. We examined > a number of proposals which would allow you to simultaneously have encrypted > content types and separate keys, but they all appear to be nonviable for one > reason or another:
[...] > • Separately encrypting the content type is inefficient in a number of > ways, especially for DTLS (and would need separate security analysis). This > is probably the most viable of the “try to get both” designs. I'd also like more information about the reasoning behind saying that separately encrypting the content type is inefficient. There was some discussion off-list (but not much) about a proposal to encrypt content type (handshake or application) with a separate key, then encrypting data with the corresponding key (handshake key or application key). The content type would be encrypted using unauthenticated encryption, resulting in a single byte of ciphertext. The authenticated encryption using the corresponding key would include the type as associated data to authenticate it. This had a few drawbacks as I remember it: 1) requires one additional byte in the communication; 2) requires deriving and keeping an extra key (the "content type key") around; 3) requires additional encryption/decryption 4) composability of the application key would still be lost because of post-handshake client authentication. In the off-list discussion, Eric had a potential solution to (1). (3) was unavoidable but in my opinion relatively minimal cost. (4) is true, but we now have Hugo's results that give a form of restricted composability that accommodate post-handshake client authentication. There may have been additional discussions that I wasn't around for. I have heard it suggested that (2) is the particularly problematic aspect for DTLS, but I do not know enough about DTLS to understand this. Even if it is problematic for DTLS, if it is not so problematic for TLS, then why not do it for at least TLS? Douglas _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
