Subject: [Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Sun, 06 May 2018 08:30:37 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-tokbind-negotiation-12: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I will be switching to "Yes" once one issue mentioned below is discussed:

I would like to have a quick discussion about your versionning model:

   struct {
       uint8 major;
       uint8 minor;
   } TB_ProtocolVersion;

What is the significance of "major" and "minor" versions?
Any rules on what kind of changed would require increment of the "major"
version. Any restrictions on what must remain the same when the "major" (or
"minor") version gets incremented? Any requirements on backward compatibility
when only the "minor" version is incremented?

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

In Section 2:

   "key_parameters_list" contains the list of identifiers of the Token
   Binding key parameters supported by the client, in descending order
   of preference.  [I-D.ietf-tokbind-protocol] defines an initial set of
   identifiers for Token Binding key parameters.

Wouldn't be better to point to the IANA registry established by [I-D.ietf-tokbind-protocol]?
My concern is that you might be misleading implementors into not looking there.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 7 May 2018 19:06:46 +0000

Hi Alexey,

Thanks for reviewing the specs, I appreciate your comments.

> What is the significance of "major" and "minor" versions?
There is no normative significance; the version value is split into two parts for convenience of discussion only, so that we can talk about versions such as 0.10, 0.13, 1.0, etc.

> Any rules on what kind of changed would require increment of the "major" version.
> Any restrictions on what must remain the same when the "major" (or "minor") version gets incremented?
We have no such rules; it is common to increment the "major" protocol version when "significant" changes happen, but this is up to future protocol specs to define.

> Any requirements on backward compatibility when only the "minor" version is incremented?
There is no backward compatibility between different Token Binding protocol versions, regardless of which component of TB_ProtocolVersion changes.

> Wouldn't be better to point to the IANA registry established by [I-D.ietf-tokbind-protocol]?
Indeed, it may be better to say something like "[I-D.ietf-tokbind-protocol] establishes an IANA registry for Token Binding key parameters" or something to this effect.
I'll try to wordsmith this.

Cheers,

Andrei

-----Original Message-----
From: Alexey Melnikov <[email-masked]> 
Sent: Sunday, May 6, 2018 8:31 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; John Bradley <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and 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%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=LDU%2F%2FEr7lCYt0gm0yExDVINW1DGJh5S5cJJRv%2FRULQY%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%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=ka1kQLpRehbQmXHtxHj73cqfGsRw1Axvk%2BS%2BjkbOatQ%3D&reserved=0

   struct {
       uint8 major;
       uint8 minor;
   } TB_ProtocolVersion;

What is the significance of "major" and "minor" versions?
Any rules on what kind of changed would require increment of the "major"
version. Any restrictions on what must remain the same when the "major" (or
"minor") version gets incremented? Any requirements on backward compatibility when only the "minor" version is incremented?

In Section 2:

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 May 2018 16:18:04 +0100

Hi Andrei,

On Mon, May 7, 2018, at 8:06 PM, Andrei Popov wrote:
> There is no normative significance; the version value is split into two 
> parts for convenience of discussion only, so that we can talk about 
> versions such as 0.10, 0.13, 1.0, etc.

I am tempted to suggest that you should replace it with a single unsigned 16bit, as "major" doesn't mean anything

> We have no such rules; it is common to increment the "major" protocol 
> version when "significant" changes happen, but this is up to future 
> protocol specs to define.

I urge the WG to think about extensibility now, as opposed to deciding later. Both TLS and HTTP specifications put much more thoughts into versionning.

If you don't need generic extensibility (you already have ability to support different private key types), then maybe you don't need the version field at all. You can just get a new TLS extension number if you need some incompatible changes. (Or to ask it in another way: do you just have the version number field to work around strict TLS extension code point allocation rules?)

> There is no backward compatibility between different Token Binding 
> protocol versions, regardless of which component of TB_ProtocolVersion 
> changes.
> 
> Indeed, it may be better to say something like "[I-D.ietf-tokbind-
> protocol] establishes an IANA registry for Token Binding key parameters" 
> or something to this effect.

Yes, this sounds good.

Best Regards,
Alexey

> Cc: [email-masked]; John Bradley 
> <[email-masked]>; [email-masked]; [email-masked]; 
> [email-masked]
> 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%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=LDU%2F%2FEr7lCYt0gm0yExDVINW1DGJh5S5cJJRv%2FRULQY%3D&reserved=0
> "minor") version gets incremented? Any requirements on backward 
> compatibility when only the "minor" version is incremented?
> 
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 May 2018 18:19:01 +0000

Hi Alexey,

> I urge the WG to think about extensibility now, as opposed to deciding later. Both TLS and HTTP specifications put much more thoughts into versionning.
The Token Binding protocol is extensible in multiple ways:
1. New algorithms can be introduced by defining new TB key parameters;
2. TB protocol supports extensions;
3. TB protocol has a version negotiation mechanism.

