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

[Nick Harper <[e-mail]>]

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.

On Wed, Mar 29, 2017 at 2:10 PM, Nick Harper <[e-mail]> wrote:
> 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