Re: [TLS] Closing on keys used for handshake and data messages

[Dave Garrett <[e-mail]>]

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