> If you don't need generic extensibility (you already have ability to support different private key types), then maybe you don't need the version field at all.
> You can just get a new TLS extension number if you need some incompatible changes.
Both of these options were discussed at length in the WG, over the years, and rejected in favor of the current version negotiation mechanism.
IMHO it would be unfortunate to renegotiate WG consensus at this point in the process.

Thanks,

Andrei

-----Original Message-----
From: Alexey Melnikov <[email-masked]> 
Sent: Wednesday, May 9, 2018 8:18 AM
To: Andrei Popov <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

Hi Andrei,

On Mon, May 7, 2018, at 8:06 PM, Andrei Popov wrote:
> There is no normative significance; the version value is split into 
> two parts for convenience of discussion only, so that we can talk 
> about versions such as 0.10, 0.13, 1.0, etc.

Yes, this sounds good.

Best Regards,
Alexey

> 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.i
> etf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndr
> ei.Popov%40microsoft.com%7C59e09351f0fe4b2fb9ac08d5b366524f%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=LDU%2F%2FE
> r7lCYt0gm0yExDVINW1DGJh5S5cJJRv%2FRULQY%3D&reserved=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-negotiation%2F&data=02%7C01
> %7CAndrei.Popov%40microsoft.com%7C59e09351f0fe4b2fb9ac08d5b366524f%7C7
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636612174409112174&sdata=ka1
> kQLpRehbQmXHtxHj73cqfGsRw1Axvk%2BS%2BjkbOatQ%3D&reserved=0
> 
> 
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 May 2018 19:50:50 +0000

> I am tempted to suggest that you should replace it with a single unsigned 16bit, as "major" doesn't mean anything

The two fields are there to facilitate the human convention of having software version numbers have two parts, for example TLS 1.2 and TLS 1.3.  I suppose that explanatory text could be added saying that the two fields are there to align with this human convention for representing version numbers, whereas for machine comparison purposes, the concatenation of the two binary fields represents the version.  Would you be happier with explanatory text along those lines?

FYI, I believe the plan is for the version number of the approved RFC to be 1.0 - that is, a 1 in the major field and a zero in the minor field.  This is pretty normal stuff.

				-- Mike

-----Original Message-----
From: Unbearable <[email-masked]> On Behalf Of Andrei Popov
Sent: Wednesday, May 9, 2018 11:19 AM
To: Alexey Melnikov <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

Hi Alexey,

The Token Binding protocol is extensible in multiple ways:
1. New algorithms can be introduced by defining new TB key parameters; 2. TB protocol supports extensions; 3. TB protocol has a version negotiation mechanism.

Thanks,

Andrei

-----Original Message-----
From: Alexey Melnikov <[email-masked]>
Sent: Wednesday, May 9, 2018 8:18 AM
To: Andrei Popov <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

Hi Andrei,

Yes, this sounds good.

Best Regards,
Alexey

> kQLpRehbQmXHtxHj73cqfGsRw1Axvk%2BS%2BjkbOatQ%3D&reserved=0
_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 May 2018 18:00:27 -0500

FWIW,

On Wed, May 9, 2018 at 1:19 PM, Andrei Popov <[email-masked]>
wrote:

> Hi Alexey,
>
> > I urge the WG to think about extensibility now, as opposed to deciding
> later. Both TLS and HTTP specifications put much more thoughts into
> versionning.
> > If you don't need generic extensibility (you already have ability to
> support different private key types), then maybe you don't need the version
> field at all.
> Both of these options were discussed at length in the WG, over the years,
> and rejected in favor of the current version negotiation mechanism.

This isn't my Discuss, but I'm responsible for a working group that has
spent a lot of time and electrons defining exactly what major numbers,
minor numbers, and extensions are, and how you know you need to increment
each one of them.

If you folks think you all understand and agree on the details, awesome,
but if you're not sure that's true, this is a great time to figure that
out.

