Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54)

From: =JeffH <[email-masked]>
Date: Tue, 26 Jul 2016 07:00:51 -0700

> +	Thus, Token Binding implementations providing an Application Programming Interface (API) should 
> +	provide means for applications to produce Token Binding messages containing Token Binding values
> +	for application-specified TLS connections,
> +	such as by identifying the connections or by supplying the corresponding EKM values.
> +      </t>
> +      <t>
> +	The application needs to be able to denote the Token Binding type (e.g., provided, referred, etc.)
> +	to be used in the message for each specified connection (or EKM value),
> +	as well as the TLS connection the application will send the Token Binding message over.
> +	The result should be a Token Binding message containing Token Binding values
> +	bound to an application-specified TLS connection over which the Token Binding message is sent.
> +	Additionally, see <xref target="privacy-cons"/> <xref target="privacy-cons" format="title"/>,
> +	which provides further guidance regarding the use of this functionality.
> +      </t>
> +    </section>
> +

Thanks for making these mods, Mike!

regarding the above section..

hmm, this spec is overall written in terms of "client", rather than "(web) user agent". E.g., the latter term is first introduced in the section preceding this one and occurs only a few times. So I think we can simplify the first paragraph accordingly. Plus, the second paragraph essentially repeats info that's in the first. 

how about the below build on the above?

```
<t>
  HTTPS-based applications may have multi-party use 
  cases other than, or in addition to, the HTTP redirect-based 
  signaling-and-conveyance of referred token bindings, as 
  presented above in <xref target="sctn-http-redir">.
</t>
<t>
  Thus, generic Token Binding implementations intended to support 
  any HTTPS-based client-side application (e.g., so-called "native 
  applications"), should provide means for applications to have 
  Token Binding messages, containing Token Binding IDs of various 
  application-specified Token Binding types and 
  for application-specified TLS connections, conveyed over an
  application-specified HTTPS connection, i.e., within the 
  TokenBindingMessage conveyed by the Sec-Token-Binding header
  field. 
  <list style="hanging" hangIndent="7">
    <t hangText="NOTE:">
      See <xref target="privacy-cons"/> 
      "<xref target="privacy-cons" format="title"/>",
      for privacy guidance regarding the use of 
      this functionality.
     </t>
  </list>
</t>
```

[ fyi/fwiw, the markup for the NOTE is as I used in RFC6797 and passed muster with the rfc-editor ]

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/pull/54/files/71df58b4e95382123ec8bedd39b3f525171350a4#r72254548

---

From: =JeffH <[email-masked]>
Date: Tue, 26 Jul 2016 07:40:51 -0700

> +	  also having Token Binding information for these connections
> +	  does not provide additional correlation information.
> +	  However, if not, by providing Token Bindings,
> +	  then there is potential to expose additional information
> +	  that could be used to correlate the endpoints that different parties are communicating with.
> +	  In these cases, a privacy analysis of correlations enabled
> +	  and the potential privacy impacts of those correlations should be performed
> +	  as part of the decision whether to utilize token binding in those cases.
> +	</t>
> +	<t>
> +	  Care should be taken to ensure that unrelated applications cannot obtain information
> +	  about each other's Token Bindings.
> +	  For instance, a Token Binding implementation shared between multiple applications on a machine
> +	  should prevent unrelated applications from seeing each other's Token Binding information.
> +	  Application isolation and key segregation should be used to prevent this.
> +	</t>

wordsmith suggestions on the above two paragraphs...

<t>
An application's communicating parties, that receive Token Bindings for TLS connections other than their own, obtain information about the application's other TLS connections. The Token Binding IDs in these other Token Bindings can serve as correlation handles for the endpoints of the other connections.
If the application is already aware of these other connections, then no additional information is being exposed. For instance, if in a redirect-based federation protocol, the Identity Provider and Relying Party already have URLs for one another, also having Token Binding information for these connections does not provide additional correlation information.
If not, then by providing the other Token Bindings there is potential to expose additional information that can be used to correlate the endpoints the other parties are communicating with.
In such cases, a privacy analysis of enabled correlations and their potential privacy impacts should be performed as part of the application design decisions of how, and whether, to utilize Token Bindings.
</t>
<t>
Also, care should be taken to ensure that unrelated applications cannot obtain information about each other's Token Bindings. For instance, a Token Binding implementation shared between multiple applications on a given system should prevent unrelated applications from obtaining each other's Token Binding information. This may be accomplished by using  techniques such as application isolation and key segregation, depending upon system capabilities.
</t>

HTH,

=JeffH

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/pull/54/files/71df58b4e95382123ec8bedd39b3f525171350a4#r72262727

---

From: =JeffH <[email-masked]>
Date: Mon, 01 Aug 2016 23:30:03 -0700

@equalsJeffH pushed 1 commit.

448a276  build upon language in HTTPSTB impl cons & priv cons

---
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/pull/54/files/71df58b4e95382123ec8bedd39b3f525171350a4..448a276e23f9c4e94dcd00f90237204f0bd6d617

---

From: =JeffH <[email-masked]>
Date: Mon, 01 Aug 2016 23:35:38 -0700

fb333e9  fix up line breaks to be readable in github diff

---
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/pull/54/files/448a276e23f9c4e94dcd00f90237204f0bd6d617..fb333e90a8f38d536472972d376202955ae90ce7

---

From: Nick Harper <[email-masked]>
Date: Tue, 02 Aug 2016 09:44:12 -0700

> @@ -937,6 +965,42 @@ contexts. Other approaches are possible, but are outside the scope of this speci
>            mechanisms.
>          </t>
>        </section>
> +        <section title="Correlation" anchor="Correlation">
> +          <t>
> +            An application's communicating parties, that receive 
> +            Token Bindings for TLS connections other than their own, 
> +            obtain information about the application's other TLS 
> +            connections.
> +            The Token Binding IDs in these other Token Bindings can 
> +            serve as correlation handles for
> +            the endpoints of the other connections.
> +            If the application is already aware of these other 
> +            connections, then no additional information is being exposed. 

I'm still confused here. Is the application something like a native app, which is acting as an https client? Are these "other connections" ones that the application makes? If both of those are true, then it's trivial to see that the application is always aware of these other connections. However, I suppose that's not what this means, so I'm wondering what the definitions are of "the application" and "other connections".

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/pull/54/files/fb333e90a8f38d536472972d376202955ae90ce7#r73192044

---

From: =JeffH <[email-masked]>
Date: Fri, 19 Aug 2016 16:44:04 -0700

@equalsJeffH pushed 3 commits.

dc49fce  fixed xref tag closure
b24896a  polish api guidance prose. fixes #53
c919c7b  further polishing

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/pull/54/files/fb333e90a8f38d536472972d376202955ae90ce7..c919c7bfa5158d5d932f291c199c7d0d43bb8ed8