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

Dirk Balfanz <balfanz@google.com> Mon, 04 June 2018 21:56 UTC

Return-Path: <balfanz@google.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 63A58130E0A for <unbearable@ietfa.amsl.com>; Mon, 4 Jun 2018 14:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9Kt_hOe1MczW for <unbearable@ietfa.amsl.com>; Mon, 4 Jun 2018 14:56:34 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 E5116130E05 for <unbearable@ietf.org>; Mon, 4 Jun 2018 14:56:33 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id k16-v6so228562wro.0 for <unbearable@ietf.org>; Mon, 04 Jun 2018 14:56:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S/dvkkiyJr/0UxODR2BSRSMpzwd3aQ0LtborDCVC51I=; b=hhc65M2j2SR5jAHRvIT6Y+t1rvZ07hYflew+ar0qvsBifkTsTjvxABtcnU8bmbYeiM nImeYclMRJP+/HHXg4ZkQdGOcQRU6qzEf1lYEiVcdsdiXpDLELZ00WThHlmaE64LrX0U oZeTh5m/O3Zrp63u0v6j5gPFLsWLGa1Z9HAzmdoUk9y53YMI+GnE2/lSOxUaBsJTIVAa yFgFHx7SFxZKpkLjz3LtC1K9ZkUEeouKBZCJ9GIsNQtQtpeesiFWB4hsOy9gTYMwVGPh 5uvym/4Nic5CiUUwkS8+QiMD3Awknij8g43CCoEmv5iUG45jkofbj9ErUDLaMRaB//Qc UDAA==
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=S/dvkkiyJr/0UxODR2BSRSMpzwd3aQ0LtborDCVC51I=; b=ThYCHPw++1uFuOolyjiyLrJSxltY4CSF6Y1RiRzkmnx8wGQa3ws3qHtCcPwOZcsfL6 4qr7xVXyOAfRLkVB+TMMyTU942AKgiqiyXJSMUy9ombaPHVIagOLBL7ubW5TMSsT+rIM S5Y3Ai3MD3l8mIOzVUFP8gFlb1BttB/fB5UTiLpjdJpy/sUV4LeShWAJzhBGoxGO1dtG go2XSXEcIlP0EW14pEBNG0u5QAGjgLkEe22US18Tz2v+N1T2Rr4x8ShXFF77viJZu3bK axFHAD0ti5+gZtsE+9JHu/q6g92v6DZyq3guRR7z8RS3AMcQ8wUBHADL0FDXlu6/8bAr 4HKQ==
X-Gm-Message-State: ALKqPwc5bQhZP6xCxM20vyn0a4MRkXI/OKBVhg700GW148c/OpaDiHn/ 7NV46ETMurcSBf4YDVwTLTWcjykoNwst9lYlrWxee4Xrasg=
X-Google-Smtp-Source: ADUXVKID6DXJioj2zVUOEHYqbXFZFU/raomE9c8MFWvT3pNDNEzLexceZhcDhK5DXgyGMjTutEjKyRkSuwF2j2+vrDQ=
X-Received: by 2002:adf:8e30:: with SMTP id n45-v6mr16465068wrb.27.1528149391885; Mon, 04 Jun 2018 14:56:31 -0700 (PDT)
MIME-Version: 1.0
References: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com>
In-Reply-To: <152575956787.20253.13180458622500226833.idtracker@ietfa.amsl.com>
From: Dirk Balfanz <balfanz@google.com>
Date: Mon, 4 Jun 2018 14:56:18 -0700
Message-ID: <CADHfa2DPni78gNNZyQr6Tbt6DTzVWY+md7L4220NPTDprUCp6A@mail.gmail.com>
To: adam@nostrum.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
Content-Type: multipart/alternative; boundary="000000000000ab3623056dd8015b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/KBaF4--5g3TfIKHYV-F1HkpLsac>
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 21:56:38 -0000

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.


On Mon, May 7, 2018 at 11:06 PM Adam Roach <adam@nostrum.com> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-tokbind-https-14: Yes
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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.



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


> ---------------------------------------------------------------------------
>
> §5.3:
>
> >  This header field has only meaning if the HTTP status code is 301,
> >  302, 303, 307 or 308, and MUST be ignored by the client for any other
> >  status codes.
>
> I'm somewhat less sanguine about this than Alexey is: we've had 3xx-class
> response codes registered as recently as three years ago, and I see no
> reason to
> believe that the future won't hold additional development work on HTTP
> overall.
>
> While I understand that 305 and 306 are deprecated, and the use of the
> header
> field is nonsensical in 304 and, to a lesser degree, in 300, it seems that
> there
> is no harm that results in any of these cases if *this* document doesn't
> prohibit them.
>
> Taken one at a time -- In the case of 300, the presence of the header field
> would indicate that whichever option was followed by the user agent would
> receive a copy of the token binding, which is as sensible a thing for a
> server
> to ask for as 300 is in the first place.
>
> In the case of 304, there is no server to receive the token binding, so no
> harm
> could possible be induced.
>
> For 305 and 306, to the extent that these are used any more (and they're
> not),
> the request will arrive back at the same origin that sent the response;
> which,
> again, causes no information to be divulged that should not be.
>
> I would strongly recommend changing this to cover all codes in the 300-399
> range, for the purpose of forward-compatibility with new redirection codes.
>

Addressed in new draft.


>
> ---------------------------------------------------------------------------
>
> §5.4:
>
> >  The TLS Extension for Token Binding Protocol Negotiation
> >  [I-D.ietf-tokbind-negotiation]
>
> Same comment as above regarding [I-D.ietf-tokbind-tls13].
>
> ---------------------------------------------------------------------------
>
> §5.5:
>
> >  | {EKMn}Ksm: | EKM for server "n", signed by private key of TBID    |
> >  |            | "m", where "n" must represent server receiving the   |
> >  |            | ETBMSG, if a conveyed TB's type is                   |
> >  |            | provided_token_binding, then m = n, else if TB's     |
> >  |            | type is referred_token_binding, then m != n. E.g.,   |
> >  |            | see step 1b in diagram below.                        |
>
>
> I was able, with some effort, to muddle through these words and (I think)
> figure
> out the intention, but the construction is very difficult to follow. I
> think you
> want to swap the comma after "ETBMSG" for a period.
>

Addressed in new draft.


>
>
> ---------------------------------------------------------------------------
>
> §11.1:
>
> >  [fetch-spec]
> >             WhatWG, "Fetch", Living Standard ,
> >             <https://fetch.spec.whatwg.org/>.
>
> I share Alexey's concern about a normative reference to a living document.
> I
> would like to suggest referencing a specific snapshot (e.g., commit hash),
> but
> the specific referenced document makes this infeasible by means of an
> aggressive red-box warning that effectively precludes doing so. I agree
> that
> understanding the document is not a prerequisite to understanding or
> implementing this one, and so agree that (for the time being) moving the
> document to the informative reference section is advisable.
>

Addressed in new draft.

Thanks again for your thoughtful comments!

Dirk.



>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>