Subject: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 09 May 2018 13:05:48 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tokbind-negotiation-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document. I am balloting "yes", but have a few comments:

- I support Alexey's DISCUSS. Additionally, do I understand the version
negotiation to require the client to support all previous version from the one
it initially advertises? If so, how would you deprecate a version at some time
in the future?

- I shared some of the confusion about this being limited to TLS 1.2 and
earlier. In particular, there is repeating language that to the effect of "For
TLS 1.2 and earlier...", which seems strange for a draft that only supports 1.2
in the first place.

§1.1: Please consider using the 8174 boilerplate across the cluster. While I
did not find lower case keywords in this draft, I did in the other two and it
would be best to be consistent across all three.

§2: "[I-D.ietf-tokbind-protocol] describes version {1, 0} of the protocol.":
While one might infer that version to be {1,0} give the name "Token Binding
1.0", I never saw it explicitly mentioned.

Editorial Comments:

§2: "Please note that the server MAY select any lower protocol version, see
Section 3": comma splice

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 May 2018 14:05:00 -0700

> https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/

You can't do it in the CH. The assumption is that the server will pick the
highest
common version in the SH and if you don't support that, you abort.

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 May 2018 21:50:34 +0000

Hi Ben,

Thanks for the review; some answers below.
> Additionally, do I understand the version negotiation to require the client to support all previous version from the one it initially advertises?
No, the draft says specifically:
" There is no requirement for the client to support any Token
   Binding versions other than the one advertised in the client's
   "token_binding" extension."

> §1.1: Please consider using the 8174 boilerplate across the cluster. While I did not find lower case keywords in this draft, I did in the other two and it would be best to be consistent across all three.
Will make this change in the next revision.

> While one might infer that version to be {1,0} give the name "Token Binding 1.0", I never saw it explicitly mentioned.
Sorry, I did not understand the concern. Can you elaborate?

Thanks,

Andrei

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: Wednesday, May 9, 2018 1:06 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; John Bradley <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C3a1591db5ceb4c9f9e3508d5b5e842b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636614931539696277&sdata=tz5MtEsJwqlG7QHQWgLVy6HMgX1xyLTqzmnFA7U9Gmc%3D&reserved=0
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-negotiation%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C3a1591db5ceb4c9f9e3508d5b5e842b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636614931539696277&sdata=JMexEpyWjrBwY5V2PvFVHCqaXtPlw7PaBRJK4Qk%2F5lc%3D&reserved=0

- I support Alexey's DISCUSS. Additionally, do I understand the version negotiation to require the client to support all previous version from the one it initially advertises? If so, how would you deprecate a version at some time in the future?

- I shared some of the confusion about this being limited to TLS 1.2 and earlier. In particular, there is repeating language that to the effect of "For TLS 1.2 and earlier...", which seems strange for a draft that only supports 1.2 in the first place.

§1.1: Please consider using the 8174 boilerplate across the cluster. While I did not find lower case keywords in this draft, I did in the other two and it would be best to be consistent across all three.

§2: "[I-D.ietf-tokbind-protocol] describes version {1, 0} of the protocol.":
While one might infer that version to be {1,0} give the name "Token Binding 1.0", I never saw it explicitly mentioned.

Editorial Comments:

§2: "Please note that the server MAY select any lower protocol version, see Section 3": comma splice

---

From: Ben Campbell <[email-masked]>
Date: Wed, 9 May 2018 23:40:05 -0500

> On May 9, 2018, at 4:05 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> You can't do it in the CH. The assumption is that the server will pick the highest

Just to make sure I understand: If the client selects version N (ignoring the (major, minor) format for a minute) , the server might respond with N-1. If the client doesn’t like N-1, it aborts and optionally tries again with the highest version it supports that is lower than N-1? Or should it just give up on TB?

Thanks,

Ben.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 10 May 2018 05:21:16 +0000

> Just to make sure I understand: If the client selects version N (ignoring the (major, minor) format for a minute) , the server might respond with N-1. If the client doesn’t like N-1, it aborts and…

Nothing in the document prevents the client from re-trying in this fashion, but the prototype clients I've seen (Web browsers) proceed without TB in this situation.

Here's what the spec says about handling TB negotiation failures:
   "Client and server applications can choose to handle failure to
   negotiate Token Binding in a variety of ways, e.g.: continue using
   the connection as usual, shorten the lifetime of tokens issued during
   this connection, require stronger authentication, terminate the
   connection, etc."

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: Wednesday, May 9, 2018 9:40 PM
To: Eric Rescorla <[email-masked]>
Cc: The IESG <[email-masked]>; John Bradley <[email-masked]>; [email-masked]; IETF Tokbind WG <[email-masked]>; [email-masked]
Subject: Re: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> - I support Alexey's DISCUSS. Additionally, do I understand the 
> version negotiation to require the client to support all previous 
> version from the one it initially advertises? If so, how would you 
> deprecate a version at some time in the future?
> 
> You can't do it in the CH. The assumption is that the server will pick 
> the highest common version in the SH and if you don't support that, you abort.

Thanks,

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 May 2018 17:23:24 -0500

> On May 10, 2018, at 12:21 AM, Andrei Popov <[email-masked]> wrote:
> 
>   connection, etc.”

I note that text does _not_ include “retry the negotiation with a different version number”. I guess if you plan to do that, you haven’t actually failed yet?

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 May 2018 17:26:18 -0500

> On May 9, 2018, at 4:50 PM, Andrei Popov <[email-masked]> wrote:
> 
> Hi Ben,
> 
>   "token_binding" extension.”
> 

We have a separate thread on this point now, so I will respond there.

> Will make this change in the next revision.

Thanks!

> Sorry, I did not understand the concern. Can you elaborate?

Ths probably should have been a comment on the protocol draft, not the negotiation draft. That is, the protocol draft never explicitly claims to be {1,0}. But it’s not a big deal because I think most implementers would infer that from the title “Token Binding 1.0"

---

From: Andrei Popov <[email-masked]>
Date: Thu, 10 May 2018 22:33:18 +0000

Yep, both boilerplate and {1,0} are addressed in the latest uploaded TBPROTO and TBNEGO.

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: Thursday, May 10, 2018 3:26 PM
To: Andrei Popov <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; John Bradley <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

Thanks!