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

John Bradley <ve7jtb@ve7jtb.com> Wed, 11 July 2018 14:20 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 0F1F0130E8D for <unbearable@ietfa.amsl.com>; Wed, 11 Jul 2018 07:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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] autolearn=unavailable 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 a0Zc6VXgLNMg for <unbearable@ietfa.amsl.com>; Wed, 11 Jul 2018 07:20:08 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 94B2B130E78 for <unbearable@ietf.org>; Wed, 11 Jul 2018 07:20:08 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id h4-v6so21244616qtj.7 for <unbearable@ietf.org>; Wed, 11 Jul 2018 07:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=mA2uhiPoYxcEcvaMZB59mNFJEuK/Q1m62uarSPTlyOs=; b=1XSeFuKADvJolmGiI7MBdwqRNwyolLnaKGb94vdqln+A/PWuL50NvtfjgJ6WxJEbK2 /xt25IvkZ0FAwGFaTVnTgMoaFFMXzPlpu4rId0HJ8COODX4FGznlsG/lN7Jlp6GlBHzx 63rkOxclUykHlTYry+rxUcu5I2dVXdHqW5hjkuh7WAiHaAwaOAV8OU73+jHHoz5fvZDs o3uO6Q7Vi+hd+8oneznkZT2rx3+DBEWtX/DcuvGMz/MOaCaB+lSpPwY5ujAogxaR3cEU if6aTOCke5Ti0x8SUtDSlr2HE1oiBmv+H5mgpzMR78NQCCDa/lWbsD5vYKVHYd8QdIoM 15TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=mA2uhiPoYxcEcvaMZB59mNFJEuK/Q1m62uarSPTlyOs=; b=rmX09VVwWtvx7FrowyxkHdRA/7GUO2UllEbh1nc21Duvhwwf3dO60+EVNlSyWm0ATX RLP0SUzhAtw1sdKwDpRGmz06uoGEJFwv4g6ggMKs+DGP0KGylMvEt/ZG6RrHsH28/M4P LJMk4QEYK4zA9yystrChB222Pv52JXjACeo65wEpZDCWQU45Ber5dYIEQ8Q+fpyaimwx cHmo5V32UFxG/sk50C5ihsk8HkjT3uxjpNHpWTGYTbo8SI9bb0Znw+0BY28bpgS39kXz RMeMBDmlsWgWZ+hBhsZDKsURXhitLAjwdmPzyWcNwVSJvnkxXIfzciK7cHsq7pzI6b1J HAIg==
X-Gm-Message-State: APt69E1NDcQiOHjE0RV7X8N2MTr8CSQOtveDTiL+zo/qd0bRbPUK5ZSz 14nbYq1Z3j1uA57qa4IyL4FwWw==
X-Google-Smtp-Source: AAOMgpcDQkKpVuw7h0TTR8SeXqPeraaC1O8NpF7cOteoL4GQeGCcgMc6LKjeejsa5i0NBD4Rs8egvg==
X-Received: by 2002:ac8:174a:: with SMTP id u10-v6mr28272429qtk.367.1531318806978; Wed, 11 Jul 2018 07:20:06 -0700 (PDT)
Received: from ?IPv6:::ffff:192.168.8.101? ([191.126.172.31]) by smtp.gmail.com with ESMTPSA id b3-v6sm9983006qtg.20.2018.07.11.07.20.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 07:20:05 -0700 (PDT)
Message-ID: <5b461215.1c69fb81.930e2.0726@mx.google.com>
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Cc: "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>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Wed, 11 Jul 2018 10:20:05 -0400
Importance: normal
X-Priority: 3
In-Reply-To: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com>
References: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="_F199F463-E244-49AA-BD7C-7C3655F25511_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/goIkcuZjHrFXSSccT_gV9fG1TFs>
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 14:20:13 -0000

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