Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

From: =JeffH <[email-masked]>
Date: Mon, 22 Feb 2016 11:08:56 -0800

> What is your goal?  A direct coupling has the advantage that you don't
 > have a different STL created that does not meet the basic
 > requirements.

well, my goal, nominially as an exercise, is to generalize the spec for 
non-TLS underlying STL(s) as noted in..

<https://mailarchive.ietf.org/arch/msg/unbearable/thqNHlHciMBBijVdVV07Kbs8ohs>

..and the encompassing thread, given that Andrei was supportive and that the 
QUIC tokenbinding impl is ensconced in QUIC code..

<https://code.google.com/p/chromium/codesearch#search/&q=tokenbind%20file:^src/net/quic/&sq=package:chromium&type=cs>

..and there's a design doc..

Token Binding over QUIC
<https://docs.google.com/document/d/12eKfkdC7g5IGUCtghzg7Wi__qiEkY65fX09n8sjLtHg>

Of course, the working group and the spec editors need to formally decide 
whether this is a direction they in fact wish to head.

I note that the wg charter does not explicitly indicate that the TB Protocol 
will be applicable to only TLS, but also does not explicitly state 
generalization for other underlying STLs (secure transport layers). The 
charter does, however, wrt app layer protocols state (fwiw)..

"Make the Token Binding protocol useable in combination with a variety of 
application protocols"

 > I don't see any text establishing requirements on the STL and the
 > token that it exports.  That would seem to be important.

the requirements on the STL, agreed. WRT "token that it exports" -- are you 
referring to keying material exported from the underlying STL, for which 
there's cryptographic and behavioral requirements (eg as expressed in 
RFC5705) ? if so, agreed.

eg, when the quic folk write their I-D equivalent to 
draft-ietf-tokbind-https, it will likely need to document the use of quic's 
keying material exporter function (the latter which will itself need to be 
documented a la RFC5705)

Note also that given the crypto direction TLS 1.3 is headed (deprecation of 
the PRF() function), and its not-yet-fleshed-out keying material exporter, 
that RFC5705 arguably does not apply to TLS 1.3, and thus TLS 1.3 will need 
to be treated as yet another STL from the Token Binding Protocol 
perspective, it seems to me at this point.

HTH,

=JeffH

 > On 21 February 2016 at 11:41, =JeffH <[email-masked]> wrote:
 >> I scrawled back on Wed, 27 Jan 2016:
 >>> on Fri, 18 Sep 2015 19:05:30 +0000 Andrei Popov
 >>> <[email-masked]> wrote:
 >>>
 >>> > QUIC's use of TB will require a separate specification with their own
 >>> > TB parameters negotiation mechanism, and their own binding method
 >>> > (analogous to EKM for TLS).
 >>>
 >>> ISTM at this time that draft-ietf-tokbind-protocol-04 needs a bit of work
 >>> in order to make it truly agnostic wrt the underlying transport protocol
 >>> (i.e., TLS or QUIC or whatever).
 >>
 >>
 >> see: https://github.com/TokenBinding/Internet-Drafts/pull/15
 >>
 >> In the spirit of supporting "security protocols other than TLS and
 >> application protocols other than HTTP", as Andrei noted here..
 >>
 >> Re: [Unbearable] Should Token Binding support non-TLS applications?
 >> https://www.ietf.org/mail-archive/web/unbearable/current/msg00287.html
 >>
 >> ..I've drafted what seem to be the minimal changes to
 >> draft-ietf-tokbind-protocol-04 in order to make the TB protocol itself
 >> agnostic to the secure transport layer underlying the application layer, and
 >> to generalize from HTTP.
 >>
 >> Note that the admonitions wrt TLS 1.2 (and earlier) Triple Handshake vuln
 >> and remediations thereof, noted in sections 4 and 8.5, are removed entirely.
 >> This is for two reasons: (1) this is TLS-specific, and (2) is already
 >> addressed draft-ietf-tokbind-negotiation.
 >>
 >> Other than that, and updating the spec's title, the changes are fairly
 >> minor.
 >>
 >> However, still to be done:
 >>
 >> 1. Move the TLS-specific keying material exporting language to
 >> draft-ietf-tokbind-negotiation.
 >> 2. further surgery needed to fully generalize from HTTP-specific app layer
 >> assumptions.
 >> 3. I have further detailed feedback on draft-ietf-tokbind-protocol-04 still
 >> to post (coming soon)
 >>
 >> visual side-by-side diff available here:
 >> 
