Subject: Re: [Unbearable] WGLC 3 on core documents

From: Andrei Popov <[email-masked]>
Date: Wed, 1 Mar 2017 20:43:19 +0000

Thanks, Martin, for the detailed review.

There are a few comments I'd like to reply to:
> (The extensions field is even less well justified, it has zero uses.)
Just wanted to point out that there is already an I-D that explores a possible use of TB extensions: https://tools.ietf.org/html/draft-mandyam-tokbind-attest-00

> Any interactions with a server that might result in the creation of a token that requires this level of protection necessarily take multiple round trips.  
> Thus, negotiating the use of this extension in the application protocol is perfectly feasible.
This actually seems to be true for the bulk of the TB deployments that I see being worked on. However, some folks in this WG won't agree with this (e.g. Google wants to use TB even with TLS 1.3 0-RTT application data, which I feel conflicted about).

> a token provider might not support the signature scheme that is negotiated with a token consumer.  Therefore, the token provider might be unable to verify the signature on the referred token binding
This is possible, but in this case the Token Provider is not supposed to issue a bound token. We've agreed to treat this case as a misconfiguration, because it appears reasonable to expect coordination between the IDP and the associated RPs.

> Inclusion in the token is not necessary.  The token could reference server-side state and THAT could include the public key.
This option is mentioned later on (section 5). I've chosen to streamline the introduction by describing one option that seems most likely to be used.

> The attacker only needs to be able to *use* the client's private key.
Correct.

> The MUST NOT forbids negotiating use of token binding in other ways.
> Other than the fact that you *can't* send a token binding in the clear, I see no reason to include this clause.
The idea is to make sure the server (which may be a compound, distributed entity) does not bind tokens when receiving spurious/erroneous/malicious TB messages.
We can remove "via [I-D.ietf-tokbind-negotiation]" so that this is not read as prohibiting other forms of negotiation.

> I observe that it is strange to omit leading zeros in one case and require them in another.
It may be strange, but I'd rather avoid re-opening this can of worms. It was hard enough to get everyone to agree to what we have...

> More odd that it doesn't cover extensions (which makes me feel further vindicated in asking for their removal).
I expect that e.g. the attestation extension will contain a signature over the preceding bytes in the message. If this signature itself were to be included in TokenBinding.signature, we'd have a chicken and egg problem...

> In TLS 1.3, the context of NULL is the same as an empty sequence.
> That might be cause for some confusion.
I don't mind changing this to simply say " no application context supplied".

>    servers from linking user identities, different keys SHOULD be used
>   by the client for connections to different servers
> Why only SHOULD?
I believe there was some opposition to MUST, for deployments where the client has knowledge of the cooperating servers. If nobody opposes a switch to MUST, I think it may be a good change to make.

> "the server MUST discard the token" - this is wrong, because it implies that the server might ignore the token.  In the HTTP case at least the server is required to reject the request.  
> "the server MUST treat the token as invalid" might be better, but that leaves a lot to the application protocol.
For consistency with the rest of the text, I suggest "the server MUST reject the token".

>  The idea that token binding keys are especially high value isn't borne out by deployment experience.  
> I believe that no implementation is willing to apply additional protection for these keys due to the performance cost that imposes.
On the contrary, Windows provides additional protections for TB keys, compared with cookies. And these protections are being improved in the new releases, even though it does come at a performance cost.

> "Token Binding IDs are never transmitted in clear text" - do you actually require that?
Yes:
"The Token Binding message is sent with the application protocol data over TLS."
"TokenBinding.signature MUST
   be a signature of the EKM value derived from the TLS master secret
   that produced the session keys encrypting the TLS application_data
   record(s) containing this TokenBinding."

> I've also already shared my view on the version field in here.  That's going to rust closed, if it isn't already.
We've discussed this in the WG extensively. The consensus was to stick with the version field.

> Does the working group intend to remove the following?  
Yes, we can add a note for the RFC editor.

> It also implies that there can be no gaps in version support and that client MUST support a contiguous range of all versions from {0, 0} up to the version they advertise, otherwise the server might pick a version they don't know.
There is no such implication for TB, similarly to TLS version negotiation. The server may pick a version the client does not know (as e.g. TLS servers may do). In this case, Token Binding is simply not negotiated.

> Given that a client MUST send a Token Binding message when it is negotiated (see comment about that above), this creates a problem when the first message arrives at the server without a Token Binding message - the server and client now disagree about whether they have enabled the feature.
It's not that they disagree. The client finds out once the server has responded (or not) with a TB extension. The server finds out whether TB is negotiated when the first application message arrives.