(And I'm a No Objection in any case, so do the right thing)

Spencer (who is thinking of https://datatracker.ietf.org/doc/rfc8178/, for
what THAT'S worth)

> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> I urge the WG to think about extensibility now, as opposed to deciding
> later. Both TLS and HTTP specifications put much more thoughts into
> versionning.
>
> If you don't need generic extensibility (you already have ability to
> support different private key types), then maybe you don't need the version
> field at all. You can just get a new TLS extension number if you need some
> incompatible changes. (Or to ask it in another way: do you just have the
> version number field to work around strict TLS extension code point
> allocation rules?)
>
> > Subject: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12:
>
> > (with DISCUSS and COMMENT)
> >

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 01:20:56 +0000

I had similar questions to Alexey, but - process-wise at least - those were
discussed in the working group.

I was eventually convinced that extensibility might be of some value.  It's
tenuous though.

I remain certain that the TB version negotiation is not just pointless, but
actively hazardous.  I was in the rough there.  But if you have it the
major/minor separation is pointless.  I was either in the rough there, or I
was so far in the rough on the first part that no one wanted to follow me.
On Thu, May 10, 2018 at 1:18 AM Alexey Melnikov <[email-masked]>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 10 May 2018 01:44:32 +0000

Hi Martin,

> But if you have it the major/minor separation is pointless.
It is true that from the implementation standpoint, version is treated simply as a two-octet value.
However, the fact that the specification enumerates the two octets separately in the TB_ProtocolVersion structure does not affect the implementation in any way.

I cannot agree that major/minor version separation is pointless. For humans, it has been convenient to think of pre-standard/experimental TB versions as 0.X versions, and the first standard version 1.0 makes sense to a lot of people. The version representation we use has been intuitive and easy to explain throughout the prototyping process.

I would not be terribly upset if I had to change the definition of TB_ProtocolVersion from struct{uint8, uint8} to unint_16, but this feels like unnecessary spec churn to me.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson <[email-masked]> 
Sent: Wednesday, May 9, 2018 6:21 PM
To: Alexey Melnikov <[email-masked]>
Cc: Andrei Popov <[email-masked]>; The IESG <[email-masked]>; John Bradley <[email-masked]>; [email-masked]; IETF Tokbind WG <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

I had similar questions to Alexey, but - process-wise at least - those were discussed in the working group.

I was eventually convinced that extensibility might be of some value.  It's tenuous though.

I remain certain that the TB version negotiation is not just pointless, but actively hazardous.  I was in the rough there.  But if you have it the major/minor separation is pointless.  I was either in the rough there, or I was so far in the rough on the first part that no one wanted to follow me.
On Thu, May 10, 2018 at 1:18 AM Alexey Melnikov <[email-masked]>

> I am tempted to suggest that you should replace it with a single 
> unsigned
16bit, as "major" doesn't mean anything

> > We have no such rules; it is common to increment the "major" 
> > protocol version when "significant" changes happen, but this is up 
> > to future protocol specs to define.

> I urge the WG to think about extensibility now, as opposed to deciding
later. Both TLS and HTTP specifications put much more thoughts into versionning.

> If you don't need generic extensibility (you already have ability to
support different private key types), then maybe you don't need the version field at all. You can just get a new TLS extension number if you need some incompatible changes. (Or to ask it in another way: do you just have the version number field to work around strict TLS extension code point allocation rules?)

> > protocol versions, regardless of which component of 
> > TB_ProtocolVersion changes.
> >

> > 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
> >

> etf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%
> 40microsoft.com%7C2dcc854d575d47527d3c08d5b6144e3e%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C636615120691755353&sdata=FywmAsC41j8eH1Y3HKQ
> TmBf4wD9wTU0pxkD%2FS5lITAQ%3D&reserved=0

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 02:03:43 +0000

The error would be in misleading people to think that new features can be
added in a compatible way by defining a new minor version, consistent with
the common understanding of the significance of a minor version number.
But changing "minor" versions here is no different to changing major
versions.

I'm surprised that you care what version 1.0 is encoded as on the wire.
  0x3689 would be fine to me.  But now I'm just rehashing the debate we've
already had.  Apologies to the IESG.
On Thu, May 10, 2018 at 11:44 AM Andrei Popov <[email-masked]>

> However, the fact that the specification enumerates the two octets
separately in the TB_ProtocolVersion structure does not affect the
implementation in any way.

> I cannot agree that major/minor version separation is pointless. For
humans, it has been convenient to think of pre-standard/experimental TB
versions as 0.X versions, and the first standard version 1.0 makes sense to
a lot of people. The version representation we use has been intuitive and
easy to explain throughout the prototyping process.

> I would not be terribly upset if I had to change the definition of
TB_ProtocolVersion from struct{uint8, uint8} to unint_16, but this feels
like unnecessary spec churn to me.

> Cc: Andrei Popov <[email-masked]>; The IESG <[email-masked]>;
John Bradley <[email-masked]>; [email-masked];
IETF Tokbind WG <[email-masked]>; [email-masked]
> Subject: Re: [Unbearable] Alexey Melnikov's Discuss on
draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)

> I remain certain that the TB version negotiation is not just pointless,
but actively hazardous.  I was in the rough there.  But if you have it the
major/minor separation is pointless.  I was either in the rough there, or I
was so far in the rough on the first part that no one wanted to follow me.

versionning.

> support different private key types), then maybe you don't need the
version field at all. You can just get a new TLS extension number if you
need some incompatible changes. (Or to ask it in another way: do you just
have the version number field to work around strict TLS extension code
point allocation rules?)

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 May 2018 14:20:16 +0100

> But changing "minor" versions here is no different to changing major

This is exactly what I was getting at.

I do think naming 2 parts of version as "major" and "minor" is misleading, because it doesn't actually mean anything.