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

[Nick Harper <[e-mail]>]

Thanks for your comments. Replies inline:

On Tue, Mar 28, 2017 at 7:49 PM, Benjamin Kaduk <[e-mail]> wrote:
> 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?)

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.
>
> 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 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.
>
> 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.

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.
>
> 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 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.
>
> 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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/unbearable