Re: [TLS] Call for consensus: Removing 0-RTT client auth

Benjamin Kaduk <bkaduk@akamai.com> Thu, 31 March 2016 17:18 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB81512D09C for <tls@ietfa.amsl.com>; Thu, 31 Mar 2016 10:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.73
X-Spam-Level:
X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 GJwFLgDhB1pF for <tls@ietfa.amsl.com>; Thu, 31 Mar 2016 10:18:00 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AB25912D6A1 for <tls@ietf.org>; Thu, 31 Mar 2016 10:17:56 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5E0BD4334A2; Thu, 31 Mar 2016 17:17:56 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 47B6B43344D; Thu, 31 Mar 2016 17:17:56 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459444676; bh=MYbuHLmt6HIdlot4rKA/WvWdSXTUfxdog6xoGs5EnIE=; l=4578; h=To:References:Cc:From:Date:In-Reply-To:From; b=Gq+7hYXuuEoswLUq9kRsCmXIkeag5G0srPpp/rLsgNFsCqYVcTu3m7sFeGFGBreTx Hsvf9SXZNWeJdwba/zk3kV/bfYIzsGG8uHsQYSGMyDHzkgd5V09LL7J6UQMe2a0Q4j yFt0ZENOY07RkihytkovzTE68Uklht+wlMQ2MqwY=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 0F74D1FCA4; Thu, 31 Mar 2016 17:17:56 +0000 (GMT)
To: Eric Rescorla <ekr@rtfm.com>
References: <AABACDA8-6A12-4023-A971-1254CED4893F@sn3rd.com> <56FD154D.1030300@gmx.net> <CAH9QtQGBrvbPp4V8SMwK1WuUQpJKMo-1z8bs6rCO_d-w0JJE8A@mail.gmail.com> <56FD5978.3040401@akamai.com> <CABcZeBM62eZfZX_yyBbur82ru4y8COzp4s2rurSw6E-XJYeiMg@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <56FD5BC3.5060103@akamai.com>
Date: Thu, 31 Mar 2016 12:17:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBM62eZfZX_yyBbur82ru4y8COzp4s2rurSw6E-XJYeiMg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020704060407070008030002"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dDaEjPZ2gBKPBiipiOout0rwlHw>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2016 17:18:02 -0000

On 03/31/2016 12:13 PM, Eric Rescorla wrote:
>
>
> On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <bkaduk@akamai.com
> <mailto:bkaduk@akamai.com>> wrote:
>
>     On 03/31/2016 12:02 PM, Bill Cox wrote:
>>     On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig
>>     <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>>
>>         Hi Sean,
>>
>>         we at ARM would find it somewhat unfortunate to remove the client
>>         authentication feature from the 0-RTT exchange since this is
>>         one of the
>>         features that could speed up the exchange quite significantly
>>         and would
>>         make a big difference compared to TLS 1.2.
>>
>>
>>     Client certs can still be used with PSK 0-RTT, but only on the
>>     initial 1-RTT handshake.  it is up to the client to ensure that
>>     the security of the resumption master secret (RMS) is solid
>>     enough to warrant doing 0-RTT session resumption without
>>     re-verification of the client cert. 
>
>     That seems to rule out most corporate uses of client certs [for
>     0-RTT client authentication], since I doubt anyone will be
>     interested in trusting that the client does so properly.
>
>
> Do those servers generally carry over client auth through resumption?
>

I don't know, offhand.  I just wanted to point out that for one sizeable
use case for client certs in general (not considering 0RTT), this
proposed scheme does not seem useful.  It may still be useful in other
use cases, of course.

-Ben