Subject: [TLS] TLS 1.3 - method to request uncached shared secrets

From: Dave Garrett <[email-masked]>
Date: Sat, 18 Jul 2015 00:37:55 -0400

Brian Smith posted an RFE to GitHub a few months ago requesting "A mechanism is needed to indicate that a session will not be resumed":
https://github.com/tlswg/tls13-spec/issues/137

The goal is to provide a simple way for either endpoint to request that the master secret be forgotten ASAP to provide a greater assurance of confidentiality.

I've written up a short proposal with idea about how I'd suggest going about this:
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify

The idea is to simply add a new "reset_notify" alert (generally a warning) which may be sent by either endpoint as soon as record protection is available, after which both endpoints would stop caching shared secrets after completion of traffic key completion. This could be sent right from the start, at the end of a connection just prior to a standard "close_notify", or at any point in between.

This seems like a simple route that does what is specified in issue #137 without the creation of any new extensions or messages; just one new alert value.

Comments? Suggestions? Any reason this would break everything?

No PR yet. Just a WIP branch to spec out the idea, so far.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Jul 2015 21:50:40 -0700

On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett <[email-masked]>
wrote:

> Brian Smith posted an RFE to GitHub a few months ago requesting "A
> mechanism is needed to indicate that a session will not be resumed":
> The goal is to provide a simple way for either endpoint to request that
> the master secret be forgotten ASAP to provide a greater assurance of
> confidentiality.
>
> The idea is to simply add a new "reset_notify" alert (generally a warning)
> which may be sent by either endpoint as soon as record protection is
> available, after which both endpoints would stop caching shared secrets
> after completion of traffic key completion. This could be sent right from
> the start, at the end of a connection just prior to a standard
> "close_notify", or at any point in between.
>
> This seems like a simple route that does what is specified in issue #137
> without the creation of any new extensions or messages; just one new alert
> value.
>

I don't think this is that useful or practical with the current structure
of TLS 1.3.

- Unless I've missed something, this is primarily an issue of PFS for the
original
  connection, since compromise of either endpoint probably allows
impersonation
  attacks going forward.

- Because the resumption master secret is cryptographically independent
  of the master secret that initiated the connection, its existence in the
server's
  database or in a ticket isn't a threat to the originating connection.

- The server can opt not to allow resumption by declining to provide
  a NewSessionTicket message.

-  The client has the option of never initiating a new connection with the
   provided ticket (assuming that the server opts to supply one). Note
   also that because the ticket is encrypted with the original traffic keys,
   if the client never tries to resume the connection, the ticket never
   appears on the wire (which is relevant for self-encrypted tickets, but
   not so much for tickets which are database lookup keys).

- Because many implementations use self-encrypted  tickets, it's not
practical
  to require   them to delete keying material once it's been established.
Once such
   a ticket has been transmitted on the wire, the server can't really
forget it
  without deleting the ticket encryption key (it can of course mark the
  ticket invalid in some local database, but that doesn't reduce the risk
  from compromise of the ticket encryption key.)

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Sat, 18 Jul 2015 01:06:33 -0400

> "close_notify", or at any point in between.

This is not really what I was intending when I suggested the feature. I was
intending for their to be an indication, in the ClientHello, that the
server should not do any of the work that it would normally do to make the
session resumable. That is, the server MUST NOT create a session ticket,
and the server MUST NOT add the connection to any session cache, the server
SHOULD forget the epheneral (EC)DHE key and master secret ASAP during
handshaking. (And, so should the client.)

An alert like you suggest may be useful for some cases, but it wouldn't be
useful for what I was suggesting because it would occur after the server
has already done all the things to cache a session that add needless risk
and waste resources when the client has no intention of resuming the
connection.

In the context of web browsers, I believe that the Tor Browser would prefer
to have this, since it disables session resumption to prevent the leaking
of the tracking identifier inherent in it. It would also be useful for any
(non-browser) application for which a 1-RTT handshake per connection is
good enough, which is probably most applications, especially many
server-to-server applications.

Cheers,
Brian
--
https://briansmith.org/

---

From: Dave Garrett <[email-masked]>
Date: Sat, 18 Jul 2015 01:36:22 -0400

> https://github.com/tlswg/tls13-spec/issues/137
[...]
> I've written up a short proposal with idea about how I'd suggest going
> about this

> I don't think this is that useful or practical with the current structure
[...]
>  server's database or in a ticket isn't a threat to the originating connection.
> 

Ok, it looks like this late night idea isn't really needed anymore for at least this set of use-cases.

