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

Hans Zandbelt <> Mon, 17 September 2018 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9107130EA3 for <>; Mon, 17 Sep 2018 12:12:25 -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 X5wFh5uzgJ_r for <>; Mon, 17 Sep 2018 12:12:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C238130EA1 for <>; Mon, 17 Sep 2018 12:12:22 -0700 (PDT)
Received: by with SMTP id h1-v6so12429136itj.4 for <>; Mon, 17 Sep 2018 12:12:22 -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=MyThqsQ3yPdBh/oiHyREiE30bV4d8szyhvhujRn+dUo=; b=sMsd1KPMCi8EAPcNhV3bidPGo2iYQDdy9TEMqDCV+N/K0k3agyUlubAFa93ZadMDaj 9OJV3LV4BkB3vdPQmtdmVqS4Xsn2fDQYZLIQRyTc/ZiC4UxPg296SEVCVAeVuTdSzDy0 3wSlnMUg+We0u+6LfsdU18qXev11oT4mNx63bfDganbJxxIDeIFW0EPPBzR9Lxntt6mu B4LMD/D638fKAz2uGLnQRPbdsz7n0ue5Rna7GLlpEiPiIRa4rELzkzJ/zWBMB9Q2noSz IxQyyxv3j/EB6xtcYvoaWxpIgW5DpWsPVCeFUJI02YfDyYX/IgZeU3RIWN/dL7KjzBtx TqDg==
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=MyThqsQ3yPdBh/oiHyREiE30bV4d8szyhvhujRn+dUo=; b=YQiY/51ppkx8vB3zNoCelgycuR85dcH+uWbOBY+Bkc7A4VuvS3sMzFL3bNLBk+DWhB 6ENtKHoHfDetZtQRHaCzGeLEiuqHORUXhyob5msjeNTH7P9hrkvFyHf0xqnO3rvtS+Yx 7mMvYLNvUGVyuQ9NwxPzO3AJTwXnfyHl+cuZEjil37tnNYdk9uJ3Mh+/D2lcnecYaxGh BOGe7AZ3Y1fPbeONTzt40nhtCEzVFODxkvSjehzuCy7OdlsG9FiCVxVAExmbIgIwljbl qN4Xf83VlONQiS7sYFiBP6z8iOvllXipz9GJHU+P7PnTqOGRJFpeVAXaajBkNuSQm0QI 27Fg==
X-Gm-Message-State: APzg51Ba5QBqiVjXKhp7b4DwQ1n1+n0pvTaf/+dImF66G1SbnLVaE8dZ IKj5xd5Au7rYSj4sULowkViXZUgVzNWNAN3HNReTMA==
X-Google-Smtp-Source: ANB0VdbvN9PCmud3cKh7uQyMrXEBcOf+yxkN9Gk7ooXAPhSfkZbAT8JIFyxM8N6JpYv5C1oCEPtGUTVZx3WYarogirI=
X-Received: by 2002:a02:b18d:: with SMTP id t13-v6mr24351944jah.64.1537211541670; Mon, 17 Sep 2018 12:12:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Hans Zandbelt <>
Date: Mon, 17 Sep 2018 21:12:10 +0200
Message-ID: <>
Cc: Tokbind WG <>
Content-Type: multipart/alternative; boundary="000000000000e2e1ef057615f330"
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 19:12:26 -0000

same reasoning holds for "don't share your HSM" with others, "don't share
your access tokens with others" and really "don't share the information you
got with the access token with others" (the latter being a more effective
"attack" than "colluding" on the access token); do we really want to spell
this out everywhere instead of referring to it?


On Mon, Sep 17, 2018 at 12:43 PM Denis <> wrote:

> Hans,
> This has nothing to do with "private key sharing". Private keys are
> usually protected by some hardware device which does not allow to export
> these keys.
> However, a legitimate user can *use* his hardware device which means that
> he can ask to his device to perform some cryptographic computation with the
> private keys
> that are stored in it.
> In the past, when doing a threat analysis, only external attackers were
> being considered. Collaborative attacks is a different kind of threat that
> should also be considered.
> However, it only applies to some specific contexts:
> If the security token contains a sufficient number of attributes that
> allows to fully identify the bearer, the bearer will probably refuse to
> collaborate with anybody else,
> because that other body could fully impersonate him.
> If the security token contains one or more attributes that do not allow to
> fully identify the bearer, the bearer may accept to collaborate with
> somebody else, because
> he cannot be identified. Typical examples of such an attribute are: "over
> 18" or "resident of Florida". Such attributes may allow to access to a
> service.
> Any solution using software only is unable to counter collaborative
> attacks. Any solution using hardware devices that are only protecting the
> private keys, *but not their usag**e*,
> are also unable to counter collaborative attacks. The topic has nothing to
> do with generic PKI principles and guidelines. However, adding some
> additional explanations into
> the security considerations section along those provided above could be
> useful.
> Denis
> 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?
> Hans.
> 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 -

ZmartZone IAM -