Subject: Re: [Unbearable] Token Binding for 0-RTT connections

From: Nick Harper <[email-masked]>
Date: Mon, 3 Oct 2016 17:55:38 -0700

Hi all,
I've uploaded a new draft:
https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The
biggest change is an addition of a TLS extension to indicate that replay
protections are in place. I also expanded the security considerations to
describe what those replay protections might look like. If you think the
replay protections should go elsewhere in the doc, I'm fine moving them
around. My rationale for putting them in security considerations is that
someone might come up with a way to implement replay protection that isn't
in the doc, and I don't want to proscribe that they must use something from
the doc if they come up with something better. (The new extension is
normative.)
Cheers,
Nick

On Thu, Sep 22, 2016 at 11:51 AM, Bill Cox <[email-masked]> wrote:

> On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov <[email-masked]
> > wrote:
>
>> My feedback for draft-nharper-0-rtt-token-binding-00 is that merely
>> discussing 0-RTT TB’s weaker security properties in the security
>> considerations is not sufficient.
>>
>>
>>
>> I think it would make sense to define the mitigation options we’ve come
>> up with so far, and some way to indicate the protection(s) that are in
>> place, so that a peer can make an informed decision whether to use 0-RTT TB
>> or not.
>>
>
> I agree.  I also would prefer a mitigation techniques for 0-RTT security
> concerns section in the TLS 1.3 doc, but that did not make it in.  This is
> pretty similar stuff: we need anti-replay on the server, key protection on
> the client, and somehow we need to ensure signatures are fresh.  When we
> combine all that, I think we would have security very close to TB over
> 1-RTT resumption.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Oct 2016 12:23:46 +1100

I think that your analysis is a little mixed up here.  It seems that
you are assuming an attacker with only passive capabilities.

If the attacker has access to the PSK, then it will be able to decrypt
the entire connection unless a new (EC)DHE exchange is performed.
That means that an active attacker can interject at any moment and use
the connection from that point onward.

Replay protection doesn't help in that case.

On 4 October 2016 at 11:55, Nick Harper <[email-masked]> wrote:
>> On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov
>> <[email-masked]> wrote:
>>>
>> combine all that, I think we would have security very close to TB over 1-RTT
>> resumption.
>
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Nick Harper <[email-masked]>
Date: Mon, 3 Oct 2016 18:37:49 -0700

You're correct that if the attacker has access to the PSK, and it is used
in the PSK-only key establishment mode, then the attacker can take over the
connection. I was assuming that the PSK was for resumption and would only
be used in psk_dhe_ke mode. I wasn't intending to consider an attacker with
only passive capabilities. I briefly thought about the need for (EC)DHE
when writing section 6.1, but it looks like I need to give more thought to
pure PSK mode (and maybe the answer is require (EC)DHE).

On Mon, Oct 3, 2016 at 6:23 PM, Martin Thomson <[email-masked]>
wrote:

> 1-RTT

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Oct 2016 10:11:05 +0300

> the doc if they come up with something better. (The new extension is

Some points:

- The extracted value from EKM is presumably a binder, so it needs to
  be at least as long as the underlying PRF-hash.
- Section 4.1 seems pretty misleading. It seems to imply that the
  problem is dealing with possible race condition. This is wrong,
  the only way prolbems even remotely like these can happen is if
  the client explicitly splits a request between 0-RTT and 1-RTT[1].

[1] 0-RTT effectively suspends the handshake until it is complete.
There is no way for handshake to complete while 0-RTT is still in
progress.

-Ilari

---

From: Nick Harper <[email-masked]>
Date: Tue, 4 Oct 2016 17:35:03 -0700

>   be at least as long as the underlying PRF-hash.

 This draft uses the same length EKM as draft-ietf-tokbind-protocol (which
is fixed at 32 bytes). Does this mean that draft-ietf-tokbind-protocol
should use a longer EKM value if the TLS connection is using a larger PRF
hash?

>   the client explicitly splits a request between 0-RTT and 1-RTT[1].

The problem I'm addressing in section 4.1 is one of visibility of the
application (where it's processing Token Binding) into the state of the TLS
connection, not a race condition. Of course both the client and server TLS
stacks know whether the data sent/received is 0-RTT or 1-RTT. At some level
in the application, a decision is made whether the application data to
write can be sent 0-RTT, and that part will have the necessary visibility.
However, above that point there's no reason for it to be visible, and
that's where the Token Binding header is added to the request. A sane
client would likely send the entire HTTP request in early data, but a
pathological client could send just the first few bytes of the HTTP request
in early data, then drive the handshake to completion, and then send the
rest of the HTTP request. (Or a client might be buffering messages to send,
and not know at the time the message is prepared whether it will be sent in
early data or not.) A server receiving such a request would need to keep
track of when in the HTTP request the client sent switched from being sent
0-RTT vs 1-RTT so it can use the correct EKM to verify the
TokenBindingMessage. This is what I meant by a synchronization issue -
perhaps I should have described this problem differently or in more depth.

---

From: Bill Cox <[email-masked]>
Date: Mon, 10 Oct 2016 12:46:45 -0700

Nick's current draft of 0-RTT token binding for TLS 1.3 requires state be
remembered server-side (in the ticket), since the server has to reject the
0-RTT attempt if the client changed the key parameters vs the original
connection, and fall back to 1-RTT.  This cannot be supported by the
current custom extension API in BoringSSL or OpenSSL.  Also, the client
sends only one key parameter, rather than a list, so if the server falls
back to 1-RTT, it has only one choice of key parameters, unlike a regular
1-RTT handshake.

I think I agree with Nick on everything in his proposal, except for this
issue.  His point is that it is easier for us to modify BoringSSL to
support token binding as a native extension than it is to use the custom
extension API.  My point is that it may be very difficult to get the
OpenSSL folks to adopt a TLS 1.3 0-RTT token binding native extension
compared to continuing to use the custom extension API.

Just how hard should we try to continue using the custom extension API?  If
we decide to go with Nick's current proposal, should we push for OpenSSL to
enhance this API so we can add the negotiated key parameters to the ticket,
or should we push for incorporating token binding natively?

Bill

---

From: Nick Harper <[email-masked]>
Date: Mon, 10 Oct 2016 13:19:13 -0700

> back to 1-RTT, it has only one choice of key parameters, unlike a regular

The client still sends a list of key parameters in the TB extension in the
ClientHello (on a 0-RTT connection), so if the server falls back to 1-RTT
it can choose a different parameter. (I think a previous draft had the
client sending only one to avoid the server having to remember, with the
downside of not being able to choose a new parameter.)

> Just how hard should we try to continue using the custom extension API?
> If we decide to go with Nick's current proposal, should we push for OpenSSL
> to enhance this API so we can add the negotiated key parameters to the
> ticket, or should we push for incorporating token binding natively?
>
> Bill
>