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

[Benjamin Kaduk <[e-mail]>]

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