> handshaking. (And, so should the client.)

Ah, so just a simple empty extension would suffice for your main concern. I went with a simple alert to satisfy your 3rd point in the RFE along with 1 and 2.

> server-to-server applications.

Ok, then I'll move the other little wording fixes/simplifications in there into my main WIP branch and set this idea aside for the time being. If the ability to easily request an ephemeral TLS session at-will sounds particularly useful to anyone, then we can discuss it further and I could submit a PR.

Thanks,
Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 18 Jul 2015 18:21:49 +0000

Brian's description makes much more sense to me than Dave's suggestion.  I'd +1 the former and -1 the latter.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 18 Jul 2015 14:28:40 -0400

On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote:
> session resumable.

Ok, I might as well write up the generic solution then:

https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest

This is an extension to allow a client to optionally request a specific session ticket lifetime. It can request a zero lifetime to disable session resumption and have the server not cache anything, request a max uint32 lifetime to request the maximum lifetime the server is willing to offer (up to the server if it wants to allow a longer lifetime than default), or request any specific lifetime (again, honoring is optional).

The extension is just a single uint32 value; including overhead, this is a total of 8 bytes.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 19 Jul 2015 15:50:16 +0300

> https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest

Are the features besides "don't bother making resumable session, I won't
resume." needed?

E.g. For what would client hinting session lifetime be useful for?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Jul 2015 14:56:22 +0200

I'm not seeing a lot of value here. Remember that servers are not
required (and have never been required) to do session resumption, but
much of the overhead of doing it (having to have a database, session
ticket machinery) is associated with being willing to do session
resumption at all, so if a small fraction of clients would tell
you that they're not interested in resumption, it's not clear that
buys you much.

Are there any server operators who think this is a useful feature
and can explain why?

-Ekr

