Subject: [Unbearable] wrt handling multiple sec-token-binding header occurrences

From: =JeffH <[email-masked]>
Date: Sun, 12 Feb 2017 21:18:03 -0800

There are some questions/pushback on this proposed text queued-up in the
repo for HTTPSTB..
<https://github.com/TokenBinding/Internet-Drafts/pull/94/files/6818906bb096a880f52404b31b999edfd2f388e0>..
 >
 > <t>If the server receives more than one Sec-Token-Binding header
 > field in an HTTP request, then the server MUST process only the first
 > such header field. If the processed Sec-Token-Binding header field
 > contains more than one EncodedTokenBindingMessage (e.g., delimited by
 > commas, see Section 3.2 of <xref target="RFC7230"/>), the server MUST
 > ignore the header field. [...]

..where some folks are saying (details below) that the server
should/must reject a received message if the message has multiple
Sec-Token-Binding header fields.

To explain the above-suggested language: we had to address essentially 
this situation when crafting RFC6797 HSTS [1] and RFC7469 HPKP [2]. The 
above language largely mirrors the latter specs' language.

Unfortunately, we did not state the rationale for this in either spec
(mea culpa wrt HSTS). Tho, this topic was discussed on the
[email-masked] mailing list during HPKP development which explicates 
the rationale..

   Re: [websec] Why are multiple PKP header fields allowed?
   <https://www.ietf.org/mail-archive/web/websec/current/msg02059.html>

..and although Ivan nominally pushed for message rejection..

   <https://www.ietf.org/mail-archive/web/websec/current/msg02065.html>

..the spec shipped with the "the UA MUST process only the first PKP
header field" language [2] (as HSTS did).

Given that receiving multiple STBs may end up being possible, due to 
HTTP intermediaries, see scenario 6 in [3], and also since we do not 
have reject-message language any longer in TBPROTO, and given the 
rationale behind the language in [1] & [2], I propose modifying the 
above-quoted language to be something like...

   If the server receives more than one Sec-Token-Binding header
   field in an HTTP request, then the server MAY process the first
   such header field, e.g., if the server is configured to receive
   connections from a reverse proxy. If the processed Sec-Token-Binding
   header field contains more than one EncodedTokenBindingMessage (e.g.,
   delimited by commas, see Section 3.2 of <xref target="RFC7230"/>),
   the server MAY process the first occurrence of
   EncodedTokenBindingMessage. Otherwise, the server SHOULD reject the
   message in some application-appropriate fashion.

=JeffH

[1] https://tools.ietf.org/html/rfc6797#section-8.1

[2] https://tools.ietf.org/html/rfc7469#section-2.3.1

[3] <http://kingsmountain.com/doc/draft-ietf-tokbind-figures-STB-TTRPs.txt>

@Andrei-Popov's comments:
<https://github.com/TokenBinding/Internet-Drafts/pull/94#discussion_r99971687>
 >
 > We're saying above that only one header is allowed, and only one TB
 > message must be in it. If the client violates these restrictions,
 > then we have a malformed request, and should simply reject this
 > request.

@balfanz replies:
 >
 > Rejecting the request is fine with me.
 >
 > So is ignoring subsequent header fields.
 >
 > So is saying that it's ok to submit multiple header fields (just
 > like it's ok to have multiple TokenBindingIDs in a
 > TokenBindingMessage), and just passing them all on to upper layers -
 > maybe that's how the client shows that it possesses multiple keys?
 >
 > (Maybe I have a slight preference for the latter.)
 >
 > Andrei - do you feel strongly about this? I'm willing to merge any of
 > those options into the main branch.

@nharper replies:
 > My preference would be to reject a request with multiple
 > Sec-Token-Binding headers.

@b---c (brian campbell) notes:
 > +1 to reject a request with multiple Sec-Token-Binding headers

@Andrei-Popov's replies:
 > I think the spec should be definitive: since we’re saying the client
 >  should only send one TB header per request, and only one TB message
 >  per header, then the server should be at liberty to enforce this.
 >
 > If we allow variation, e.g. it’s OK to send multiple TB headers per
 > request, then we need to define when and how one would use this
 > mechanism. And at this point in the process I don’t think we should
 > be adding new mechanisms to TB v 1.0.

@balfanz wonders:
 > Don't we allow multiple TokenBinding structures within a
 > TokenBindingMessage? Seems to me that the server already has to be
 > able to deal with multiple proofs-of-possession. Allowing multiple
 > header fields is just another way that we might end up with multiple
 > proofs-of-possession - it's not exactly a "new mechanism".
 >
 > But like I said, I don't feel strongly about it. I'm happy to have
 > the spec say that the server should (must?) reject if there are
 > multiple headers.

