Re: [TLS] Clarifications and questions: TLS1.3 - Static RSA and AEAD

[Michael StJohns <[e-mail]>]

On 5/26/2014 10:32 PM, Eric Rescorla wrote:
>
>     Does it also result in changing the output of the "key expansion"
>     phase as only "client_write_key" and "server_write_key"s will be
>     needed for AEAD?
>
>
> I don't believe so, since AEAD still at least potentially requires an IV.

Right - but we really need to get IV material in a way where it isn't 
derived from the master secret.    What I meant was that 
"client_write_mac_key" and "server_write_mac_key" are no longer 
generated since they aren't necessary for AEAD - correct?

>
>
>     Is there any desire to specify a AEAD general block cipher
>     mode/mac construct with an integral key expansion function?  E.g.
>     could something like
>     http://www.ietf.org/id/draft-mcgrew-aead-aes-cbc-hmac-sha2-04.txt
>     be adapted to be a general model for TLS or is this out of scope
>     for the TLS1.3 main document?
>
>
> Certainly this is something one could in principle do. However I know that
> there are some who would prefer to not specify any CBC cipher suite so
> I expect they may want to weigh in now. Another alternative would be to
> specific an AES-CTR/HMAC combined mode.

There's things that the TLS base document should be specifying (e.g. 
we'll only do AEAD style modes and here's the interface), and then 
there's getting into the nitty-gritty of specific cipher suites.

  I'm wondering if it would make sense to completely remove all of the 
cryptography (e.g. RSA, DH, AES, DSA, ECDSA, ECDH) specific language to 
a separate document and have the base document only talk about the 
cryptographic constructs, message formats, negotiation schemes etc?  
That makes support of the base specification a bit more independent from 
the crypto suite specifications.

With respect to the use of compound AEAD functions - I think you have to 
allow for things like McGrew's draft, as well as the equivalent on 
non-AES, non-NIST regional mechanisms to be specified as a compound 
AEAD.  CBC has gotten bad press, but it's out there, it's built in to a 
lot of hardware and, used with a good integrity mechanism (in 
encrypt-then-mac order), seems to be "secure enough" for the given uses.