Cheers,

Andrei

---

From: Brian Campbell <[email-masked]>
Date: Wed, 1 Mar 2017 14:21:58 -0700

> I believe there was some opposition to MUST, for deployments where the
> client has knowledge of the cooperating servers. If nobody opposes a switch
> to MUST, I think it may be a good change to make.

Yes there's a desire for the allowance of different scoping rules for
application protocols where there's already knowledge of the cooperating
servers and/or correlatable info is already being sent in a token to
different servers.

Also that text is in the TBPROTO document and the sentence also has,
"according to the token scoping rules of the application protocol."

A MUST would be too strong here. SHOULD is appropriate and should stay.

On Wed, Mar 1, 2017 at 1:43 PM, Andrei Popov <[email-masked]>
wrote:

> Just wanted to point out that there is already an I-D that explores a
> possible use of TB extensions: https://tools.ietf.org/html/
> draft-mandyam-tokbind-attest-00
>
> > Any interactions with a server that might result in the creation of a
> token that requires this level of protection necessarily take multiple
> round trips.
> This actually seems to be true for the bulk of the TB deployments that I
> see being worked on. However, some folks in this WG won't agree with this
> (e.g. Google wants to use TB even with TLS 1.3 0-RTT application data,
> which I feel conflicted about).
>
> > a token provider might not support the signature scheme that is
> negotiated with a token consumer.  Therefore, the token provider might be
> unable to verify the signature on the referred token binding
> This is possible, but in this case the Token Provider is not supposed to
> issue a bound token. We've agreed to treat this case as a misconfiguration,
> because it appears reasonable to expect coordination between the IDP and
> the associated RPs.
>
> > Inclusion in the token is not necessary.  The token could reference
> server-side state and THAT could include the public key.
> This option is mentioned later on (section 5). I've chosen to streamline
> the introduction by describing one option that seems most likely to be used.
>
> The idea is to make sure the server (which may be a compound, distributed
> entity) does not bind tokens when receiving spurious/erroneous/malicious TB
> messages.
> We can remove "via [I-D.ietf-tokbind-negotiation]" so that this is not
> read as prohibiting other forms of negotiation.
>
> It may be strange, but I'd rather avoid re-opening this can of worms. It
> was hard enough to get everyone to agree to what we have...
>
> I expect that e.g. the attestation extension will contain a signature over
> the preceding bytes in the message. If this signature itself were to be
> included in TokenBinding.signature, we'd have a chicken and egg problem...
>
> I believe there was some opposition to MUST, for deployments where the
> client has knowledge of the cooperating servers. If nobody opposes a switch
> to MUST, I think it may be a good change to make.
>
> > "the server MUST discard the token" - this is wrong, because it implies
> that the server might ignore the token.  In the HTTP case at least the
> server is required to reject the request.
> > "the server MUST treat the token as invalid" might be better, but that
> leaves a lot to the application protocol.
> > I believe that no implementation is willing to apply additional
> protection for these keys due to the performance cost that imposes.
> On the contrary, Windows provides additional protections for TB keys,
> compared with cookies. And these protections are being improved in the new
> releases, even though it does come at a performance cost.
>
> > I've also already shared my view on the version field in here.  That's
> going to rust closed, if it isn't already.
> > It also implies that there can be no gaps in version support and that
> client MUST support a contiguous range of all versions from {0, 0} up to
> the version they advertise, otherwise the server might pick a version they
> don't know.
> There is no such implication for TB, similarly to TLS version negotiation.
> The server may pick a version the client does not know (as e.g. TLS servers
> may do). In this case, Token Binding is simply not negotiated.
>
> > Given that a client MUST send a Token Binding message when it is
> negotiated (see comment about that above), this creates a problem when the
> first message arrives at the server without a Token Binding message - the
> server and client now disagree about whether they have enabled the feature.
> It's not that they disagree. The client finds out once the server has
> responded (or not) with a TB extension. The server finds out whether TB is
> negotiated when the first application message arrives.
>
> Cheers,
>
> Andrei
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 10:43:06 +1100

> servers and/or correlatable info is already being sent in a token to

That's not an argument for SHOULD, that's an argument for flexibility
in scoping rules, which you already have.  Since the application
protocol determines the scoping rules, you can let the MUST stand and
define scoping rules for the application protocol that suit your
needs.

---

From: Nick Harper <[email-masked]>
Date: Wed, 1 Mar 2017 15:55:50 -0800

