Re: [TLS] Premaster/Master convention

On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns <msj@nthpermutation.com>
wrote:

>  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"?
>

I mean always have the secret you use for key derivation be
the same size and unstructured and get to it the same way,
regardless of the starting secret.

Thus, I would prefer to stick with the same PMS->MS flow.

-Ekr

> 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>
> 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
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>