Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

From: =JeffH <[email-masked]>
Date: Fri, 19 Aug 2016 17:20:27 -0700

Nick Harper wrote on Mon, 25 Jul 2016 15:21:15 -0700...
 >
 > I'm still concerned that the privacy concerns are not being addressed
 > with this proposal. Section 4.1 of the HTTPS draft states that the
 > common idea among the federation mechanisms is that the server
 > signals to the client to reveal its provided TBID to another server
 > (with the Include-Referred-Token-Binding-ID header being one such
 > mechanism). However, the wording in this pull request makes no
 > indication that the use of this API to set referred TBIDs would be
 > limited to when the referring server indicates to do so.

I've added some commits to 
https://github.com/TokenBinding/Internet-Drafts/pull/54 addressing the 
above, as well as line-level comments Nick made in github.

 > The new section in "Privacy Considerations"

..entitled "Correlation"..

 > is missing some of the
 > cases of correlation that could happen. Suppose Example App decides
 > to send a referred TBID (for its connection to example.com) on every
 > HTTPS request it makes, and it happens to make requests to evil1.com
 > and evil2.com (whose operators are trying to correlate traffic
 > between them). This referred TBID is the same on both requests, and
 > the site operators can now correlate requests, whereas if the app
 > didn't (mis)use the API for setting referred TBIDs, the site
 > operators wouldn't have been able to use Token Binding to correlate
 > the requests. I think this example contradicts the wording that
 > states "If the application is already aware of these other
 > connections to these endpoints, then no additional information is
 > being exposed." In this case, the application is aware of the
 > connections (to evil1.com and evil2.com), yet the referred TBIDs that
 > it sends can be used for correlation, which is additional information
 > being exposed.

I believe the proposed language does address the above scenario -- the 
app misuses the API, and ignores the advice in the "correlation" section 
of the spec, specifically to do a privacy analysis.

 > I also wouldn't mind the Privacy Considerations
 > section reiterating the point that a referred TBID should only be
 > sent when indicated to do so by the referring server.

done.

HTH,

=JeffH

---

From: Mike Jones <[email-masked]>
Date: Sat, 20 Aug 2016 00:24:07 +0000

I'm good with these changes and comments.  Thanks for doing this, Jeff!

				-- Mike

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Friday, August 19, 2016 5:20 PM
To: IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance

 >
 > I'm still concerned that the privacy concerns are not being addressed  > with this proposal. Section 4.1 of the HTTPS draft states that the  > common idea among the federation mechanisms is that the server  > signals to the client to reveal its provided TBID to another server  > (with the Include-Referred-Token-Binding-ID header being one such  > mechanism). However, the wording in this pull request makes no  > indication that the use of this API to set referred TBIDs would be  > limited to when the referring server indicates to do so.

I've added some commits to
https://github.com/TokenBinding/Internet-Drafts/pull/54 addressing the above, as well as line-level comments Nick made in github.

 > is missing some of the
 > cases of correlation that could happen. Suppose Example App decides  > to send a referred TBID (for its connection to example.com) on every  > HTTPS request it makes, and it happens to make requests to evil1.com  > and evil2.com (whose operators are trying to correlate traffic  > between them). This referred TBID is the same on both requests, and  > the site operators can now correlate requests, whereas if the app  > didn't (mis)use the API for setting referred TBIDs, the site  > operators wouldn't have been able to use Token Binding to correlate  > the requests. I think this example contradicts the wording that  > states "If the application is already aware of these other  > connections to these endpoints, then no additional information is  > being exposed." In this case, the application is aware of the  > connections (to evil1.com and evil2.com), yet the referred TBIDs that  > it sends can be used for correlation, which is additional information  > being exposed.

I believe the proposed language does address the above scenario -- the app misuses the API, and ignores the advice in the "correlation" section of the spec, specifically to do a privacy analysis.

 > I also wouldn't mind the Privacy Considerations  > section reiterating the point that a referred TBID should only be  > sent when indicated to do so by the referring server.

done.

HTH,

=JeffH

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