On Tue, Feb 28, 2017 at 9:51 PM, Martin Thomson
<[email-masked]> wrote:
> I don't believe that referred token bindings need a signature.  Adding
> a signature only creates busy work for clients.  My rationale is this:
> negotiated with a token consumer.  Therefore, the token provider might
> be unable to verify the signature on the referred token binding.  If a
> security proof were to depend on the token provider verifying that
> signature, we have an entirely different set of constraints on the
> design (and a three-way negotiation to somehow build).  The attack in
> Section 7.4 of the HTTP doc is thwarted simply by having the client
> send its TBID to the Token Provider.
>
I recall a previous discussion around referred token bindings and
whether a signature is needed. In that discussion, the approach
considered is that in the Token Consumer's (TC) request to the Token
Provider (TP), the TC asks for a token that is bound to the TBID
between the client and TC (call this TBID C). This had the problem
that if there was a MitM between the client and TC (and the MitM uses
TBID M for connections from the MitM (on "behalf" of the client) to
TC), then the MitM can change that request of TP "provide a token
bound to C" to "provide a token bound to M". The key takeaway from
this discussion was that whatever mechanism is used to refer a TBID
needs to show that the provided and referred TBIDs belong to the same
client. Having a signature from both keys is an obvious way to do
that.

I do believe that it is possible to keep that property without
requiring a signature for referred token bindings. Suppose that a
TokenBindingMessage contains a provided TokenBinding (with signature,
as TBPROTO currently specifies) and a list of referred TokenBindingIDs
(with no signatures). Assuming the token binding signature verifies,
the server knows that the provided TBID belongs to the peer (client)
on the other end of the connection. The server also knows that the
client is the only one capable of writing things on that connection.
If the protocol is structured in a way that this list of (or single)
referred TBID(s) is only included upon a signal like the
"Include-Referred-Token-Binding-ID" (and it is up to the client to
determine what that referred TBID is, instead of the referrer saying
"please include TBID X"), I think the server can assume that the
client would only include a TBID as a referred TBID if it is one that
belongs to that client.

I am in favor of removing signatures for referred token bindings.
Doing so removes the ambiguity around a token provider possibly being
unable to verify the signature on a referred binding. It also removes
the complexity around EKM lengths and Brian Campbell's TTRPs.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 10:56:38 +1100

I've elided responses that look fine, or don't need further comment.

> Just wanted to point out that there is already an I-D that explores a possible use of TB extensions: https://tools.ietf.org/html/draft-mandyam-tokbind-attest-00

I can't really assess that given its current level of detail.  It
doesn't really define what an attestation *is* (there is some hint in
TUDA, but it doesn't really show how a recipient might decide to
*trust* the attestation).

> This actually seems to be true for the bulk of the TB deployments that I see being worked on. However, some folks in this WG won't agree with this (e.g. Google wants to use TB even with TLS 1.3 0-R…

I'm conflicted about that too, but I also think that can be made
orthogonal.  0-RTT is by definition only possible on a second
interaction with the server.  So you have already spent round trips.

> This is possible, but in this case the Token Provider is not supposed to issue a bound token. We've agreed to treat this case as a misconfiguration, because it appears reasonable to expect coordina…