@Andrei-Popov's replies:
 > Correct, we do allow multiple bindings within a TB message (and to
 > me that's an existing mechanism:).
 >
 > Supporting the same thing via multiple header fields requires a code
 > change, and so far I see no reason to maintain two ways (or
 > mechanisms:) to do the same thing.

[ aside: this'd be a whole lot easier if github.com comments/issues/etc 
in the TokenBinding/Internet-Drafts were sent to this list - which was 
set up at one time but appears to have quit working... ]

---

From: Andrei Popov <[email-masked]>
Date: Mon, 13 Feb 2017 18:42:35 +0000

Per PKP thread referenced below:
"No matter where the header is injected (first or second),
it's never wrong reject both. It certainly feels safer to me; after all
we know that that response is contaminated."

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Sunday, February 12, 2017 9:18 PM
To: IETF TokBind WG <[email-masked]>
Subject: [Unbearable] wrt handling multiple sec-token-binding header occurrences

There are some questions/pushback on this proposed text queued-up in the repo for HTTPSTB..
<https://github.com/TokenBinding/Internet-Drafts/pull/94/files/6818906bb096a880f52404b31b999edfd2f388e0>..
 >
 > <t>If the server receives more than one Sec-Token-Binding header  > field in an HTTP request, then the server MUST process only the first  > such header field. If the processed Sec-Token-Binding header field  > contains more than one EncodedTokenBindingMessage (e.g., delimited by  > commas, see Section 3.2 of <xref target="RFC7230"/>), the server MUST  > ignore the header field. [...]

..where some folks are saying (details below) that the server should/must reject a received message if the message has multiple Sec-Token-Binding header fields.

To explain the above-suggested language: we had to address essentially this situation when crafting RFC6797 HSTS [1] and RFC7469 HPKP [2]. The above language largely mirrors the latter specs' language.

Unfortunately, we did not state the rationale for this in either spec (mea culpa wrt HSTS). Tho, this topic was discussed on the [email-masked] mailing list during HPKP development which explicates the rationale..

..the spec shipped with the "the UA MUST process only the first PKP header field" language [2] (as HSTS did).

Given that receiving multiple STBs may end up being possible, due to HTTP intermediaries, see scenario 6 in [3], and also since we do not have reject-message language any longer in TBPROTO, and given the rationale behind the language in [1] & [2], I propose modifying the above-quoted language to be something like...

=JeffH

 >
 > We're saying above that only one header is allowed, and only one TB  > message must be in it. If the client violates these restrictions,  > then we have a malformed request, and should simply reject this  > request.

@balfanz replies:
 > So is saying that it's ok to submit multiple header fields (just  > like it's ok to have multiple TokenBindingIDs in a  > TokenBindingMessage), and just passing them all on to upper layers -  > maybe that's how the client shows that it possesses multiple keys?
 >
 > (Maybe I have a slight preference for the latter.)  >  > Andrei - do you feel strongly about this? I'm willing to merge any of  > those options into the main branch.

@nharper replies:
 > My preference would be to reject a request with multiple  > Sec-Token-Binding headers.

@Andrei-Popov's replies:
 > I think the spec should be definitive: since we’re saying the client  >  should only send one TB header per request, and only one TB message  >  per header, then the server should be at liberty to enforce this.
 >
 > If we allow variation, e.g. it’s OK to send multiple TB headers per  > request, then we need to define when and how one would use this  > mechanism. And at this point in the process I don’t think we should  > be adding new mechanisms to TB v 1.0.

@balfanz wonders:
 > Don't we allow multiple TokenBinding structures within a  > TokenBindingMessage? Seems to me that the server already has to be  > able to deal with multiple proofs-of-possession. Allowing multiple  > header fields is just another way that we might end up with multiple  > proofs-of-possession - it's not exactly a "new mechanism".
 >
 > But like I said, I don't feel strongly about it. I'm happy to have  > the spec say that the server should (must?) reject if there are  > multiple headers.

@Andrei-Popov's replies:
 > Correct, we do allow multiple bindings within a TB message (and to  > me that's an existing mechanism:).
 >
 > Supporting the same thing via multiple header fields requires a code  > change, and so far I see no reason to maintain two ways (or  > mechanisms:) to do the same thing.

[ aside: this'd be a whole lot easier if github.com comments/issues/etc in the TokenBinding/Internet-Drafts were sent to this list - which was set up at one time but appears to have quit working... ]

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable