Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT)

Adam Roach <adam@nostrum.com> Mon, 04 June 2018 22:11 UTC

Return-Path: <adam@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 226F5130E05; Mon, 4 Jun 2018 15:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 F5jJgHUKwV20; Mon, 4 Jun 2018 15:11:47 -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 18F19130E07; Mon, 4 Jun 2018 15:11:47 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w54MBhnr065612 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Jun 2018 17:11:44 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Dirk Balfanz <balfanz@google.com>
Cc: The IESG <iesg@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, Tokbind WG <unbearable@ietf.org>, tokbind-chairs@ietf.org, draft-ietf-tokbind-https@ietf.org
References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com> <CADHfa2DPni78gNNZyQr6Tbt6DTzVWY+md7L4220NPTDprUCp6A@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <c103c5d7-3508-23b5-aae0-165dcd81db17@nostrum.com>
Date: Mon, 4 Jun 2018 17:11:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CADHfa2DPni78gNNZyQr6Tbt6DTzVWY+md7L4220NPTDprUCp6A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------20B89BDEB4E2C6C03BA5D2FD"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/rTTWTLIXJaKBS1p_rsrUzzEUKfY>
Subject: Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with 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: Mon, 04 Jun 2018 22:11:50 -0000

On 6/4/18 4:56 PM, Dirk Balfanz wrote:
> Hi Adam,
>
> 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.
>
>

Thanks! Some responses inline.


>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     Thanks to everyone who worked on this document. I am balloting
>     "Yes", but
>     still have a handful of comments, including several that I believe are
>     rather important.
>
>
>     ---------------------------------------------------------------------------
>
>     §2:
>
>     >  Once a client and server have negotiated the Token Binding Protocol
>     >  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>     >  [I-D.ietf-tokbind-negotiation])
>
>     Presuming this document is intended to cover use of TLS 1.3, I
>     believe this
>     list needs to also include [I-D.ietf-tokbind-tls13].
>
>
> Actually, the document doesn’t address TLS 1.3 - that will be covered 
> in a separate document.

Please adjust the title, abstract, and introduction to make this clear. 
I see neither prose nor technical mechanism in this document that 
precludes use with TLS 1.3, and it's virtually guaranteed that 
implementors will try to use it with TLS 1.3 unless there is clear text 
saying not to.


>
>
>     ---------------------------------------------------------------------------
>
>     §5.3:
>
>     >  When a client receives the Include-Referred-Token-Binding-ID
>     header,
>     >  it includes the referred token binding even if both the Token
>     >  Provider and the Token Consumer fall under the same eTLD+1 and the
>     >  provided and referred token binding IDs are the same. Note that the
>     >  referred token binding is sent only on the request resulting
>     from the
>     >  redirect and not on any subsequent requests to the Token Provider.
>
>     I think this needs some clarification about handling of multiple
>     redirections of
>     the transaction. E.g.: Token Consumer sends a 3xx to redirect the
>     user to a
>     Token Provider (using, perhaps, an endpoint that is in the process
>     of being
>     migrated), and then the Token Provider sends an additional 3xx to
>     get the
>     client to the correct server.  Presumably, the inclusion of the
>     referred token
>     binding should survive both redirections, but this text might be
>     read as
>     preventing that.
>
>
> This was consciously chosen to have the semantics that you took from 
> this section (i.e., the header doesn’t survive multiple redirects). 
> The migrating endpoint would have to communicate the Token Binding ID 
> to the final endpoint in some other manner (e.g., through a custom 
> authenticated query parameter).

That's okay as behaviors go, but I still think the document is somewhat 
unclear, as the notion of what constitutes a single "request" is a bit 
muddy in the context of request redirection. I would suggest adding 
clarifying text similar to what you say above.

/a