Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Tue, 26 June 2018 21:25 UTC

Return-Path: <ekr@rtfm.com>
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 9DBA3130E3C for <unbearable@ietfa.amsl.com>; Tue, 26 Jun 2018 14:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level:
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 SC4G1UED2_uE for <unbearable@ietfa.amsl.com>; Tue, 26 Jun 2018 14:25:51 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32393130E40 for <unbearable@ietf.org>; Tue, 26 Jun 2018 14:25:48 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id x15-v6so3902823ybm.2 for <unbearable@ietf.org>; Tue, 26 Jun 2018 14:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eZ+shD6W2hfgrBNJlP4V4eT6FLHRwWuCc/WEv1aTZJs=; b=qHSTtOlhWChtzzMcxiL29+X5OPgJoIx5xPZxOL9waTK7Vi0jyh4xstPJgpYoQjwvmT bOfF+QjrLyk+7LWfWco4qdZNYZAsl2wfgvoYSRB3xIZ4oS65yoDpuQdRsoorVVUqCP8O KeA/fWyAML8G7Jo/J8PQSQookGjgdV7MnVbO9/M918cuzywl+ny4qmcyDFAmZHIXtrjs WGi2WodRugr3KeSo3N+4PPfzOjQoSbBMzFnex16RfIOL/e+8HT48GobL6UuZOtb0+6uN Lkb3zUdCEjVLJEGnVhGOWVqJGqcjrtM9zUYx/h+U6vqqw5clo6Q3XRrzymPShBdgEtFf 6goA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eZ+shD6W2hfgrBNJlP4V4eT6FLHRwWuCc/WEv1aTZJs=; b=rrSKrkgP2GieSJmyVH8BhUDyF+B0ss8k4pDp0m9i/mP0mtINE8Sr9U7ET343GnFbj8 Za2L4nBWHegKxe7/xt+lycEWbtdBYqvdJCvNXiLjxn0Wskrm+0jfN3oyRU6c+la7RyJu ChbQj+FgpPEhN6Z38/wMaQUwdDj+isNjsSX9wWM00oxrSlhHEVAAb6K60JhSXhPd7LzS 5SKsR4xyZCnSQqQwNf7oX0vm6eU8qLUefIFMobKVAspIR9+oBI/hObNb40Pc8Tzw/8kN zlcahPEm6InZ59zhZvryL/LjPw6WryuJqEIrr33z7vjUFYAPeDmNh8LTMWG52vcHPGFj CV/Q==
X-Gm-Message-State: APt69E2DlSF37VWs4ZHBRfjDiwQfhjhnoMOQZB5VMa5H2IZNKoxfnmtb BXQqCvMozM9dKHO+sDde3cN1liHEBgb+y8W5HBbTCA==
X-Google-Smtp-Source: ADUXVKJjbLoShFjDqq7bvOy/G5aJ2Ppwpp52bFaU1TYuShngXTeILEuyoabMSsAjp/g5tyrnCszb0NKvGP7IO0dK50c=
X-Received: by 2002:a25:7c4:: with SMTP id 187-v6mr1798957ybh.73.1530048347313; Tue, 26 Jun 2018 14:25:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:25:06 -0700 (PDT)
In-Reply-To: <CY4PR21MB077453A70AC47C98C59C21088C490@CY4PR21MB0774.namprd21.prod.outlook.com>
References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <CADHfa2Aj9_-X-rtPR7OU-_cEXC=MnHpv88O_HTmB0-Yd-X_LLA@mail.gmail.com> <CABcZeBOb9G3jTnOg6ucba2060EqObM8LEo9F16mCCvwdHaU9=A@mail.gmail.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <CY4PR21MB0774D87B730D6A726AA272568C490@CY4PR21MB0774.namprd21.prod.outlook.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> <CAANoGhJXuHiSGB8zY4cGqf4xpkbqCjWExJwL1ou1vXSRn3mUvw@mail.gmail.com> <CAANoGh+7BNCKo9NQhh4qvAKeoUFVeYkY6VJ7wBLRz=sRDmoVwA@mail.gmail.com> <CY4PR21MB077453A70AC47C98C59C21088C490@CY4PR21MB0774.namprd21.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 26 Jun 2018 14:25:06 -0700
Message-ID: <CABcZeBOwcNEbPvPu3ksmj1C8qa4VFixZ++2GgDw89SL4Sf1Uag@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, Ben Campbell <ben@nostrum.com>, Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>, "draft-ietf-tokbind-https@ietf.org" <draft-ietf-tokbind-https@ietf.org>, Tokbind WG <unbearable@ietf.org>, IESG <iesg@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003b2f85056f922497"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/Rx9rdL8J8pBw8oHYOtEnXYlUI1E>
Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 26 Jun 2018 21:25:55 -0000

