Re: [TLS] Premaster/Master convention

On 7/30/2014 12:00 PM, Eric Rescorla wrote:
> As discussed in the interim we are going to want to roll over the
> MS periodically. Life will be a lot easier if it has a uniform structure.
>
> Moreover, just because we aren't using key transport doesn't mean
> there aren't other mechanisms with funky shared secrets, e.g.,
> PSK.

I don't think either of these are show stoppers - although I don't know 
exactly what you mean by "uniform structure" here.  Do you mean "because 
that's the way its done in TLS1.2 and before and we want backwards 
compatibility"?

In the former case, its pretty simple to do:

(KA)->master_secret -> next_master_secret  - either as part of the first 
context call (to derive the session and handshake keys), or as a 
separate context call (to specifically generate a new master secret.

E.g. the derive looks like:

(KA) -> master_secret
                  -> next_master_secret
                  -> handshake key
                  -> client_write_AEAD
                  -> server_write_AEAD

next_master_secret
          -> next_master_secret
          -> handshake_key
          -> client_write_AEAD
          -> server_write_AEAD

Or it looks like

(KA) -> master_secret (key expand)
          -> handshake key
          -> client_write_AEAD
          -> server_write_AEAD

master_secret (nextmaster)
       -> next_master_secret

(where key expand and nextmaster are differing labels and KDF contexts).

In the PSK case, with key transport, doing the pre_master->master derive 
allows you to mix in random data from both sides so that the 
master_secret isn't only chosen by one side so there's some security 
benefit there.  In the PSK model, that's not an issue as both sides have 
already agreed upon a key.

Mike

>
> -Ekr
>
>
>
> On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns 
> <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
>
>     Given that TLS1.3 only does KeyAgreement, is there still any
>     reason for the premaster -> master_secret derivation step?  We do
>     (KA)->premaster and then premaster -> master and then
>     master->(session keys).   We could probably do
>     (KA)->master->(session keys) where the master secret is now the KA
>     shared secret rather than premaster.
>
>     1) Is there any security reason for retaining the extra step given
>     there is no longer a KeyTransport mechanism in TLS1.3?
>     2) Are there other *good* - non-security - reasons for retaining
>     the extra step?
>
>     Mike
>
>
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>
>