Subject: [Unbearable] comments on draft-ietf-tokbind-tls13-0rtt-01

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Mar 2017 21:49:52 -0500

We appear to have a rather tight dependency between this document
and the core TLS 1.3 spec in section 2.2.1, where we require the
server to MUST NOT accept early data if the negotiated token binding
key parameter does not match teh parameter from the initial
connection, which is the same behavior as ALPN and SNI.  It seems
like this might require the formal "Updates: <TLS 1.3>" absent a
change to the TLS 1.3 document in the current state of the document,
since we only have a token_binding_replay_indication TLS extension,
which does not match up exactly with this requirement.  However, if
we went to a new TLS extension to indicate willingness to do 0-RTT
and token binding together (in addition to the existing early_data
and token binding extensions), that seems like it would not need the
formal "Updates:" marker.  (Ekr, can you check me on that?)

Given the semantics of early data with external PSKs, I find it
rather dangerous to allow token binding in such setups, and would
prefer that we forbid it rather than just saying that the token
binding parameters must be provisioned along with the PSK.  (Does
anyone have a use case in mind for this?)

I think the last sentence of the second paragraph of section 3
should probably be more explictily scoped to clarify that it is
attempting to support 0-RTT that is problematic; the software for
one.example.com can support 0-RTT but not use it for that domain, in
which case sharing the cert for h2 is fine.

I'm not sure that I believe the text in section 5.4 that claims that
when a peer implements complete replay protection, the other peer
does not need to implement such a mitigation; it seems to ignore the
possibility that the first peer could become compromised.

I made a note that there should probably be more consideration of
external PSKs in the second paragraph of section 5.1 and in section
5.5.

-Ben

---

From: Nick Harper <[email-masked]>
Date: Wed, 29 Mar 2017 14:10:58 -0700

Thanks for your comments. Replies inline:

> formal "Updates:" marker.  (Ekr, can you check me on that?)

The core TLS 1.3 spec also requires that any new extensions MUST
define their interaction with 0-RTT (section 4.2.8). Assuming that TLS
1.3 is published before TBNEGO, I think TBNEGO would define an initial
interaction (e.g. forbidding the combination of TB and 0-RTT), it
would possibly update TLS 1.3, and this draft would update TBNEGO to
redefine the interaction with 0-RTT. I'm removing the
token_binding_replay_indication TLS extension, so that shouldn't
matter.

I'm leaning towards defining a new TLS extension for indicating
support of TB and 0-RTT on the same connection. It would be nice to
know more of the rules for when the "Updates: " marker is needed.
> anyone have a use case in mind for this?)

I don't have a use-case in mind for Token Binding in early data with
external PSKs, and would be fine with forbidding that combination.
> which case sharing the cert for h2 is fine.

That paragraph is already making assumptions about how h2 interacts
with 0-RTT TLS 1.3 (which isn't specified). Specifically, it is
assuming that both one.example.com and two.example.com support 0-RTT,
and that requests for both domains could get coalesced onto a single
connection in early data. (This is a lot to assume, and may be
incorrect. A draft describing how to use h2 over 0-RTT TLS 1.3
connections might be useful.) The problem is that two.example.com
could receive a request with a 0-RTT Token Binding message and bound
token, when two.example.com only expects Token Binding as specified in
TBPROTO, and doesn't know how to handle that 0-RTT Token Binding
message. I think it's fine for two.example.com to serve a cert with
both one and two in its SAN, but not the other way around. I will work
on clarifying and expanding the language in this section.
> possibility that the first peer could become compromised.

I think the logic here was that if one peer does something that
guarantees that a message can't be replayed, then even if the other
peer is compromised and tries to replay a message, the first peer will
prevent the replay from happening. Of course, this has no indication
whether the first message was legitimate.
> external PSKs in the second paragraph of section 5.1 and in section

Hopefully we can remove support for external PSKs and this point will
be moot. If we don't, I agree there should be more consideration
given, as I haven't given it much thought yet.
>
> -Ben
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Nick Harper <[email-masked]>
Date: Wed, 29 Mar 2017 15:30:11 -0700

Are the concerns around external PSKs based on how they are
provisioned, or them being used without (EC)DHE?

I see 4 possible combinations: (PSK from a NewSessionTicket,
externally provisioned PSK)x(ECDHE key exchange, pure PSK), all of
which have different security considerations. I'd be fine limiting
this to just NewSessionTicket PSKs used with ECDHE key exchange.