Re: [TLS] Premaster/Master convention

[Michael StJohns <[e-mail]>]

On 7/30/2014 12:26 PM, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns 
> <[e-mail] <mailto:[e-mail]>> 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.

You already have a disconnect in size on with respect to the premaster 
secret - it's going to be 32 bytes for P256 ECDH, something larger for 
DH depending on the group. (random length) -> (48 bytes)

You also have a disconnect on the output - any number of keys of any 
size.  (48 bytes) -> (random sizes)

So why you think that its important to have an impedence match of 
(random size} -> 48 bytes -> (random sizes) is unclear to me.

Is there a specific technical issue with {random length} -> { random 
lengths} that you can see?  I understand you have a preference, I'm 
asking if you can see a reason why this would weaken security?

There's the final issue that  - as I read the HMAC document and the 
precursor technical papers - you don't really get anything with respect 
to security using keys over the native output length of the underlying 
hash, and that you weaken security if you use less bits than that.  So 
48 bytes is fine up to a hash of 384 bits, but is the possibly limiting 
security factor for anything larger.  I don't know that we're going to 
be going to anything above 192 bits of (to include 384 bit hash 
functions) any time soon, but I would hate for this 48 bit legacy value 
to be the unforeseen security ceiling.

*My* preference is for the input keys and the output keys to be matched 
to the needs of the cryptographic suite.  That 384 bits of premaster 
secret is good up to SHA384, but may represent a smaller security 
strength for non-NIST hashes.   I *think* this 48 octet value is the 
last fixed length security key in the standard.

Mike

>
> -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
>>     <[e-mail] <mailto:[e-mail]>> 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
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>