Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-00.txt

From: [email-masked]
Date: Fri, 11 Sep 2015 05:56:54 -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           : Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
        Authors         : Andrei Popov
                          Magnus Nyström
                          Dirk Balfanz
                          Adam Langley
	Filename        : draft-ietf-tokbind-negotiation-00.txt
	Pages           : 8
	Date            : 2015-09-10

Abstract:
   This document specifies a Transport Layer Security (TLS) [RFC5246]
   extension for the negotiation of Token Binding protocol
   [I-D.ietf-tokbind-protocol] version and key parameters.

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

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

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: Fri, 11 Sep 2015 17:50:38 +0000

As discussed in Prague, I've posted the TBNEGO I-D as a Tokbind WG item.

The new version incorporates the following changes and fixes resulting from review comments and implementation experience:
1. The TLS extension is now negotiated per-connection, so that implementers don't have to add new info to TLS session cache items and tickets.
2. 2-byte key_parameters_list length did not make sense; reduced to 1 byte.
3. TB version indication is replaced with a simple TLS-style version negotiation. The client offers the highest version it supports, the server responds with the lower of client-advertised and server-supported versions. The client then either uses the server-selected TB version, or proceeds without TB. The goal of this is to allow clients and servers to support multiple TB versions at the same time, for compatibility with legacy SW.
4. Other minor changes (updated links, fixed typos, etc.)

I'm also planning to submit the updated TBPROTO spec early next week.

Please review and comment,

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 11, 2015 5:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-00.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: Fri, 11 Sep 2015 16:13:29 -0700

One more clarification (not really a change in functionality) might be in
order:

If the user has an existing TB key pair for a channel, it really should
list this first in it's preferences.  Otherwise, the server is likely to
switch to the key type the client advertised as most preferable,
invalidating all the bound tokens on that channel.  I think with that
understanding, it is fine to have the server respond with exactly one key
type.  It should only pick a key type other than the client's preferred key
type if it feels that it is worth invalidating the client's bound tokens,
and force the client to generate a new key pair.

Thanks,
Bill

On Fri, Sep 11, 2015 at 10:50 AM, Andrei Popov <[email-masked]>
wrote:

> The new version incorporates the following changes and fixes resulting
> from review comments and implementation experience:
> 1. The TLS extension is now negotiated per-connection, so that
> implementers don't have to add new info to TLS session cache items and
> tickets.
> 3. TB version indication is replaced with a simple TLS-style version
> negotiation. The client offers the highest version it supports, the server
> responds with the lower of client-advertised and server-supported versions.
> The client then either uses the server-selected TB version, or proceeds
> without TB. The goal of this is to allow clients and servers to support
> multiple TB versions at the same time, for compatibility with legacy SW.
> 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: Sat, 12 Sep 2015 00:00:56 +0000

One can implement this type of logic in the client and server, but I would not recommend it in general.

It would be my preference to have servers pick the “best” algorithm they have in common with the client. If the server’s definition of “best” changes after a while, and the user needs to re-authenticate (using a convenient and secure method, of course☺), then so be it. Realistically, I don’t expect frequent changes of TB algorithm preferences.

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Friday, September 11, 2015 4:13 PM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-00.txt

One more clarification (not really a change in functionality) might be in order:

If the user has an existing TB key pair for a channel, it really should list this first in it's preferences.  Otherwise, the server is likely to switch to the key type the client advertised as most preferable, invalidating all the bound tokens on that channel.  I think with that understanding, it is fine to have the server respond with exactly one key type.  It should only pick a key type other than the client's preferred key type if it feels that it is worth invalidating the client's bound tokens, and force the client to generate a new key pair.

Thanks,
Bill

On Fri, Sep 11, 2015 at 10:50 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
As discussed in Prague, I've posted the TBNEGO I-D as a Tokbind WG item.

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, September 11, 2015 5:57 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-00.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