http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html

---

From: Nick Harper <[email-masked]>
Date: Mon, 22 Feb 2016 16:33:28 -0800

QUIC crypto is destined to die (and be replaced by TLS 1.3), so I wouldn't
worry about making spec changes to accommodate QUIC specifically. However,
I agree with Jeff about TLS 1.3 needing to be treated differently from the
Token Binding Protocol perspective because of the difference in keying
material exporters.

On Mon, Feb 22, 2016 at 11:08 AM, =JeffH <[email-masked]>
wrote:

> <
> https://mailarchive.ietf.org/arch/msg/unbearable/thqNHlHciMBBijVdVV07Kbs8ohs
> >
>
> ..and the encompassing thread, given that Andrei was supportive and that
> the QUIC tokenbinding impl is ensconced in QUIC code..
>
> <https://code.google.com/p/chromium/codesearch#search/&q=tokenbind%20file
> :^src/net/quic/&sq=package:chromium&type=cs>
>
> <
> https://docs.google.com/document/d/12eKfkdC7g5IGUCtghzg7Wi__qiEkY65fX09n8sjLtHg
> >
>
> I note that the wg charter does not explicitly indicate that the TB
> Protocol will be applicable to only TLS, but also does not explicitly state
> the requirements on the STL, agreed. WRT "token that it exports" -- are
> you referring to keying material exported from the underlying STL, for
> which there's cryptographic and behavioral requirements (eg as expressed in
> Note also that given the crypto direction TLS 1.3 is headed (deprecation
> of the PRF() function), and its not-yet-fleshed-out keying material
> exporter, that RFC5705 arguably does not apply to TLS 1.3, and thus TLS 1.3
> will need to be treated as yet another STL from the Token Binding Protocol
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Feb 2016 01:06:45 +0000

Thanks Jeff for reviewing the documents and providing the pull request. I am not opposed to the overall goal of this PR.

If the WG decides to pursue this type of change, I think we would either need a new I-D that will contain TLS-specific information (primarily parameters for the key exporters and TLS-specific security considerations), or draft-ietf-tokbind-negotiation would need to be expanded and transformed into draft-ietf-tokbind-tls.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Monday, February 22, 2016 4:33 PM
To: =JeffH <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

QUIC crypto is destined to die (and be replaced by TLS 1.3), so I wouldn't worry about making spec changes to accommodate QUIC specifically. However, I agree with Jeff about TLS 1.3 needing to be treated differently from the Token Binding Protocol perspective because of the difference in keying material exporters.

> have a different STL created that does not meet the basic

well, my goal, nominially as an exercise, is to generalize the spec for non-TLS underlying STL(s) as noted in..

<https://mailarchive.ietf.org/arch/msg/unbearable/thqNHlHciMBBijVdVV07Kbs8ohs<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailarchive.ietf.org%2farch%2fmsg%2funbearable%2fthqNHlHciMBBijVdVV07Kbs8ohs&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c819ef587837c4948485608d33be90285%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=lAcZW3a7Ak2iRN9uP3oVFkBF363be3frKbNmkl8AY3k%3d>>

..and the encompassing thread, given that Andrei was supportive and that the QUIC tokenbinding impl is ensconced in QUIC code..

<https://code.google.com/p/chromium/codesearch#search/&q=tokenbind%20file<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcode.google.com%2fp%2fchromium%2fcodesearch%23search%2f%26q%3dtokenbind%2520file&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c819ef587837c4948485608d33be90285%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8Xdsxk%2bY0V0rGHeIxrPmfjdAnP45wk2GddRzg8PD5iQ%3d>:^src/net/quic/&sq=package:chromium&type=cs>

Token Binding over QUIC
<https://docs.google.com/document/d/12eKfkdC7g5IGUCtghzg7Wi__qiEkY65fX09n8sjLtHg<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google.com%2fdocument%2fd%2f12eKfkdC7g5IGUCtghzg7Wi__qiEkY65fX09n8sjLtHg&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c819ef587837c4948485608d33be90285%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MWxs4L6NcAD4cjvYa1JMTxBL6nz%2b3c31gt%2fSxlunREY%3d>>

Of course, the working group and the spec editors need to formally decide whether this is a direction they in fact wish to head.

