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 <aamelnikov@fastmail.fm>
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 <aamelnikov@fastmail.fm>
> > Sent: Sunday, May 6, 2018 8:31 AM
> > To: The IESG <iesg@ietf.org>
> > Cc: draft-ietf-tokbind-negotiation@ietf.org; John Bradley
> > <ve7jtb@ve7jtb.com>; tokbind-chairs@ietf.org; ve7jtb@ve7jtb.com;
> > unbearable@ietf.org
> > 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
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable