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:14 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 D57FC130E5D for <unbearable@ietfa.amsl.com>; Tue, 26 Jun 2018 14:14:44 -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 nQYCMo8Dejge for <unbearable@ietfa.amsl.com>; Tue, 26 Jun 2018 14:14:42 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 03779130E3F for <unbearable@ietf.org>; Tue, 26 Jun 2018 14:14:42 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id p1-v6so3008046wrs.9 for <unbearable@ietf.org>; Tue, 26 Jun 2018 14:14:41 -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=gM14tQ1tcQG1L1jXGeRhnkdZszUsBE+idfrIrwIZkxg=; b=ZvRRn8ZTRVOm3DzIY218HzY3Fw6nYqILub4xRQHDCCYCuISsJ4MeUEL65gF51mvqiZ 5KfShk+hPyKWPKU77ITMb5/fTpS2viC0zGFObHHv4MR389bDruNR2mtta+6K2Bfs2PXI UB96ysunOJGJxv69ShDIM4sxpnKYWGG3pWABjmr17Zj7gvsK84DwfiQIGcOiknwhwUF2 pe1sgjHBwdHUnr54DuzNSeLC/0q8Y38pOykYjnZmM/brUsO8SHjsk/A0WegC8L1CzWOO hRBX8ox6PzSCp8cvsKs/Gj/7MZ+/YXgV+FpUqrbzqly0ryJ+XNqjObp0GJMuzN6cG+Po NSoA==
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=gM14tQ1tcQG1L1jXGeRhnkdZszUsBE+idfrIrwIZkxg=; b=okwHMr0W1ZXYtM/DfxqcjTszvkL8LEfbnpUMqDxmxvSw4owYv3wmchy4uF8C2ahQ+b FU9oAKBEzmuevKXAwWxQKwzgjB75W0Is0eQn3MaG9wQFqj1bGXdoEWHGSkYWX25Acbml Y2R47uYzJ22qfMqocj6try59WX7GzcChhx8SKRPtCDQziIJWX93RJ9yEjhZ4yloNbSs6 PGrqJdvfan6idiCjyp9yk8EBhePwA52rD/F3sbiC0D/XsHiy94VA9DoZbcf0wRLWqPVh SqpD0Q1Jt8KZ608Q/3f5ypguEacjcVVLR0u6aqklz3ovZKErNsiDmU0Mwvdv41/tADEX U2Yg==
X-Gm-Message-State: APt69E0RDqEYYAJgRfOUvz8cromWHgNokwiyu2dHEFBlTJHpynWJp6KU 4xiZEyI71dr0uU9v18fHQJtZIWjD3yy6vnZhFEUUEQ==
X-Google-Smtp-Source: AAOMgpeiGrdXRXfogvx5j/onALUXAMVfjGvRQ+frZzYKWwuaiu6sV0YEWJ4b0Pm8PdIXhNuslGrG7fWf+WbiiBjjIXU=
X-Received: by 2002:adf:9ed0:: with SMTP id b16-v6mr224535wrf.170.1530047680162; Tue, 26 Jun 2018 14:14:40 -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> <CAANoGhJXuHiSGB8zY4cGqf4xpkbqCjWExJwL1ou1vXSRn3mUvw@mail.gmail.com>
In-Reply-To: <CAANoGhJXuHiSGB8zY4cGqf4xpkbqCjWExJwL1ou1vXSRn3mUvw@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Tue, 26 Jun 2018 17:14:28 -0400
Message-ID: <CAANoGh+7BNCKo9NQhh4qvAKeoUFVeYkY6VJ7wBLRz=sRDmoVwA@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, Tokbind WG <unbearable@ietf.org>, IESG <iesg@ietf.org>, tokbind-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000077487c056f91fce8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/9Vb_J7kRdMgmfQAPGa3d6bU8_aQ>
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:14:45 -0000

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