I note that the wg charter does not explicitly indicate that the TB Protocol will be applicable to only TLS, but also does not explicitly state generalization for other underlying STLs (secure transport layers). The charter does, however, wrt app layer protocols state (fwiw)..

"Make the Token Binding protocol useable in combination with a variety of application protocols"

> token that it exports.  That would seem to be important.

the requirements on the STL, agreed. WRT "token that it exports" -- are you referring to keying material exported from the underlying STL, for which there's cryptographic and behavioral requirements (eg as expressed in RFC5705) ? if so, agreed.

eg, when the quic folk write their I-D equivalent to draft-ietf-tokbind-https, it will likely need to document the use of quic's keying material exporter function (the latter which will itself need to be documented a la RFC5705)

Note also that given the crypto direction TLS 1.3 is headed (deprecation of the PRF() function), and its not-yet-fleshed-out keying material exporter, that RFC5705 arguably does not apply to TLS 1.3, and thus TLS 1.3 will need to be treated as yet another STL from the Token Binding Protocol perspective, it seems to me at this point.

HTH,

=JeffH

> On 21 February 2016 at 11:41, =JeffH <[email-masked]<mailto:[email-masked]>> wrote:
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>> https://www.ietf.org/mail-archive/web/unbearable/current/msg00287.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2funbearable%2fcurrent%2fmsg00287.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c819ef587837c4948485608d33be90285%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HMLPjlbgkO2zijowu5JR2qG2%2fRcyyqfJoP8ibi8eaVg%3d>
>>
>> http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fkingsmountain.com%2fdoc%2fdiff%2fDiff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04b.txt.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c819ef587837c4948485608d33be90285%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00LwujOPEufxX70ryFIlC0oE1NaXZCrnsrmSgnSIxhk%3d>
>>
_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c819ef587837c4948485608d33be90285%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ve0LRRlfKb9a90DJYxTP7UUR%2fE5ZwqapcKMm56K7Y0A%3d>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 23 Feb 2016 16:32:03 +0100

On 2016-02-23 02:06, Andrei Popov wrote:
> Thanks Jeff for reviewing the documents and providing the pull request.
> I am not opposed to the overall goal of this PR.
> 
>  
> 
> If the WG decides to pursue this type of change, I think we would either
> need a new I-D that will contain TLS-specific information (primarily
> parameters for the key exporters and TLS-specific security
> considerations), or draft-ietf-tokbind-negotiation would need to be
> expanded and transformed into draft-ietf-tokbind-tls.
> 

this does represent a major change (not measuring by words but by scope)
and there has to be pretty strong consensus from the WG to
take this on.

	Cheers Leif

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 09:50:16 -0800

> and there has to be pretty strong consensus from the WG to

I don't think that this is a good idea.  If there is a need for this
capability in other places, then we can discuss that need.  Given that
QUIC is basically HTTP and will eventually use TLS, the problem will
solve itself there, so that leaves us generalizing something without a
customer for that generalization.

I've noted a couple of concerns with the approach in the PR.  I'm not
confident that those are the only problems we'd have to solve.
Avoiding an abstraction layer at this point avoids having to do all
that work and completely avoids the risk that we mess it up.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Feb 2016 18:21:46 +0000

> this does represent a major change (not measuring by words but by 
> scope) and there has to be pretty strong consensus from the WG to take 
> this on.

Yes, let the WG decide. At this time, I don't feel strongly either way.

> Avoiding an abstraction layer at this point avoids having to do all that work and completely avoids the risk that we mess it up.

I think that publishing TBPROTO and TBNEGO in their current form would not preclude future documents describing the use of the Token Binding protocol with e.g. Kerberos or DTLS. And Martin's point about delaying the generalization until we have a few adaptations to various STLs makes sense to me. 

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, February 23, 2016 9:50 AM
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

On 23 February 2016 at 07:32, Leif Johansson <[email-masked]> wrote:
> this does represent a major change (not measuring by words but by 
> scope) and there has to be pretty strong consensus from the WG to take 
> this on.

I don't think that this is a good idea.  If there is a need for this capability in other places, then we can discuss that need.  Given that QUIC is basically HTTP and will eventually use TLS, the problem will solve itself there, so that leaves us generalizing something without a customer for that generalization.

I've noted a couple of concerns with the approach in the PR.  I'm not confident that those are the only problems we'd have to solve.
Avoiding an abstraction layer at this point avoids having to do all that work and completely avoids the risk that we mess it up.