On Sun, Jul 19, 2015 at 2:50 PM, Ilari Liusvaara <
[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Jul 2015 17:16:57 +0000

> Are there any server operators who think this is a useful feature

These days, I'm operating servers that only support session tickets
(no server-side cache).  If the client does not send the session
ticket extension, no session is cached.

So for servers that elect the same strategy, there's no need for
a separate means to signal the client's intentions.

-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Sun, 19 Jul 2015 16:17:10 -0400

> a separate means to signal the client's intentions.

First, I think that there should be only one way to do resumption in TLS
1.3 anyway. All I'm asking for is that the client have some way of
indicating whether or not it supports resumption. Viktor's method seems
fine with me.

Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
actually contains a regression here. It seems like it is no longer possible
for the server to indicate how long a PSK should be held by the client to
resume a session, and it seems like it is no longer possible for the server
to indicate that it doesn't support resumption.

I don't know that the lifetime hint is valuable, but being able to reduce
attack surface by being disabling resumption for a session seems clearly
useful. See https://www.secure-resumption.com/, CVE-2014-1490 in
Firefox/NSS, and CVE-2015-1791 in OpenSSL, which show that it can be useful
to avoid resumption in many cases.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Jul 2015 22:26:45 +0200

On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith <[email-masked]> wrote:

> resume a session,

Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint
value.

http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12

and it seems like it is no longer possible for the server to indicate that
> it doesn't support resumption.
>

Well, it can't indicate it, but if it doesn't supply a session ticket,
there's no way for
the client to do it.

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Sun, 19 Jul 2015 16:40:15 -0400

> Well, it can't indicate it, but if it doesn't supply a session ticket,

Great. I was misunderstanding. Here's the part that is not is still not
clear to me: Is the SessionTicket extension still to be used or not? It
seems not, AFAICT. If the SessionTicket extension were to be used, then
everything would work perfectly as Viktor suggested in his message: the
absense of the SessionTicket extension in the ClientHello would be the way
that a client can indicate that it doesn't want the session to be cached.

It seems weird that the server can supply a lifetime hint but the client
can't, especially in cases like WebRTC where there is no functional
difference between the two. But, that's a smaller issue than the lack of an
indication that resumption machinery isn't wanted at all.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Jul 2015 22:49:10 +0200

On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith <[email-masked]> wrote:

>> and it seems like it is no longer possible for the server to indicate
>>> that it doesn't support resumption.
>>>
>>

No, it's not used.

> indication that resumption machinery isn't wanted at all.

I don't think it's *that* odd, since tickets have at least two fundamental
asymmetries:

- The client needs to actually keep state and the server does not
(that being the point of tickets)
- The client (because they speak first) gets to offer the ticket for
resumption and the server can accept it or reject it.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sun, 19 Jul 2015 16:58:02 -0400

> > that a client can indicate that it doesn't want the session to be cached.

This draft spec explicitly obsoletes RFC 5077. (listed up top)
https://tools.ietf.org/html/rfc5077#section-3.2

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Jul 2015 21:03:56 +0000

On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:

> Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not?

While we now have

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4

       In TLS 1.2 and below, this functionality was provided by "session
       resumption" and "session tickets" [RFC5077].  Both mechanisms are
       obsoleted in TLS 1.3.

at the same time we also have:

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11

       After the server has received the client Finished message, it MAY
       send a NewSessionTicket message.  This message MUST be sent before
       the server sends any application data traffic, and is encrypted under
       the application traffic key.  This message creates a pre-shared key
       (PSK) binding between the resumption master secret and the ticket
       label.  The client MAY use this PSK for future handshakes by
       including it in the pre_shared_key extension in its ClientHello
       (Section 6.3.1.5.4) and supplying a suitable PSK cipher suite.

	 struct {
	     uint32 ticket_lifetime_hint;
	     opaque ticket<0..2^16-1>;
	 } NewSessionTicket;

       ticket_lifetime_hint
	  Indicates the lifetime in seconds as a 32-bit unsigned integer in
	  network byte order.  A value of zero is reserved to indicate that
	  the lifetime of the ticket is unspecified.

       ticket
	  The value of the ticket to be used as the PSK identifier.

and

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4

       The pre_shared_key extension is used to indicate the identity of the
       pre-shared key to be used with a given handshake in association with
       a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).

         opaque psk_identity<0..2^16-1>;

	     struct {
	       select (Role) {
		 case client:
		   psk_identity identities<0..2^16-1>;

		 case server:
		   psk_identity identity;

	     } PreSharedKeyExtension;

       identifier
	  An opaque label for the pre-shared key.

So indeed it is no longer possible for the client to signal the
ability/desire to resume sessions, and servers will generate session
tickets absent any indication that the client intends to use them.

This does not impose a space penalty on the server, but some CPU
and bandwidth may be wasted on clients that don't or can't resume.

> It seems not, AFAICT. If the SessionTicket extension were to be used, then

In the current 1.3 draft, there is indeed no client signal.

> difference between the two. But, that's a smaller issue than the lack of
> an indication that resumption machinery isn't wanted at all.

The client lifetime is not that useful with session tickets anyway,
whether the client caches at all, could be, but it is not clear
that the resulting "inefficiency" needs to be fixed.  The fix would
be for the client to send an empty extension of some sort to signal
its desire to elicit a session ticket.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Jul 2015 21:09:41 +0000

> https://tools.ietf.org/html/rfc5077#section-3.2

However, part of RFC 5077 remains applicable:

       The ticket itself is an opaque label.  It MAY either be a
       database lookup key or a self-encrypted and self-authenticated
       value.  Section 4 of [RFC5077] describes a recommended ticket
       construction mechanism.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Jul 2015 23:10:42 +0200

> and bandwidth may be wasted on clients that don't or can't resume.

Yes.

So my question is whether there are an appreciably large number of servers
each of which have an appreciably large fraction of *both* caching and
non-caching clients to make an optimization like this worthwhile (servers
which only have non-caching or only caching clients can just send
or not send a ticket as appropriate)

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sun, 19 Jul 2015 17:14:14 -0400

[...]
> The fix would be for the client to send an empty extension of some
> sort to signal its desire to elicit a session ticket.

Why is the SessionTicket TLS Extension being deprecated at all? Sure, obsolete the RFC, but include the same extension in the TLS 1.3 spec with the same semantics for requesting a ticket from the server (0-length to request). This could be backwards compatible easily enough.

Dave

---

From: Brian Smith <[email-masked]>
Date: Sun, 19 Jul 2015 17:28:27 -0400

> (that being the point of tickets)

It depends on how the server implements tickets. The server could implement
tickets the same way that it implements session ID-based resumption. That's
not a good idea, but I don't think the spec should prohibit that type of
implementation either since it unenforceable. Thus, because of that
possibility, it is valuable to have the client be able to say "don't cache
the session" and/or limit the session's lifetime, so the client can help
direct the level of forward secrecy for the session. Right now, only the
server has a say in how long a session will be forward-secret.

Note also that the NewSessionTicket extension precedes any application
data, so without a way to prevent an unwanted NewSessionTicket message from
being sent, the client has to waste effort and time to consume the
NewSessionTicket before it can do anything useful.

Anyway, I don't understand why you keep directing your question to server
vendors. The people that would be interested in such a feature are client
software vendors, for client software that wants to control the level of
forward secrecy for a session.

Cheers,
Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Jul 2015 21:35:20 +0000

> or not send a ticket as appropriate)

