Subject: [TLS] judging consensus on keys used in handshake and data messages

From: Joseph Salowey <[email-masked]>
Date: Wed, 6 Jul 2016 09:39:53 -0800

We are the unenviable position of calling consensus between three choices
[0]:

- Option 1 - use the same key for both handshake and applications messages.
- Option 2 - restore a public content type and different keys.
- Option 3 - separately encrypting the content type.

At this point the consensus is rough.

The first option we would broadly characterize as supported by the
implementers because they can’t see the harm in using the same key but
opposed by the cryptographers because it makes the proofs harder making
mistakes easier to miss.

The second option as supported by researchers/cryptographers because it
cleanly separates the keys used but opposed by the implementers because
it’s unnecessarily complex.  In general, privacy advocates do not support
this option either.

The third was not really discussed at all and it’s not clear what is the
impact to security proofs or implementations.

As we see it the privacy concerns are somewhat of a moving target, however
not encrypting the content type seems worse for privacy than encrypting it.

We are looking to eliminate option 2 and choose 1 or 3.  If you are in
favor of option 2 then we need to know if option 1 meets your needs, if
option 3 is better than option 1, or if you feel that the only viable
option is option 2.

J&S

[0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBuiNA

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2016 22:00:02 +0200

Hi Joe,

it might be interesting to note that in the context of the DTLS 1.3
discussion with Ilari it appears that the epoch exposes handshake
messages (vs. application data) since you need a way to find out what
key was used to encrypt the message (and msgs may get re-ordered or lost).

So, I claim that even if you manage to go for option 1 in TLS 1.3 you
will most likely have a kind of option 2 in DTLS 1.3 (unless you get rid
of the epoch value, which is of course possible).

This does not really answer your question but I don't have a strong
opinion between #1 and #2. Separately encrypting the content type sounds
feels a bit too radical to me.

Ciao
Hannes

On 07/06/2016 07:39 PM, Joseph Salowey wrote:
> We are the unenviable position of calling consensus between three
> choices [0]:
> 
> it’s unnecessarily complex.  In general, privacy advocates do not
> support this option either.
> 
> As we see it the privacy concerns are somewhat of a moving target,
> however not encrypting the content type seems worse for privacy than
> encrypting it.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Jul 2016 00:11:39 +0300

Hi, Joe

> On 6 Jul 2016, at 8:39 PM, Joseph Salowey <[email-masked]> wrote:
> 
> We are the unenviable position of calling consensus between three choices [0]:
> 
> The first option we would broadly characterize as supported by the implementers because they can’t see the harm in using the same key but opposed by the cryptographers because it makes the proofs harder making mistakes easier to miss.   
> 
> The second option as supported by researchers/cryptographers because it cleanly separates the keys used but opposed by the implementers because it’s unnecessarily complex.  In general, privacy advocates do not support this option either.
> 
> The third was not really discussed at all and it’s not clear what is the impact to security proofs or implementations.  
> 
> As we see it the privacy concerns are somewhat of a moving target, however not encrypting the content type seems worse for privacy than encrypting it.
> 
> We are looking to eliminate option 2 and choose 1 or 3.  If you are in favor of option 2 then we need to know if option 1 meets your needs, if option 3 is better than option 1, or if you feel that the only viable option is option 2.

I will re-iterate my opposition to option 2. Some occurrences on non-application data records within a TLS session are initiated by user action or application state. Best example is when the user sees a login page and clicks the button that says “Log in with certificates…” causing (in TLS 1.2) a HelloRequest to be send and a renegotiation with client certificates, or (in TLS 1.3) a CertificateRequest to be sent followed by the client sending a certificate. This is not some theoretical weakness. This is real information disclosure. With TLS 1.2 you can look at the Wireshark screen, point to the handshake record in the middle of the TCP flow and know that this is where the user pressed the button.

Of options 1 and 3, I can see that #3 is theoretically better, but the design seems too baroque to me. I hope it can be done without adding a whole new block operation to each record, and I prefer the simplicity of #1, but I’m not really opposed to #3. IIRC there were some cryptographers who were concerned about #1. We haven’t heard from them that #3 solves their issue, have we?

Yoav

---

From: David Benjamin <[email-masked]>
Date: Wed, 06 Jul 2016 22:19:29 +0000

On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir <[email-masked]> wrote:

> I will re-iterate my opposition to option 2. Some occurrences on
> non-application data records within a TLS session are initiated by user
> action or application state. Best example is when the user sees a login
> page and clicks the button that says “Log in with certificates…” causing
> (in TLS 1.2) a HelloRequest to be send and a renegotiation with client
> certificates, or (in TLS 1.3) a CertificateRequest to be sent followed by
> the client sending a certificate. This is not some theoretical weakness.
> This is real information disclosure. With TLS 1.2 you can look at the
> Wireshark screen, point to the handshake record in the middle of the TCP
> flow and know that this is where the user pressed the button.
>
> Of options 1 and 3, I can see that #3 is theoretically better, but the
> design seems too baroque to me. I hope it can be done without adding a
> whole new block operation to each record, and I prefer the simplicity of
> #1, but I’m not really opposed to #3. IIRC there were some cryptographers
> who were concerned about #1. We haven’t heard from them that #3 solves
> their issue, have we?
>

I'm also curious which post-handshake messages are the problem. If we were
to rename "post-handshake handshake messages" to "post-handshake bonus
messages" with a distinct bonus_message record type, where would there
still be an issue? (Alerts and application data share keys and this seems
to have been fine.)

For post-handshake client auth, is
draft-bishop-httpbis-http2-additional-certs-01 still the plan for HTTP/2?
It seems to me that, whatever we do for the HTTP/1.1 + TLS 1.3 case, we
need to solve certificate auth hosted in application data anyway. So we
don't gain anything overall for HTTP if these messages share fate with
handshake vs. application data. And, as you note, this is where the
information disclosure is particularly bad.

The KeyUpdate messages themselves seem so inconsequential that I likewise
can't imagine key separation is particularly important. But I don't
understand the proof-related concerns, so perhaps I'm confused.

NewSessionTicket I am willing to buy should share fate with the handshake
and not application data. Though it still doesn't seem worth the complexity
tradeoff to me. (With the caveat I, again, don't actually understand the
proof-related concerns.)

David

---

From: Dave Garrett <[email-masked]>
Date: Wed, 6 Jul 2016 20:24:46 -0400

> still be an issue? (Alerts and application data share keys and this seems

Recasting all the post-handshake handshake messages as not something named "handshake" does make a degree of sense, on its own. (bikeshedding: I'd name it something more descriptive like "secondary negotiation" messages or something, though.) Even if this doesn't directly help with the issue at hand here, does forking these into a new ContentType sound like a useful move, in general?

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Jul 2016 17:39:04 -0700

On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <[email-masked]> wrote:

> Recasting all the post-handshake handshake messages as not something named
> "handshake" does make a degree of sense, on its own. (bikeshedding: I'd
> name it something more descriptive like "secondary negotiation" messages or
> something, though.) Even if this doesn't directly help with the issue at
> hand here, does forking these into a new ContentType sound like a useful
> move, in general?

I'm not sure what this would accomplish.

-Ekr

---

From: David Benjamin <[email-masked]>
Date: Thu, 07 Jul 2016 00:49:00 +0000

On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <[email-masked]> wrote:

>> Recasting all the post-handshake handshake messages as not something
>> named "handshake" does make a degree of sense, on its own. (bikeshedding:
>> I'd name it something more descriptive like "secondary negotiation"
>> messages or something, though.) Even if this doesn't directly help with the
>> issue at hand here, does forking these into a new ContentType sound like a
>> useful move, in general?
>
>

Me neither. To clarify, I mention this not as a suggestion, but to motivate
asking about the type of message. If the only reason the proofs want them
in the handshake bucket rather than the application data bucket is that
they say "handshake" in them then, sure, let's do an inconsequential
re-spelling and move on from this problem.

But presumably something about the messages motivate this key separation
issue and I'd like to know what they are.

David

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Thu, 7 Jul 2016 07:10:20 +0200

If we are left with 1 or 3, the miTLS team would prefer 1.

On the cryptographic side, Hugo has a recent (draft) paper that seems to provide
some more justification for (1), at least for client authentication. 

I know this is a bit off-topic, but the miTLS team would also like to get rid of 0-RTT ClientFinished 
if that is the only message left in the 0-RTT encrypted handshake flight. That should remove
another Handshake/Data key separation from the protocol, leaving only 3 keys: 0-RTT data,
1-RTT handshake, and 1-RTT data. 

Best,
-Karthik

> On 07 Jul 2016, at 02:49, David Benjamin <[email-masked]> wrote:
> 
> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <[email-masked] <mailto:[email-masked]>> wrote:
> Me neither. To clarify, I mention this not as a suggestion, but to motivate asking about the type of message. If the only reason the proofs want them in the handshake bucket rather than the application data bucket is that they say "handshake" in them then, sure, let's do an inconsequential re-spelling and move on from this problem.
> 
> But presumably something about the messages motivate this key separation issue and I'd like to know what they are.
> 
> David

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 7 Jul 2016 10:27:01 +0300

> If we are left with 1 or 3, the miTLS team would prefer 1.

Yeah, me too.

> On the cryptographic side, Hugo has a recent (draft) paper that seems
> to provide some more justification for (1), at least for client
> authentication. 

Personally, I would be very surprised if (1) the way it is used in -13
turned out broken, unless the application did very odd things (that
would likely render security of 2 or 3 questionable as well).

But perhaps there is some very nontrivial way to screw up using just
one key, a way that doesn't involve rather obvious mistakes, e.g.

- Encryption failing basic security notions.
- Context-sensitive messages.
- Rather obviously disclosing or leaking keys.
- Broken channel muxing.
- Applications carelessly doing raw read/write.

For the above, either nothing obvious comes up with draft-13 designs
or using multiple keys wouldn't really help.

For DTLS, I noticed that there might be issues with replay of handshake
messages (key separation obivously wouldn't help here). Fortunately,
all messages that are in DTLS seem to be idempotent... As extra safety
measure, one could require handshake messages to be always be replay-
checked (turning replay checking off would only turn it off for appdata
messages and leave it on for handshake messages).

> I know this is a bit off-topic, but the miTLS team would also like
> to get rid of 0-RTT ClientFinished if that is the only message left
> in the 0-RTT encrypted handshake flight. That should remove another
> Handshake/Data key separation from the protocol, leaving only 3 keys:
> 0-RTT data, 1-RTT handshake, and 1-RTT data. 

Oh yeah, that message is sure annoying to handle...

And in (Stream)TLS, it is supposed to provode a MAC. Isn't there going
to be sending at least one encrypted 0-RTT data record (if only warning
alert 1)? Seems like that would provode a MAC.

Things are quite a bit different in DTLS tho: Since there is no
reliability for any appdata, without Finished there might not be a MAC
available even in case of 0-RTT being accepted.

Based on some quick thinking, I don't expect the previous to be a
problem, given that if 0-RTT keys are wrong, all the other keys are
almost certainly (within collision margins) wrong too, triggering an
abort on next encrypted record.

> > > I'm also curious which post-handshake messages are the problem.
> > > If we were to rename "post-handshake handshake messages" to
> > > "post-handshake bonus messages" with a distinct bonus_message
> > > record type, where would there still be an issue? (Alerts and
> > > application data share keys and this seems to have been fine.)

That wouldn't really help: It isn't distinction between main-handshake
and post-handshake messages that is the problem (those are key-separated
anyway!), but distinction between post-handshake and appdata messages
(or lack thereof).

> > Me neither. To clarify, I mention this not as a suggestion, but
> > to motivate asking about the type of message. If the only reason
> > the proofs want them in the handshake bucket rather than the
> > application data bucket is that they say "handshake" in them then,
> > sure, let's do an inconsequential re-spelling and move on from this
> > problem.
> > 
> > But presumably something about the messages motivate this key
> > separation issue and I'd like to know what they are.

What I think the issue here actually is:

If you are going to use the encryption key used for application data for
_anything_ else (such as using it to encrypt any sort of "control"
messages) you have to be careful that the uses "don't step on another's
toes". And then when doing security proofs, you need to also prove that
the uses don't interfere with each other.

There has obviously been some very bad communication here, so the above
understanding might not be correct...

-Ilari

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 7 Jul 2016 06:44:08 -0400

I do not have an objection to option 1 if re-phrased as
Option 1 - use the same key for protecting both *post*-handshake and
applications messages..

I believe this is what was intended by that option anyway. Let me clarify.

I understand the question as relating *only* to post-handshake messages and
not
to the main handshake (three initial flights). For the latter we have key
separation in the sense that none of these main-handshake messages is
encrypted
under the application key but rather under dedicated handshake keys. This
should
not be changed as it provides key indistinguishability to the application
key, a
desirable design and analysis (=proof) modularity property.

On the other hand, for post-handshake messages, and particularly for
encrypting
post-handshake client authentication messages, preserving key
indistinguishability is not relevant since at the time of post-handshake
client authentication, the application key has already lost its
indistinguishability
by the mere fact that the key was used to encrypt application data. Key
indistinguishability is the main reason to insist in key separation and this
principle does not apply here anymore hence removing the objection to 1.

I'd note that the best one could hope for in the post-handshake setting is
that
as a result of post-handshake client authentication the application key
becomes
a secure mutually-authenticated key for providing "secure channels"
security.
As pointed out by others in previous posts I have an analysis showing that
this
delayed mutual authentication guarantee is achieved even if one uses the
application key to encrypt the post-handshake messages. I have circulated a
preliminary version of the  paper among cryptographers working on TLS 1.3
and  I will post a public copy next week so this can be scrutinized further.

Hugo

On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> Me neither. To clarify, I mention this not as a suggestion, but to
> motivate asking about the type of message. If the only reason the proofs
> want them in the handshake bucket rather than the application data bucket
> is that they say "handshake" in them then, sure, let's do an
> inconsequential re-spelling and move on from this problem.
>

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 7 Jul 2016 21:47:37 +0200

With Hugo's analysis of the secure channel-like security afforded even when the application key is used to encrypt non-application data, and as Cédric pointed out to me the application key will be used to encrypt non-application data like certain alert messages; so I think option 1 is a reasonable choice, and option 3 would not recover the composability property we hoped it might.

Douglas

> On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk <[email-masked]> wrote:
> 
> Option 1 - use the same key for protecting both *post*-handshake and applications messages.. 
> 
> I understand the question as relating *only* to post-handshake messages and not
> separation in the sense that none of these main-handshake messages is encrypted
> under the application key but rather under dedicated handshake keys. This should
> not be changed as it provides key indistinguishability to the application key, a
> On the other hand, for post-handshake messages, and particularly for encrypting
> client authentication, the application key has already lost its indistinguishability
> I'd note that the best one could hope for in the post-handshake setting is that
> as a result of post-handshake client authentication the application key becomes
> a secure mutually-authenticated key for providing "secure channels" security.
> As pointed out by others in previous posts I have an analysis showing that this
> On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <[email-masked]> wrote:

---

From: Cas Cremers <[email-masked]>
Date: Fri, 8 Jul 2016 09:33:30 +0100

Hi,

After several discussions (including the ones Douglas points out) I have
also come round to option 1 as the preferred way forward. For our symbolic
analysis in Tamarin it should not make a big difference anyway.

Best,

Cas

On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila <[email-masked]> wrote:

> With Hugo's analysis of the secure channel-like security afforded even
> when the application key is used to encrypt non-application data, and as
> Cédric pointed out to me the application key will be used to encrypt
> non-application data like certain alert messages; so I think option 1 is a
> reasonable choice, and option 3 would not recover the composability
> property we hoped it might.
>
> Douglas
>
>

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 8 Jul 2016 05:49:38 -0800

We would like to have all comments in on this by Friday, July 7, 2016.

Also, to clarify, Hugo's interpretation is correct:

applications messages.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 8 Jul 2016 08:28:30 -0700

applications messages.

I don't object to this if 2 is of the table. The only reason this option is
reasonable is that we've carefully attempted to ensure keys are separated.
I'll submit a PR to add text warning of extensions that don't do this.
(Some exist IIRC).

applications messages..
encrypted
encrypting
indistinguishability
becomes
security.
>>> On the cryptographic side, Hugo has a recent (draft) paper that seems
to provide

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 18 Jul 2016 11:56:00 -0400

> and  I will post a public copy next week so this can be scrutinized

​Here is the promised posted paper
http://eprint.iacr.org/2016/711
"
A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with
Applications to Client Authentication in TLS 1.3)
​"​

Its analysis of client authentication is relevant to the different modes of
TLS 1.3 and, in particular, to post-handshake authentication. As said
above, the results support the use of the application key to encrypt the
post-handshake messages, hence avoiding the need to use a dedicated key for
this and the consequent need for trial decryption (or related techniques).

Comments on and off list are welcome.

Hugo
​