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

Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 10 May 2018 13:20 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BADC12D962; Thu, 10 May 2018 06:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=azVWnyN8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f7S/am3e
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2lYlmigzDCB; Thu, 10 May 2018 06:20:17 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4030212D958; Thu, 10 May 2018 06:20:17 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 97B05216F9; Thu, 10 May 2018 09:20:16 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 10 May 2018 09:20:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=s329zESRNmuF/R8D11xb1J7SHAyfx hOfyK9TcdH5ImM=; b=azVWnyN80llQgsfioJWhUw6OqyHKR2QbiEqG/f6Uv+cVw BbmTepERO50eD4rnkPQb7RbGKI7QIuboGHWU7FAxEcj4gzKaX/6hsIEoxu4l61Nh TVorEeM8IxHpHb8L/3zbjiHvz66dwN/8uOC21o2SI5oUIgCq/GJMyfaNilbXUzho R10/v+n8/852HdiVPFIZWZcAU967UisajDJ8NgwBqlfIKCI6UO3kaqVMqmR4M7RD iSf9Xbyg6TMJt3h2+nOym/pI0QO16QVUWxs1S76dmeQ0EdQ+J177nf2XMUGRkt4k 8ikOPIEMG4Y5H+ZAUDnNfHO/vMndQOEqAjdoSXk7Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=s329zE SRNmuF/R8D11xb1J7SHAyfxhOfyK9TcdH5ImM=; b=f7S/am3erTLPqi6hhLpF8u fn2H4w2oII0dRUzTENeJYgmECQBI4a3tNX4db+OTtefFL1zpaaVGZ5tNrr7X6Mr1 MpFCwoqyRXC1DBns20EUZuWt4k0BmTzL0sf5BHTKoUkOZ8QfNj9bLxDroJ/DkSfN RBssmZVSwo2+5FxVXNYFOcw2MyAZnWyR0fw5uYct/ummNLcq4CrUCelSFKdT4LYK YSOL2eGV4efvfRDiy0NvV9QKT5iTFPPteiM9hH6rL/tyd+Da0cPWgwZ7FcC8N2iQ 08c8J/dCQ2DQ7AKlQqUkm+VSz31FR3m63Nfax36O1HVESO4TIJJZXg3oU2kVDRHQ ==
X-ME-Sender: <xms:EEf0WhEh9gacUgOOEAsw57UhOPsEx6c_v9E9St-M9hP8Zylk8ZOotA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6D8529E0B6; Thu, 10 May 2018 09:20:16 -0400 (EDT)
Message-Id: <1525958416.2146188.1367426992.4960AE05@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Martin Thomson <martin.thomson@gmail.com>, Andrei Popov <Andrei.Popov@microsoft.com>
Cc: The IESG <iesg@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, draft-ietf-tokbind-negotiation@ietf.org, IETF Tokbind WG <unbearable@ietf.org>, tokbind-chairs@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42
In-Reply-To: <CABkgnnXv26Kb4qB2Fp8wnzEzkfSDtHTb5n-YLNdJq=dHtaPejw@mail.gmail.com>
References: <152562063795.26840.1916104340550306942.idtracker@ietfa.amsl.com> <DM5PR21MB0507C39C1A09C13C32385F2F8C9B0@DM5PR21MB0507.namprd21.prod.outlook.com> <1525879084.3938368.1366298224.73E1E829@webmail.messagingengine.com> <CABkgnnXrBvfeP6hF7ewd0r5MH+XeiEQ4AteHfR0HrAt=y2DsRA@mail.gmail.com> <DM5PR21MB0507119FF6EB653A6793F95E8C980@DM5PR21MB0507.namprd21.prod.outlook.com> <CABkgnnXv26Kb4qB2Fp8wnzEzkfSDtHTb5n-YLNdJq=dHtaPejw@mail.gmail.com>
Date: Thu, 10 May 2018 14:20:16 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/A2QjqTWwMngEdAQP7VkkNxxGi8c>
Subject: Re: [Unbearable] Alexey Melnikov's Discuss on draft-ietf-tokbind-negotiation-12: (with DISCUSS and COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 13:20:20 -0000

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 <Andrei.Popov@microsoft.com>
> 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 <martin.thomson@gmail.com>
> > Sent: Wednesday, May 9, 2018 6:21 PM
> > To: Alexey Melnikov <aamelnikov@fastmail.fm>
> > Cc: Andrei Popov <Andrei.Popov@microsoft.com>om>; The IESG <iesg@ietf.org>rg>;
> John Bradley <ve7jtb@ve7jtb.com>om>; draft-ietf-tokbind-negotiation@ietf.org;
> IETF Tokbind WG <unbearable@ietf.org>rg>; tokbind-chairs@ietf.org
> > 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 <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>om>; 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://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