Should be, I need to do a double check to make sure other comments were
dealt with, but assuming so, then yes. Should be able to do this tomorrow

-Ekr


On Tue, Jun 26, 2018 at 2:19 PM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/.
>
>
>
> *From:* John Bradley <ve7jtb@ve7jtb.com>
> *Sent:* Tuesday, June 26, 2018 2:14 PM
> *To:* Ben Campbell <ben@nostrum.com>
> *Cc:* Andrei Popov <Andrei.Popov@microsoft.com>om>; Eric Rescorla <
> ekr@rtfm.com>gt;; Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>rg>;
> draft-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>rg>; IESG
> <iesg@ietf.org>rg>; tokbind-chairs@ietf.org
>
> *Subject:* Re: [Unbearable] Ben Campbell's Discuss on
> draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
>
>
>
> PS I suppose we need DIRK OR Andre to push a version with the changes.
>
>
>
> John B.
>
> On Tue, Jun 26, 2018, 5:12 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> Thanks Ben.
>
>
>
> EKR once this Discuss is cleared are we good to move on to the final
> embrace of the RFC editor?
>
>
>
> Regards
>
> John B.
>
>
>
> On Tue, Jun 26, 2018, 2:58 PM Ben Campbell <ben@nostrum.com> wrote:
>
>
>
> > On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
> >
> > Hi Ben,
> >
> > Thanks for the review.
> >
> >> Are the “applications” from paragraph 3 the same as those from
> paragraph 2?
> >
> > Yes, the same throughout paragraphs 1, 2 and 3.
> >
> >> It seems like paragraph 2 is talking more about local APIs (at least, I
> see that was mentioned in the text in version 17 but not in 18), but
> paragraph 3 uses an example of a signal from a server. (I can accept that
> the difference in control may be weak enough for web applications that the
> distinction does not matter.)
> >
> > The APIs provided by the TB implementation and called by the application
> are local APIs.
> > The application needs to make a decision whether to request that the TB
> implementation include a Referred binding in the TB message or not.
> > In the example, the server provides a signal to the application using
> the Include-Referred-Token-Binding-ID HTTP response header.
> > The signal could be different, or an application may have out-of-band
> ways to determine this (e.g. a local database of RP->IDP associations).
>
> I just re-read the 3rd paragraph, and I think I missed the “then” in
> “which then signals” on the first reading. It’s fine as is.
>
> Thanks!
>
> Ben.
>
> >
> > Cheers,
> >
> > Andrei
> >
> > -----Original Message-----
> > From: Ben Campbell <ben@nostrum.com>
> > Sent: Tuesday, June 26, 2018 11:41 AM
> > To: Eric Rescorla <ekr@rtfm.com>
> > Cc: Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>rg>;
> draft-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>rg>; The
> IESG <iesg@ietf.org>rg>; John Bradley <ve7jtb@ve7jtb.com>om>;
> tokbind-chairs@ietf.org
> > Subject: Re: [Unbearable] Ben Campbell's Discuss on
> draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
> >
> > Hi, thanks for the pointer.
> >
> > The text in version 18 is sufficient to clear my discuss. I have one
> remaining (or maybe new) non-blocking question for section 6:
> >
> > Are the “applications” from paragraph 3 the same as those from paragraph
> 2? It seems like paragraph 2 is talking more about local APIs (at least, I
> see that was mentioned in the text in version 17 but not in 18), but
> paragraph 3 uses an example of a signal from a server. (I can accept that
> the difference in control may be weak enough for web applications that the
> distinction does not matter.)
> >
> > I did not check my editorial comments.
> >
> > Thanks!
> >
> > Ben.
> >
> >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >>
> >> Ben,
> >>
> >> Does the following new text address your concern:
> >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/a
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxml2rfc.tools.ietf.org%2Fcgi-bin%2Fxml2rfc.cgi%3FmodeAsFormat%3Dhtml%2Fa&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842164263&sdata=Y%2BREp5UE5Jm9yUeshFJ1eXblnfs0C5W31uG%2Fk6mtIO0%3D&reserved=0>
> >> scii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Draft
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2FTokenBinding%2FInternet-Draft&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842174271&sdata=Lg7YBDv2yEZP3pYMkztxew9u34xhtNnY8ocvLuujD8M%3D&reserved=0>
> >> s/master/draft-ietf-tokbind-https-18.xml
> >>
> >>
> >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=
> 40google..com@dmarc.ietf.org> wrote:
> >> Hi Ben,
> >>
> >> thanks for the feedback. Most of it is addressed in the new draft (
> https://tools.ietf.org/html/draft-ietf-tokbind-https-16
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tokbind-https-16&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842184279&sdata=IJHYDJSWoUy5Ao8EWj1lHn8s5WuqTCD%2FH5hAVbmMdVk%3D&reserved=0>).
> See below (inline) for details.
> >>
> >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com> wrote:
> >> Ben Campbell has entered the following ballot position for
> >> draft-ietf-tokbind-https-14: 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://www.ietf.org/iesg/statement/discuss-criteria.html
> <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%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842184279&sdata=irsD0beoR1vbnMm%2FB5vrDF4gwAs4HHulXEumzjFJj0M%3D&reserved=0>
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-https%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842194288&sdata=m3aq2LeWis4PZmysUZeVb%2Fai%2BqEaewg%2BAlv8BB68%2FxM%3D&reserved=0>
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> I plan to ballot "YES", but I want to clear up once concern first:
> >>
> >> After reading section 6 several times, I don't know what it means. I
> >> think it's [...]
> >>
> >> Addressed in new draft.
> >>
> >>
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> Substantive Comments:
> >>
> >> §1.1: Please consider using the boilerplate from 8174 across the
> >> cluster. Both this and the protocol draft have lower case keyword
> instances.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §8.2:
> >> - Does it really make sense to wait for a user to request the keys be
> expired?
> >> I suspect the average user does this about never. Did the working
> >> group discuss possibly making the keys default to expiring after some
> period of time?
> >>
> >> Yes, we did discuss it. This was chosen consciously to be in sync with
> cookies and their expirations / manual user-initiated purges.
> >>
> >> - Why
> >> is the SHOULD in paragraph 2 not a MUST?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> Editorial Comments:
> >>
> >> §2:
> >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in
> >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open
> parenthesis before "in"
> >> seems misplaced. Also, as written the comma after "style" creates a
> >> comma splice. (Note that this pattern occurs elsewhere in the
> >> document.)
> >>
> >> - Paragraph 3: The paragraph is a single hard-to-parse sentence.
> >> Please consider breaking into simpler sentences.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> - example: Am I correct to assume the backslashes are just for print
> >> purposes and are not in the actual message? If so, please mention that.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> § 2.1:
> >> - first paragraph, "Within the latter context...": There was no former
> context.
> >> I suggest "Within that context..."
> >>
> >> Addressed in new draft.
> >>
> >> - 2nd paragraph: The first sentence is hard to parse. I suggest
> >> breaking it into separate paragraphs, or restructure without the
> >> center-imbedding.
> >>
> >> Addressed in new draft.
> >>
> >> - 2nd to last paragraph: Does "SHOULD generally"
> >> mean the same as just "SHOULD"?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §5.1: 2nd paragraph: Unneeded comma in "... itself, to another
> server..."
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §5.2,
> >> - last bullet: " (between client and Token Consumer)" seems more than
> >> parenthetical. Please consider removing the parentheses.
> >>
> >> Addressed in new draft.
> >>
> >> - paragraph after last
> >> bullet: The parenthetical phrase starting with "(proving
> >> possession...) is quite long and makes the sentence hard to parse.
> >> Given that the concept is covered in the immediately preceding
> paragraph, can it be removed?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §7.1 and §7.2: These sections seem to be copied from (or restate
> >> requirements
> >> in) the protocol and negotiation drafts. Can they be included by
> >> reference instead, or at least attributed?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §7.2, 2nd paragraph: This seams like a restatement of §7.1.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §8.3: Unneeded comma in first sentence.
> >>
> >> Addressed in new draft.
> >>
> >> Thanks again for the thoughtful comments!
> >>
> >> Dirk.
> >>
> >> _______________________________________________
> >> Unbearable mailing list
> >> Unbearable@ietf.org
> >> https://www.ietf.org/mailman/listinfo/unbearable
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842194288&sdata=NLYzqLIc9d9qH0VTbDcC%2BYdYaSR%2Bs653eBpQ6Alk%2FbA%3D&reserved=0>
> >>
> >>
> >
>
>