Subject: [TLS] Premaster/Master convention

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jul 2014 10:56:48 -0400

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

---

From: "Gero, Charlie" <[email-masked]>
Date: Wed, 30 Jul 2014 11:02:20 -0400

We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms.  It allows us to do splitting between machines that have keys and those that don't (machines in safe locales and those which are simply terminators).  I don't think we could use the same methods we use today without that sub step.  It would make it very difficult for Akamai to adopt 1.3.

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2014 10:57 AM
To: [email-masked]
Subject: [TLS] Premaster/Master convention

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

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jul 2014 11:45:54 -0400

> We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms.  It allows us to do splitting between mac…

So you send the master secret from the handshaker machine out to several 
other machines which then do what with it?  Couldn't you send the 
traffic keys instead?

I'm not sure I understand the constraints you're working under. Could 
you expand on that?

Thanks - Mike

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Jul 2014 09:00:06 -0700

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.

-Ekr

On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns <[email-masked]>
wrote:

> the premaster -> master_secret derivation step?  We do (KA)->premaster and
> then premaster -> master and then master->(session keys).   We could

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jul 2014 12:21:29 -0400

> there aren't other mechanisms with funky shared secrets, e.g.,

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 
> <[email-masked] <mailto:[email-masked]>> 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?
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Jul 2014 09:26:22 -0700

> that's the way its done in TLS1.2 and before and we want backwards

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

> context call (to derive the session and handshake keys), or as a separate
> context call (to specifically generate a new master secret.
>
> 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
>
>
>

---

From: "Gero, Charlie" <[email-masked]>
Date: Wed, 30 Jul 2014 12:27:54 -0400

I can't go into details around it at this time.  Suffice to say, we definitely do rely on the two being split.

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2014 11:46 AM
To: Gero, Charlie; [email-masked]
Subject: Re: [TLS] Premaster/Master convention

> We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms.  It allows us to do splitting between mac…

So you send the master secret from the handshaker machine out to several other machines which then do what with it?  Couldn't you send the traffic keys instead?

I'm not sure I understand the constraints you're working under. Could you expand on that?

Thanks - Mike

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 30 Jul 2014 22:47:14 +0300

> On 30.7.2014, at 18.02, "Gero, Charlie" <[email-masked]> wrote:
> 

Without going much into details, are you sure that you can still use these methods, or that these methods are still relevant, without the RSA key exchange?

With ephemeral (EC)DH only things done with the certificate private key is signing and verifying, and that doesn't involve the randoms. So I can't figure out how PMS->MS separation helps there, although I can see how it helps in the RSA key exchange. But I'll take your word for it if you say so.

Juho

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jul 2014 16:43:20 -0400

On 7/30/2014 12:26 PM, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns 
>     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"?
>
>

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

>     (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.
>
>     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
>>
>>
>>
>>         reason for the premaster -> master_secret derivation step?
>>          We do (KA)->premaster and then premaster -> master and then
>>         (KA)->master->(session keys) where the master secret is now
>>         1) Is there any security reason for retaining the extra step
>>         given there is no longer a KeyTransport mechanism in TLS1.3?

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jul 2014 16:58:37 -0400

> I can't go into details around it at this time.  Suffice to say, we definitely do rely on the two being split.
Hi Charlie -

If someone said - "we depend on the packet formats to be predictable" 
I'd say they'd have a case for reliance and backwards compatibility.  
Saying that you did something that will break that is totally and 
completely opaque to the on-the-wire protocol spec and expecting the 
protocol spec not to change (assuming proper on-the-wire negotiation to 
describe said changes) seems to be pushing your luck.

That said, the more details you can share, the better chance we have of 
doing something that won't annoy you.  For example, would your system 
break if the master secret were no longer 48 octets?  Would it break if 
the PRF were not based on SHA256?  Would it break if the PRF were a CMAC 
vs an HMAC?

I have no idea where this idea will go.  It may go nowhere, in which 
case you're safe - for now.  It may go into the protocol.  I think if I 
were at akamai, I'd be looking at why this could be an issue, and how to 
remediate it even if it doesn't make it in.  But that's just me.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Jul 2014 17:04:17 -0400

> changes) seems to be pushing your luck.

Duly noted, and we don't disagree.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: "Gero, Charlie" <[email-masked]>
Date: Wed, 30 Jul 2014 20:44:03 -0400

Michael,

Respectfully, there are things that we can and can not divulge.  I will continue to monitor this path and will update as necessary if removal of the PMS to MS step looks like it is gaining traction.  I'm not sure it is.  Certainly, Akamai represents a significant amount of SSL traffic on the Internet, so we want to make sure we future proof our designs.  My not telling you of how the internals work should not be construed that we're not trying to guard against this and other possible changes.  It is simply relaying to you a real world fact without divulging what I can not divulge.

Charlie Gero
Senior Principal System Software Engineer
Team Lead Engineering - Akamai Labs
617.444.3940

On Jul 30, 2014, at 4:59 PM, "Michael StJohns" <[email-masked]<mailto:[email-masked]>> wrote:

Mike

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 11:46 AM
To: Gero, Charlie; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Premaster/Master convention

Thanks - Mike

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] Premaster/Master convention

Mike

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Gero, Charlie" <[email-masked]>
Date: Wed, 30 Jul 2014 21:18:53 -0400

Sorry for the second late response.  Hectic day.  Here's a follow up from the previous.

Missed answering your original questions:
Would your system break if the master secret were no longer 48 octets? No.
Would it break if the PRF were not based on SHA256?  No.
Would it break if the PRF were a CMAC vs an HMAC? No.

In addition, as long as TLS 1.3 keeps static RSA key exchange and renegotiation out as well as only removing PMS to MS in 1.3 and later, we should be ok.  As someone adeptly inferred earlier, this is where things would get hairy for us if any of these constraints are violated.