My point is that it isn't necessary from a security perspective.  The
Token Provider only needs to know that the TBID is correct (a property
which we assume is provided by TLS + the other TB message.

> This option is mentioned later on (section 5). I've chosen to streamline the introduction by describing one option that seems most likely to be used.

It's a little misleading, is all.

> We can remove "via [I-D.ietf-tokbind-negotiation]" so that this is not read as prohibiting other forms of negotiation.

That might work.  On this point, is the -negotiation draft a mandatory
requirement for the -http doc, but not the main one?  Is that the
organization we have here?

> It may be strange, but I'd rather avoid re-opening this can of worms. It was hard enough to get everyone to agree to what we have...

Oh, I missed the original worm can opening.  I thought that was the
X9.62 thing, which I expressly did not mention (I was obviously in the
weeds there).  It was an observation only.

> I expect that e.g. the attestation extension will contain a signature over the preceding bytes in the message. If this signature itself were to be included in TokenBinding.signature, we'd have a ch…

Ugh, really?  Why not create a new token binding *type* then and avoid
the whole mess.  The only wrinkle there is that you have to make the
content type-based.

> "The Token Binding message is sent with the application protocol data over TLS."

That doesn't MUST NOT anything else though.

> There is no such implication for TB, similarly to TLS version negotiation. The server may pick a version the client does not know (as e.g. TLS servers may do). In this case, Token Binding is simply…

If the working group thinks that this is OK, I will step back, but I
think that's not a great design.

Note that you do need to define rules for comparing versions.  Those
don't exist yet as far as I can see.

> It's not that they disagree. The client finds out once the server has responded (or not) with a TB extension. The server finds out whether TB is negotiated when the first application message arrive…

I see that you manage to avoid this being a problem by only mandating
that the client *send* a TB message, not that the server enforce the
presence of a TB message.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 11:00:18 +1100

> client. Having a signature from both keys is an obvious way to do

This is only a problem if the Token Consumer is able to tell the
client which TBID to use.  I had assumed that the TC had no control
over this, it's a boolean flag and there can be only one.

Note sure that you motivated having a list here.  Unless you were
intending to also do something about the redirect chain issue.

---

From: Nick Harper <[email-masked]>
Date: Wed, 1 Mar 2017 16:13:36 -0800

> intending to also do something about the redirect chain issue.

I was only including a list since the current structure of a
TokenBindingMessage allows for multiple referred TBIDs. I wasn't
trying to change how a redirect chain would work. If we change TBPROTO
to have signature-less referred token bindings, I think the
TokenBindingMessage would to change to one of the following:

struct {
    TokenBinding provided_token_binding;
    TokenBindingID referred_token_binding_id;
} TokenBindingMessage;

or

struct {
    TokenBinding provided_token_binding;
    TokenBindingID referred_token_binding_ids<0..2^16-1>;
} TokenBindingMessage;

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 11:51:27 +1100

> TokenBindingMessage would to change to one of the following:

I would have thought that you would instead make the message contents
dependent on the type.  That would be consistent with the needs of any
future addition of attestations, which have yet another format.

As I mentioned in my review, I would also prefer to see the entire
contents of the message signed.  Thus:

struct {
  TokenBindingType type;
  TokenBindingContent content<1..2^16-1>;
  opaque signature<1..2^16-1>;
} TokenBindingMessage;

The signature would cover type, the content length and the content in
an ideal situation.

And then you can define per-type content, which for a regular message
is just one TBID, or, for a referred TB, two (or many, still can't
grok the use case for that - AND or OR?).

---

From: Andrei Popov <[email-masked]>
Date: Thu, 2 Mar 2017 01:02:00 +0000

> As I mentioned in my review, I would also prefer to see the entire contents of the message signed.
This does not work if we want to use extensions for attestation.

> I would have thought that you would instead make the message contents dependent on the type.
The TB type is not supposed to define the format of the TB message. Its purpose is to distinguish first-party bindings from 3rd-party/federated bindings.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 12:23:08 +1100

> This does not work if we want to use extensions for attestation.

I can't really test this statement because I don't know what an
attestation necessarily entails.

> The TB type is not supposed to define the format of the TB message. Its purpose is to distinguish first-party bindings from 3rd-party/federated bindings.

That's only really justifiable if you are certain that you only ever
include a signature over a public key.  As the attestation case
highlights, there are more things that you might want to say than just
"I control this key".  Gaining some flexibility might be the way to do
that.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 2 Mar 2017 01:41:34 +0000

> If the protocol is structured in a way that this list of (or single) referred TBID(s) is only included upon a signal like the "Include-Referred-Token-Binding-ID" 
> (and it is up to the client to determine what that referred TBID is, instead of the referrer saying "please include TBID X"), 
> I think the server can assume that the client would only include a TBID as a referred TBID if it is one that belongs to that client.

A few issues with this:
1. There are multiple ways federation may work, and only some of them have the above properties.
2. The specific federation mechanisms are beyond the scope of TBPROTO, and it is this way because different application protocols have different federation mechanisms. At the same time, I would like the base protocol to retain its security properties, regardless of the federation mechanism.
3. If we include referred TB IDs only, the Token Issuer/IDP has no way to cryptographically verify that the client controls the corresponding private key.

I think that eliminating the signature on the referred bindings makes the protocol less secure and potentially narrows the range of scenarios where it can be used.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 14:06:23 +1100

> I think that eliminating the signature on the referred bindings makes the protocol less secure and potentially narrows the range of scenarios where it can be used.

If we had more formal analysis of the protocol, we might be able to
have these discussions without resorting to "I think" statements.  If
your claim is that a client might, under different circumstances, be
coerced into making a claim that it controlled a key that it did not
in fact control, that's an extraordinary claim requiring extraordinary
evidence.

I totally see how a client might be tricked into using the wrong key
in some different protocol - even in HTTP if there truly is a MitM -
but that doesn't provide anything other than a denial of service.  The
MitM is more than capable of causing that to happen without resorting
to trickery though.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 2 Mar 2017 06:44:28 -0700

> define scoping rules for the application protocol that suit your

Yes it's an argument for flexibility. My concern is with how the text might
be interrupted. With the SHOULD to MUST change you're suggesting, it would
say,

 "In order to prevent cooperating
   servers from linking user identities, different keys MUST be used
   by the client for connections to different servers, according to the
   token scoping rules of the application protocol."

And I worry that some will zero in on the "different keys MUST be used by
the client for connections to different servers" and take it very literally
(especially the "to different servers" part) and out of context of the rest
of the sentence that qualifies it with respect to the application protocol
token scoping rules. Maybe that worry is unfounded but having it be SHOULD
felt like it helps give that flexibility.

I take your point though.

What if it just said,

 "In order to prevent cooperating
   servers from linking user identities, different keys MUST be used
   by the client, according to the
   token scoping rules of the application protocol."

taking the "different servers" bit out?

---

From: Andrei Popov <[email-masked]>
Date: Thu, 2 Mar 2017 21:27:10 +0000

Without “different servers”, it is not clear what these keys are supposed to be different from. ☺

How about this:
“In order to prevent cooperating servers from linking user identities, the scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by the application protocol.”

From: Brian Campbell [mailto:[email-masked]]
Sent: Thursday, March 2, 2017 5:44 AM
To: Martin Thomson <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Leif Johansson <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] WGLC 3 on core documents

