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

[Alexey Melnikov <[e-mail]>]

On Thu, May 10, 2018, at 3:03 AM, Martin Thomson wrote:
> 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.

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.

> 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 <[e-mail]>
> wrote:
> 
> > 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