Again, I'm not sure this has steam behind it or not (only time will tell) but we should be able to work out things given those constraints.

Regards,
Charlie

On Jul 30, 2014, at 8:44 PM, "Gero, Charlie" <[email-masked]<mailto:[email-masked]>> wrote:

Michael,

Charlie Gero

Mike

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 11:46 AM
To: Gero, Charlie; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Premaster/Master convention

Thanks - Mike

-----Original Message-----
From: Michael StJohns [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] Premaster/Master convention

Mike

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Jul 2014 19:51:24 -0700

On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns <[email-masked]> 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?

Ideally the handshake would simply supply key material to a transport
protocol, and meet standard security conditions.
(some CK variant, and I've not included renegotiation). To do this the
premaster->master step is fine, but the Finished
message needs to be changed. (Yes, miTLS exists. It has to do all sort
of nonstandard assumptions to work).

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 Jul 2014 13:28:22 -0400

On 7/30/2014 8:44 PM, Gero, Charlie wrote:
> Michael,
>
> Respectfully, there are things that we can and can not divulge.  I 
> will continue to monitor this path and will update as necessary if 
> removal of the PMS to MS step looks like it is gaining traction.  I'm 
> not sure it is.  Certainly, Akamai represents a significant amount of 
> SSL traffic on the Internet, so we want to make sure we future proof 
> our designs.  My not telling you of how the internals work should not 
> be construed that we're not trying to guard against this and other 
> possible changes.  It is simply relaying to you a real world fact 
> without divulging what I can not divulge.

Hi Charlie -

No problems.  I understand the painful master that is NDA.    That said, 
pretend for a minute that all that's left of TLS1.2 in TLS1.3 is the 
version negotiation and basic record format.  Think about the gotcha's 
that might pop up with your stuff the longer the TLS WG twiddles with 
the protocol.  Figure out if you can tell us anything about them.

If you can't - you can't.   Unfortunately, the corollary of  "if you 
can't explain what's wrong, we can't do anything to fix it" probably 
applies.

Mike

> *Charlie Gero*
>> I can't go into details around it at this time.  Suffice to say, we 
>> definitely do rely on the two being split.
> Hi Charlie -
>
>
>> To: Gero, Charlie; [email-masked] <mailto:[email-masked]>
>>> We have a number of technologies at Akamai that utilize the fact 
>>> that the PMS is split from the MS and that MS is produced in 
>>> conjunction with the randoms.  It allows us to do splitting between 
>>> machines that have keys and those that don't (machines in safe 
>>> locales and those which are simply terminators).  I don't think we 
>>> could use the same methods we use today without that sub step.  It 
>>> would make it very difficult for Akamai to adopt 1.3.
>> So you send the master secret from the handshaker machine out to 
>> several other machines which then do what with it?  Couldn't you send 
>> the traffic keys instead?
>>
>>> To: [email-masked] <mailto:[email-masked]>
>>> Given that TLS1.3 only does KeyAgreement, is there still any reason 
>>> for the premaster -> master_secret derivation step?  We do 
>>> (KA)->premaster
>>> probably do (KA)->master->(session keys) where the master secret is 
>>> now the KA shared secret rather than premaster.
>>>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 Jul 2014 13:34:34 -0400

> Sorry for the second late response.  Hectic day.  Here's a follow up 
No probs
>
> In addition, as long as TLS 1.3 keeps static RSA key exchange and 
> renegotiation out as well as only removing PMS to MS in 1.3 and later, 
> we should be ok.  As someone adeptly inferred earlier, this is where 
> things would get hairy for us if any of these constraints are violated.
>
>

I couldn't parse this very well - too many missing commas.  Did you mean?:

"In addition, as long as TLS1.3 only removes static RSA key exchange and 
renegotiation we should be ok"

- and -

"If removing the pre-master secret only applies to TLS1.3 and later we 
should be ok"

I thought removing the pre-master regardless of rev was the issue?

Mike

---

From: "Gero, Charlie" <[email-masked]>
Date: Thu, 31 Jul 2014 21:46:25 -0400

Sorry for the lack of clarity.  What I mean is, I think Akamai will be able to keep our current system working even with PMS to MS removed given:

1. Removal of the PMS to MS step is done in 1.3 and forward only (this seems obvious, but in the argument of explicitness...)

AND

2. TLS 1.3 removes static RSA key exchange.

AND

3. TLS 1.3 removes renegotiation.

If any of those constraints break, our current architecture will require significant change.

Regards,
Charlie Gero

On Jul 31, 2014, at 1:34 PM, "Michael StJohns" <[email-masked]<mailto:[email-masked]>> wrote:

No probs

"In addition, as long as TLS1.3 only removes static RSA key exchange and renegotiation we should be ok"

- and -

"If removing the pre-master secret only applies to TLS1.3 and later we should be ok"

Mike

---

From: "StJohns, Michael" <[email-masked]>
Date: Fri, 1 Aug 2014 00:15:53 -0400

Got it.  Thanks for the clarification.

On Thursday, July 31, 2014, Gero, Charlie <[email-masked]> wrote:

> Sorry for the lack of clarity.  What I mean is, I think Akamai will be
> able to keep our current system working even with PMS to MS removed given:
>
> 1. Removal of the PMS to MS step is done in 1.3 and forward only (this
> seems obvious, but in the argument of explicitness...)
>
> AND
>
> On Jul 31, 2014, at 1:34 PM, "Michael StJohns" <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> renegotiation out as well as only removing PMS to MS in 1.3 and later, we
> should be ok.  As someone adeptly inferred earlier, this is where things
> would get hairy for us if any of these constraints are violated.
>
>
>