Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-https-17: (with COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 11 July 2018 16:34 UTC

Return-Path: <ben@nostrum.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 D996A130F58; Wed, 11 Jul 2018 09:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 FxnWMmw3oauw; Wed, 11 Jul 2018 09:34:29 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E38FC130F4A; Wed, 11 Jul 2018 09:34:28 -0700 (PDT)
Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6BGYLg0041058 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 11:34:22 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95]
Content-Type: multipart/signed; boundary="Apple-Mail=_5C00D37B-3A9F-4B05-A671-7D0C994A2DAE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Ben Campbell <ben@nostrum.com>
X-Priority: 3
In-Reply-To: <5b461215.1c69fb81.930e2.0726@mx.google.com>
Date: Wed, 11 Jul 2018 11:34:19 -0500
Cc: The IESG <iesg@ietf.org>, "draft-ietf-tokbind-https@ietf.org" <draft-ietf-tokbind-https@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>, "unbearable@ietf.org" <unbearable@ietf.org>
Message-Id: <F44905A0-EB5B-4476-A63E-A24A761FF2ED@nostrum.com>
References: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com> <5b461215.1c69fb81.930e2.0726@mx.google.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/tEEBhqAMI9owG5nVEjUOKNXIiGc>
Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-https-17: (with COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 11 Jul 2018 16:34:31 -0000

Hi John,

Now that you see my confusion, I will leave it to you to decide how best to fix it, if at all.

Thanks!

Ben.

> On Jul 11, 2018, at 9:20 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> Thanks Ben,
> 
> I have gone over 6 again, and think I see the confusion.
> 
> The point of section 6 is to remind platforms that provide native HTTP API to also expose token binding to the applications using them.
> 
> An example native app such as a OAuth client on a phone is not using redirects from the resource server to the Authorization Server, it is making a direct HTTP request to the AS Token Endpoint.   If that app wants to include the tokenbindingID from the connection to the Resource server as the referred token binding in the HTTP POST to the token endpoint it needs some way in the HTTP API to signal sending the referred token binding for the other connection.
> 
> IETF specs slip into a grey area when we start talking about API.   The work group participants wanted to keep this goal oriented rather than having any wording that might impact there intended API implementations.
> 
> In the third paragraph it is true that native API should only convey the referred token binding to servers if signaled to do so by an application.
> 
> It is also true in a general sense both for redirect and JS browser apps as well.
> I think that while true the third paragraph may have morphed into more of a general privacy concern, using redirect as an example.
> 
> Would it work for you if we refocus the third paragraph to focus specifically  on native apps.
> 
> Eg.  Native API MUST only convey referred token binding information if signaled by an application.
> 
> Then leave the rest to the Privacy Considerations reference.
> 
> That or just dropping the third paragraph.
> 
> Let me know and we can update in the final version
> 
> Regards
> John B.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for addressing my DISCUSS and substantive comments in pre-submission
> text. I did not check editorial comments.
> 
> I have one remaining (non-blocking) question on 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.)