Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

Hans Zandbelt <> Mon, 17 September 2018 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB522130DEA for <>; Mon, 17 Sep 2018 02:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W4-eoSyi52D7 for <>; Mon, 17 Sep 2018 02:53:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9AD71277D2 for <>; Mon, 17 Sep 2018 02:53:46 -0700 (PDT)
Received: by with SMTP id q5-v6so10916173iop.3 for <>; Mon, 17 Sep 2018 02:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z0CjipHHtxQgirWYJHaLZ9fgx9/n5fUWes5DxknJzJM=; b=t+kLXAYTelN3irPSFAG0u+C2Qwca7R418v5S+lDl4i+FwG1JXxSOusogtzhbj1cX25 rpZg9C+3PzdosIGoSnJ3uWmKHH9GLAv9oEjOiJUGb4EAjoZKEKwQ3js0vpMPHXBxZaLL bPpFL8sMNnSah9oZRzfzjUjwJId/1ZQrHLiE2cnzz8/8IkkvNXQgpOPJITiPsiatFYpz JLUROCzdKIMFNusgtfzOWDon/byDpfYcMyXVcVMelpEId1rMlay4lHePfbZEvOasXuE7 yytFGR5vmwpDNbi6Z4VC2nHp2LmnQlCGwETq48QbX+WALXwHrIY06+SiXDxR5BE6Iw31 +uBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z0CjipHHtxQgirWYJHaLZ9fgx9/n5fUWes5DxknJzJM=; b=tQbKzjyAD12rxD9lQAFnfHaOwr6+0/3pU6GVJ6YdrkSdEy4KguEZa+fsR5l2qt9+/Y g2KvWt3Z/I9QivP47nZHZbxEbWfcRrrnmACa65b07iCfqnk18iqIB9zPcHa86Q40hMuG ZHKj5napv5CQA/+3ztPUaO0pW+hg4P9UlI6r+g6Mledlgp/km5qLjIzEe2HVqaFyPuWN n3OEctInyP/ZImKIDKZ7adhnh7mP2gWTl9qmbrD0TP7FuIK8YtPTrbMtldb4iF5ZdDlE 5FNi7Q9V+1PGojDl1OHh1nmRzqabdRdkk03FFQQJLsu5Oepv1VGUiotmEDQEftwmSb7S 6ifQ==
X-Gm-Message-State: APzg51AdSND0BEMNSHXYKhpSz/9iLxRJdSVVSRtpwvd0Vs8Rr/pbgwxx lMmPHlbRi7c803aa6Lk1Thlp7dXrlNZKQ8wCpYywpA==
X-Google-Smtp-Source: ANB0VdYebGMmOGsOiHQ4UNCCemw5uZRfHNRzgg9OaF3H1aL9cWnYCPNNXSJ5PMnDg6ggMgyQwLuYzXtpRIHibGy6Nyo=
X-Received: by 2002:a6b:8d0f:: with SMTP id p15-v6mr19945707iod.98.1537178026140; Mon, 17 Sep 2018 02:53:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Hans Zandbelt <>
Date: Mon, 17 Sep 2018 11:53:34 +0200
Message-ID: <>
Cc: Tokbind WG <>
Content-Type: multipart/alternative; boundary="000000000000347d4805760e2690"
Archived-At: <>
Subject: Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp
X-Mailman-Version: 2.1.29
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.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Sep 2018 09:53:50 -0000

Can we please stop adding text that says "don't share your private key with
others" to IETF drafts? That is an inherent part of PKI and does not need
to be repeated everywhere IMO, just like text about how verifying TLS
server certificate should work is not repeated in drafts where TLS is a
requirement. Perhaps a reference to generic PKI principles and guidelines
may be included?


On Mon, Sep 17, 2018 at 11:32 AM Denis <> wrote:

> Comments on draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with TLS
> Terminating Reverse Proxies
> The introduction states:
> An HTTP server issuing cookies or other security tokens can associate them
> with the Token Binding ID, which ensures those tokens
> cannot be used successfully over a different TLS connection or by a
> different client than the one to which they were issued.
> When there are only external attackers, the sentence is correct but is
> incorrect when there is a collusion between a legitimate client and another
> client.
> The sentence should be corrected. Here is a proposal:
> An HTTP server issuing cookies or other security tokens can associate them
> with the Token Binding ID, which ensures those tokens
> cannot be used successfully over a different TLS connection or by a
> different client than the one to which they were issued, as long as
> there is no collusion between the legitimate client and another client.
> In the "Security Considerations" section (section 4), some explanations
> should be added. Here is a proposal:
> The token binding mechanism is efficient against external attackers, but,
> in case a legitimate client collaborates with another client,
> the mechanism can be defeated since the legitimate client, using the
> private key which proves possession of the security token, can perform
> all the cryptographic computations that the other client needs to
> demonstrate the possession of that security token.
> Denis
> This message marks the start of a 2 week WGLC on
> draft-ietf-tokbind-ttrp-06 as agreed in Montreal but only now effected
> by your chair.
> Please provide your final comments, voices of support or objections
> by COB Fri 28 Sept in any TZ.
> 	Best R
> 	Leif
> _______________________________________________
> Unbearable mailing listUnbearable@ietf.org
> _______________________________________________
> Unbearable mailing list

ZmartZone IAM -