Such a mixture of clients is not at all uncommon with SMTP.  Not
all MTAs implement client-side TLS session caches (no such cache
in Exim or Sendmail).  However, sending a session ticket either
way is not a major burden for SMTP servers.  It would however be
nice to not waste resources doing so, if an appropriate extension
(say the existing one) were used to signal client support.

This is not an absolutely compelling argument in favour of client
signalling, more of an observation that it could be useful.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Jul 2015 21:42:57 +0000

On Sun, Jul 19, 2015 at 05:28:27PM -0400, Brian Smith wrote:

> Thus, because of that

I think this is too much complexity, for too little gain.  Servers
will limit the lifetime of local session storage rather severely
to avoid running out of space.

> NewSessionTicket before it can do anything useful.

This is typically much smaller than the server certificate chain,
so the cost saving is marginal.

> forward secrecy for a session.

I don't think the client would gain much if any control by signalling
a lifetime hint.  With actual session tickets, the key rotation
lifecycle determines the effective forward-secrecy exposure (to
server state compromise before a key is retired) of the ticket,
and no client hint can influence that in any way.

So I agree with Eric that the issue is fundamentally a server-side
issue, modulo the fact that the CPU and bandwidth cost of processing
the unwanted ticket is borne on both sides.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sun, 19 Jul 2015 18:12:54 -0400

> NewSessionTicket before it can do anything useful.

If the general ticket lifetime request route is not needed, here's the simplest route: just don't drop the Session Ticket extension.

https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension

This keeps it with the same semantics for requesting a ticket, thus allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 servers with no additional effort. TLS 1.3 sessions would be resumed using the new PSK-based method and TLS 1.2 sessions would be resumed using the old session ticket extension.

Should I submit this as a PR? It seems like the obvious route if all we want is to just keep the ability for a client to not request a ticket. No need to write a new extension at all.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jul 2015 06:27:42 +0200

On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith <[email-masked]> wrote:

> It depends on how the server implements tickets. The server could
> implement tickets the same way that it implements session ID-based
> resumption. That's not a good idea, but I don't think the spec should
> prohibit that type of implementation either since it unenforceable.
>

I don't think that the current spec does so.

> Thus, because of that possibility, it is valuable to have the client be
> able to say "don't cache the session" and/or limit the session's lifetime,
> so the client can help direct the level of forward secrecy for the session.
> Right now, only the server has a say in how long a session will be
> forward-secret.
>

I think perhaps you have misunderstood the forward secrecy properties of the
current draft. Unlike TLS 1.2 and previous, the current draft has a separate
resumption master secret which is independently derived from the master
secret used for the connection keys in the original connection. This means
that if you don't resume the connection, you have forward secrecy for the
original connection regardless of whether the server stores the session in
the session cache or sends the client a ticket.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jul 2015 06:27:46 +0200

On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett <[email-masked]>
wrote:

> implement
> If the general ticket lifetime request route is not needed, here's the
> simplest route: just don't drop the Session Ticket extension.
>
>
> This keeps it with the same semantics for requesting a ticket, thus
> allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2
> servers with no additional effort. TLS 1.3 sessions would be resumed using
> the new PSK-based method and TLS 1.2 sessions would be resumed using the
> old session ticket extension.
>
> Should I submit this as a PR? It seems like the obvious route if all we
> want is to just keep the ability for a client to not request a ticket. No
> need to write a new extension at all.

As I said initially, I'm having trouble seeing why this is particularly
useful.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Mon, 20 Jul 2015 03:04:24 -0400

> the session cache or sends the client a ticket.

We've got lots of keys and secrets now. Could you please clarify the exact points where these are each to be discarded? If I am understanding it correctly, the master_secret, prior intermediate secrets, and finished_secret are to be discarded as soon as the keys, resumption_secret, and possibly exporter_secret (which currently has no explanation in the doc) are derived, the handshake is finished, and we're ready for application traffic? It would help if you provided a table/chart laying out the timeline of secret & key lifetimes, from derivation to discard. It should state in the spec explicitly what needs to be kept around for how long and require things be discarded as soon as viable.

