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

John Bradley <ve7jtb@ve7jtb.com> Tue, 26 June 2018 21:13 UTC

Return-Path: <ve7jtb@ve7jtb.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 5BA83130E42 for <unbearable@ietfa.amsl.com>; Tue, 26 Jun 2018 14:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 doHPS-3RUyjp for <unbearable@ietfa.amsl.com>; Tue, 26 Jun 2018 14:13:00 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 F3971130ECD for <unbearable@ietf.org>; Tue, 26 Jun 2018 14:12:59 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id f16-v6so18613565wrm.3 for <unbearable@ietf.org>; Tue, 26 Jun 2018 14:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tl+SWfC9Zllkf7Dhiirj71H1HLWKFlVqrniqKfCRgFQ=; b=erGHzvKHJWrBQfWkmHzAXqp78nsD2CSy7+MWmQu6c482TE5gWrgkVW0TpAQO3VwyFR u0cPl2yOS7NDnWyMFsYppmwm6QXQXcEzLcWHSh8ADjFpfPlnZLM/qfUh7QAf9Y+NEnRg MJ+CTwfTv1MJsE9ALgPaRKHUhRHXDukaMtSkx8/RMxcORfbMfiAih5V5P9L/h/67EwGr +VJhxyXS4z10eoKm5rCaSzFzKdEfdIC084R9l+iMuaSFYKTkqfFRdUKBO07+yJhDWDoL IZzvhWOgueIQYhET0ySgk4Cs167+7Sx44DPxP/dkhGnMkO9UOPSQQ5cn1HLzR1g6MzuY eO7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tl+SWfC9Zllkf7Dhiirj71H1HLWKFlVqrniqKfCRgFQ=; b=ThYrxlvGtyM1H1iUmdXKT93+qdHXxJSEcCX1gB5D5P4plX0sDMFnci7axrHadFASWk 85wdWJf3jugn04yan7EZ4i2ZcHwsfOKGqc2Rs4n+BY/3GiQx0iND9t3NTf3rjj7QhOEY umMqFwVNGeS5BvdeFxzYLfoNZQHCWQz3pqTyoArtQDAvJWHgfyStLVWNvTqBGVjp/CNM dJVK+Nmv8pSXd4+HQZx1hV2ohaNCW77FGpqUf+xDauIKlADjQqGjMobDDXOD63ylnaje V+9t3N3pCpfR/dPiJwNaetNdWkD61P3JyTTwHjaGTzhlr6epph9Jzn3u3wmQyAGTevSL ytmQ==
X-Gm-Message-State: APt69E15VIQ16IiaqBmXgESX9ZHTc9c+9Q8xPJ4fWOSfvGYBv4zcWPvx CVqlh8IsBkqcaapREp+O1ScR5gt/AOFxAF9OfB4oTm5h
X-Google-Smtp-Source: AAOMgpfsv15ghIVrO8Dt2phnztlq69TcxcmIt56+JDs/CJgv2Fo/3+Jzm0sNQFUA4HzbUH2KUxkpAnPE8kpWmEhBeVc=
X-Received: by 2002:adf:84c5:: with SMTP id 63-v6mr2917941wrg.50.1530047578108; Tue, 26 Jun 2018 14:12:58 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Tue, 26 Jun 2018 17:12:46 -0400
Message-ID: <CAANoGhJXuHiSGB8zY4cGqf4xpkbqCjWExJwL1ou1vXSRn3mUvw@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>, Eric Rescorla <ekr@rtfm.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>, The IESG <iesg@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000620e13056f91f655"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/U3IQU1iRZ3azMPZiwSKfK6yyY8U>
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:13:04 -0000

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
> >> scii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Draft
> >> 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). 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
> >> 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/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> 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
> >>
> >>
> >
>
>