Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-02.txt

From: [email-masked]
Date: Mon, 14 Sep 2015 14:22:46 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Token Binding Working Group of the IETF.

        Title           : The Token Binding Protocol Version 1.0
        Authors         : Andrei Popov
                          Magnus Nyström
                          Dirk Balfanz
                          Adam Langley
	Filename        : draft-ietf-tokbind-protocol-02.txt
	Pages           : 12
	Date            : 2015-09-14

Abstract:
   This document specifies Version 1.0 of the Token Binding protocol.
   The Token Binding protocol allows client/server applications to
   create long-lived, uniquely identifiable TLS [RFC5246] bindings
   spanning multiple TLS sessions and connections.  Applications are
   then enabled to cryptographically bind security tokens to the TLS
   layer, preventing token export and replay attacks.  To protect
   privacy, the TLS Token Binding identifiers are only transmitted
   encrypted and can be reset by the user at any time.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andrei Popov <[email-masked]>
Date: Mon, 14 Sep 2015 21:35:14 +0000

This is the updated version of the TBPROTO I-D. Major changes include:
1. A switch from TLS-UNIQUE to Exported Keying Material, as discussed on the mailing list;
2. Instead of the SignatureAndHashAlgorithm structure, the Token Binding ID now uses 1-byte TokenBindingKeyParameters from TBNEGO (per discussion in Prague);
3. Added text describing a possible use of TB extensions (per discussion in Prague);
4. New text talking about “in private” browsing in the Security Considerations section.

Please review and comment,

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 14, 2015 2:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-02.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Bill Cox <[email-masked]>
Date: Wed, 16 Sep 2015 09:08:40 -0700

I'm just now implementing a parser for TokenBindingMessage.  I see that
we've switched to using the say key parameter type as in the TLS
negotiation.  That's excellent.  Doesn't this mean we can get rid of the
NamedCurve field?  Aren't all the key parameters such as the curve name
implied by the key_parameters field?  If not, I have an error in my code :)

Bill

On Mon, Sep 14, 2015 at 2:35 PM, Andrei Popov <[email-masked]>
wrote:

> 2. Instead of the SignatureAndHashAlgorithm structure, the Token Binding
> ID now uses 1-byte TokenBindingKeyParameters from TBNEGO (per discussion in
> Prague);
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 16 Sep 2015 18:02:52 +0000

In principle we could; NamedCurve is part of the ECDSAParams TLS struct that we’re reusing. Instead, we could probably do something like this:
case ecdsap256_sha256:
    ECPoint point;

We could also drop “_sha256” suffixes from TokenBindingKeyParameters, because we’re no longer hashing TLS-UNIQUEs (but this would not require a code change).

I’m planning to collect more comments and then update the spec once more, in time for Yokohama.

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, September 16, 2015 9:09 AM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-02.txt

I'm just now implementing a parser for TokenBindingMessage.  I see that we've switched to using the say key parameter type as in the TLS negotiation.  That's excellent.  Doesn't this mean we can get rid of the NamedCurve field?  Aren't all the key parameters such as the curve name implied by the key_parameters field?  If not, I have an error in my code :)

Bill

On Mon, Sep 14, 2015 at 2:35 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, September 14, 2015 2:23 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-02.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: Bill Cox <[email-masked]>
Date: Thu, 17 Sep 2015 09:31:56 -0700

On Wed, Sep 16, 2015 at 11:02 AM, Andrei Popov <[email-masked]>
wrote:

> We could also drop “_sha256” suffixes from TokenBindingKeyParameters,
> because we’re no longer hashing TLS-UNIQUEs (but this would not require a
> code change).
>

Ha, I just started writing an email to suggest this when I saw your reply.
Using the key exported simplifies the code a bit, which is nice, and it
already does SHA256 for us.   There's nowhere in my code that I use the
hash algorithm field for verifying signatures.  I would prefer that we
either:

1) Require a further hash using the specified algorithm, to provide some
hash algorithm agility
2) Go with SHA256, as it's baked into the key exporter without any agility.

I would prefer option 2, but if we want hash algorithm agility, we lose it
with the key exporter, and have to do an additional hash.  The only option
I want to avoid is sending the hash algorithm over the wire if we are going
to ignore it, which is what I do now.

Thanks for all the work on this!

Bill