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

[Andrei Popov <[e-mail]>]

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 <[e-mail]> 
Sent: Wednesday, May 9, 2018 6:21 PM
To: Alexey Melnikov <[e-mail]>
Cc: Andrei Popov <[e-mail]>; The IESG <[e-mail]>; John Bradley <[e-mail]>; [e-mail]; IETF Tokbind WG <[e-mail]>; [e-mail]
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 <[e-mail]>
wrote:

> Hi Andrei,

> On Mon, May 7, 2018, at 8:06 PM, Andrei Popov wrote:
> > 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.

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

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

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

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

> Yes, this sounds good.

> Best Regards,
> Alexey

> > Cheers,
> >
> > Andrei
> >
> > -----Original Message-----
> > From: Alexey Melnikov <[e-mail]>
> > Sent: Sunday, May 6, 2018 8:31 AM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; John Bradley 
> > <[e-mail]>; [e-mail]; [e-mail]; 
> > [e-mail]
> > Subject: Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12:
> > (with DISCUSS and COMMENT)
> >
> > 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://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
> >
> >
> >
> > --------------------------------------------------------------------
> > --
> > 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.
> >
> >

> _______________________________________________
> Unbearable mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> 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