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

[Eric Rescorla <[e-mail]>]

On Mon, May 26, 2014 at 6:53 PM, Michael StJohns <[e-mail]>wrote:

> I went back and read the minutes of the London meeting about removing
> static RSA and wanted to clarify what that really meant. The minutes had
> EKR mentioning this in conjunction with DH which seems different that what
> I kept hearing at the interim meeting. Could someone confirm "removing
> static RSA" results in removing the use of  RSA as a key transport
> mechanism from 1.3 (e.g. as defined in section 7.4.7.1 of TLS1.2 -
> basically removing this section and prohibiting "rsa" and "rsa_psk"  as key
> exchange algorithms)?
>

Yes. This has already been merged into github:
https://github.com/tlswg/tls13-spec/commit/45aed081b1e3790507d91e3e6cc48451ed9beb94


To go further and take this up from specific cryptography - will/should TLS
> 1.3 prohibit *any* Key Transport mechanism and retain only Key Agreement
> mechanisms for key exchange?
>

I don't believe there has been any consensus on this topic. It certainly
would
be easy to do if that's what the WG wants.


>
> Also in the London meeting it was agreed limit ciphertext to AEAD style
> processing - e.g. in the TLSCipherText record to remove "stream" and
> "block" as valid choices.  Does that result in the removal of sections
> 6.2.3.1 and 6.2.3.2 or rather their equivalent in TLS1.3?


Yes. I'm working on a pull request for this now.



> 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.


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.

-Ekr