Re: [TLS] AEAD only for TLS1.3 revisit

["Joseph Salowey (jsalowey)" <[e-mail]>]

On Sep 30, 2014, at 1:23 PM, Michael StJohns <[e-mail]> wrote:

> On 9/30/2014 3:44 PM, Joseph Salowey (jsalowey) wrote:
>>  Allowing for man-in-the-middle and passive monitoring is in opposition to our current mandate.   As an aside, if this becomes a requirement in the future I don't think that AEAD actually limits either of these possibilities, although your choice of cipher may.
> 
> 
> 
> It depends on the cipher mode.  Unfortunately, the restriction/limitation  applies to both CCM and GCM; the only "native" AEAD ciphers in the TLS toolchest.  For CCM, the key used for encryption is the same one used for integrity.  For GCM, the key used for integrity is CIPH[sub K](128 bits of zero) where K is the encryption key - if you have the encryption key, you can generate the integrity key.
> 
> The only other AEAD cipher suite we have in progress is https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ which is a constructed AEAD cipher.  That basically splits the input K linearly into two pieces - the HMAC and AES keys, so it would be possible to reveal the AES subkey without revealing the HMAC key.
> 
> So the choice of AEAD effectively limits these possibilities.  For all the non-AEAD suites, the integrity and encryption keys are individually derived.
> 

[Joe] Many may consider this a feature rather than a problem, however, as you state above, you can develop an AEAD ciphersuite with the properties you want.  

> Mike
>