On Wed, Mar 1, 2017 at 4:43 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Yes it's an argument for flexibility. My concern is with how the text might be interrupted. With the SHOULD to MUST change you're suggesting, it would say,

And I worry that some will zero in on the "different keys MUST be used by the client for connections to different servers" and take it very literally (especially the "to different servers" part) and out of context of the rest of the sentence that qualifies it with respect to the application protocol token scoping rules. Maybe that worry is unfounded but having it be SHOULD felt like it helps give that flexibility.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 2 Mar 2017 14:50:24 -0700

That works for me. Thanks.

On Thu, Mar 2, 2017 at 2:27 PM, Andrei Popov <[email-masked]>
wrote:

> Without “different servers”, it is not clear what these keys are supposed
> to be different from. J
>
>
>
> How about this:
>
> “In order to prevent cooperating servers from linking user identities, the
> scope of the Token Binding keys MUST NOT be broader than the scope of the
> tokens, as defined by the application protocol.”
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Thursday, March 2, 2017 5:44 AM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* Andrei Popov <[email-masked]>; Leif Johansson <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Unbearable] WGLC 3 on core documents
>
>
>
>
>
>
>
> Yes it's an argument for flexibility. My concern is with how the text
> might be interrupted. With the SHOULD to MUST change you're suggesting, it
> would say,
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 2 Mar 2017 21:52:21 +0000

> If we had more formal analysis of the protocol, we might be able to have these discussions without resorting to "I think" statements.
Having a formal analysis would have been wonderful. My conclusion was derived from the 3 points listed right above the conclusion:)

> If your claim is that a client might, under different circumstances, be coerced into making a claim that it controlled a key that it did not in fact control, that's an extraordinary claim requiring extraordinary evidence.
A TB library sitting on a server has no knowledge of exactly how federation happens to be arranged, and what guarantees the federation mechanism provides. With the current design, the TB library does not need to know these things. It can simply make sure the client is in control of the TB private keys by verifying signatures.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, March 1, 2017 7:06 PM
To: Andrei Popov <[email-masked]>
Cc: Nick Harper <[email-masked]>; [email-masked]; Leif Johansson <[email-masked]>
Subject: Re: [Unbearable] WGLC 3 on core documents

> I think that eliminating the signature on the referred bindings makes the protocol less secure and potentially narrows the range of scenarios where it can be used.

If we had more formal analysis of the protocol, we might be able to have these discussions without resorting to "I think" statements.  If your claim is that a client might, under different circumstances, be coerced into making a claim that it controlled a key that it did not in fact control, that's an extraordinary claim requiring extraordinary evidence.

I totally see how a client might be tricked into using the wrong key in some different protocol - even in HTTP if there truly is a MitM - but that doesn't provide anything other than a denial of service.  The MitM is more than capable of causing that to happen without resorting to trickery though.