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

[Martin Thomson <[e-mail]>]

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