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

Denis <denis.ietf@free.fr> Mon, 17 September 2018 09:32 UTC

Return-Path: <denis.ietf@free.fr>
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 9B6ED130DE3 for <unbearable@ietfa.amsl.com>; Mon, 17 Sep 2018 02:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 nIy95UdYbwyq for <unbearable@ietfa.amsl.com>; Mon, 17 Sep 2018 02:32:37 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4494130DC1 for <unbearable@ietf.org>; Mon, 17 Sep 2018 02:32:36 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id A0361780395 for <unbearable@ietf.org>; Mon, 17 Sep 2018 11:32:34 +0200 (CEST)
To: unbearable@ietf.org
References: <bba419c9-103b-5cb0-4267-c5cec9c7b3dd@sunet.se>
From: Denis <denis.ietf@free.fr>
Message-ID: <6bea7c7b-80ec-9637-324e-730998c461ad@free.fr>
Date: Mon, 17 Sep 2018 11:32:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <bba419c9-103b-5cb0-4267-c5cec9c7b3dd@sunet.se>
Content-Type: multipart/alternative; boundary="------------FB48D9ADCBAFBC372E6A2D83"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/wXykYAbkU62hI-aM5PDLkkn83RE>
Subject: Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp
X-BeenThere: unbearable@ietf.org
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.\"" <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, 17 Sep 2018 09:32:40 -0000

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 list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable