On Friday, June 03, 2016 05:54:53 pm Joseph Salowey 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: > > - Trial decryption has serious implementation problems > - Double-encrypting handshake messages in both the handshake key and the > application key does not actually provide the required key separation > - 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.
Could someone please elaborate on why nested encryption would be a problem? No objection to avoiding trial decryption, though. The general expectation I would have for doing double encryption here would be to encrypt TLSCiphertext normally with the application traffic key and TLSCiphertext.content would be the real unencrypted length plus an aead-ciphered struct of the message which is encrypted with the relevant key. (the unencrypted length would be the inner encrypted block's length, in this scenario) Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