I think these various values need to be named more consistently in the doc to make searching for them easier. For example, "resumption_secret" is used in the computation part but the words "resumption master secret" are used when actually using this value. (also noted in issue #191 by Martin Thomson) I've pushed a small PR to correct this case along with a few tweaks that I think makes it a bit clearer.
https://github.com/tlswg/tls13-spec/pull/205

Also, some other questions about various computations:

https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1
https://tlswg.github.io/tls13-spec/#key-schedule

HKDF(,,,) doesn't seem to be fully defined here, just HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. Could you please clarify this?

Why is finished_secret derived from extracted static secret instead of master_secret? There's a TODO about changes to use of the master_secret here; could you explain this bit please? (I assume this is a work in progress)

Are there two finished_secret in the event that the client sends a certificate?

The computation of verify_data could probably be moved up to the same section so this is all in the same place. Am I correct in reading that it could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, finished_label, handshake_hash, L) without the extra HMAC currently defined for verify_data)

Thanks,
Dave

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jul 2015 09:10:42 +0200

On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <[email-masked]>
wrote:

> We've got lots of keys and secrets now. Could you please clarify the exact
> points where these are each to be discarded? If I am understanding it
> correctly, the master_secret, prior intermediate secrets, and
> finished_secret are to be discarded as soon as the keys, resumption_secret,
> and possibly exporter_secret (which currently has no explanation in the
> doc) are derived, the handshake is finished, and we're ready for
> application traffic? It would help if you provided a table/chart laying out
> the timeline of secret & key lifetimes, from derivation to discard. It
> should state in the spec explicitly what needs to be kept around for how
> long and require things be discarded as soon as viable.
>

Yes, I can do something along these lines.

> I think these various values need to be named more consistently in the doc
> to make searching for them easier. For example, "resumption_secret" is used
> in the computation part but the words "resumption master secret" are used
> when actually using this value. (also noted in issue #191 by Martin
> Thomson) I've pushed a small PR to correct this case along with a few
> tweaks that I think makes it a bit clearer.
> HKDF(,,,) doesn't seem to be fully defined here, just
> HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869.
> Could you please clarify this?
>

Yes.

> Why is finished_secret derived from extracted static secret instead of
> master_secret?

The rationale here is that the Finished message also serves to authenticate
the server's ephemeral DH share (when in known_configuration mode) and
because the master secret depends on the ephemeral DH keys, this creates
an odd authentication logic. Hugo can expand on this some more, perhaps.

> Are there two finished_secret in the event that the client sends a

No, this shouldn't be necessarily. You just use the first one. I'll try to
clarify.

> The computation of verify_data could probably be moved up to the same
> section so this is all in the same place. Am I correct in reading that it
> could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret,
> finished_label, handshake_hash, L) without the extra HMAC currently defined
> for verify_data)

See above.

-ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 20 Jul 2015 10:31:15 -0700

​​

On Mon, Jul 20, 2015 at 12:10 AM, Eric Rescorla <[email-masked]> wrote:

>> We've got lots of keys and secrets now. Could you please clarify the
>> exact points where these are each to be discarded? If I am understanding it
>> I think these various values need to be named more consistently in the
>> doc to make searching for them easier. For example, "resumption_secret" is
>> used in the computation part but the words "resumption master secret" are
>> used when actually using this value. (also noted in issue #191 by Martin

​Eric's explanation is correct.
Your question boils down to: Why is finished_secret derived from SS only
and not from ES?

First note that the issue only arises in the known_configuration case since
in other cases ES and SS are the same.
For the known_configuration case there are t
wo important reasons
​ to build on SS and not on ES:
​
1. Only SS can authenticate the handshake as it is the only element to
involve the server's (semi) static private key.
2. One of the main elements to be authenticated by the server (via the
Finished message) is the ServerKeyShare, thus deriving the key for the
Finished message (i.e. finished_secret) from ES (calculated using
ServerKeyShare) would create a circularity issue in the logic of the
derivation.

Note that the derivation of application keys (and other key material
remaining after the end of the handshake) do involve both SS and ES, but in
that case involving ES is crucial to achieve forward secrecy.

Hugo
​

---

From: Dave Garrett <[email-masked]>
Date: Mon, 20 Jul 2015 14:19:37 -0400

On Monday, July 20, 2015 01:31:15 pm Hugo Krawczyk wrote:
> For the known_configuration case there are two important reasons
> ​to build on SS and not on ES:
> ​

Thanks for the explanation.

Using the master secret could work, but adding the ES isn't productive so using the SS directly makes more sense than mixing SS+ES first.

Dave