[TLS] Fwd: Summary of today's discussion on server-side signing

Sean Turner <turners@ieca.com> Mon, 27 July 2015 14:26 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63691B2E45 for <tls@ietfa.amsl.com>; Mon, 27 Jul 2015 07:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham
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 hMzlHyHvJB4l for <tls@ietfa.amsl.com>; Mon, 27 Jul 2015 07:26:18 -0700 (PDT)
Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.100]) (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 544941B2E2E for <tls@ietf.org>; Mon, 27 Jul 2015 07:26:18 -0700 (PDT)
Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 170B59C78876A; Mon, 27 Jul 2015 09:26:16 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 056899C78870A for <tls@ietf.org>; Mon, 27 Jul 2015 09:26:16 -0500 (CDT)
Received: from [96.231.221.219] (port=55139 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from <turners@ieca.com>) id 1ZJjM7-0000Tq-C1 for tls@ietf.org; Mon, 27 Jul 2015 09:26:15 -0500
From: Sean Turner <turners@ieca.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Jul 2015 10:26:12 -0400
References: <CABcZeBNeT5vijK=6T78P9VenPw0reO98qtuJAB_frJmppKwc+A@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.221.219
X-Exim-ID: 1ZJjM7-0000Tq-C1
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:55139
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hRiK6aQEtSsFV3P0nM6gnlJ_Hvk>
Subject: [TLS] Fwd: Summary of today's discussion on server-side signing
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 27 Jul 2015 14:26:20 -0000

All,

I asked ekr to write a brief summary of the server-side signing issue.  The summary provided matches the WG consensus as judged by the chairs.  Please let us know if you object to the way forward by August 3rd.

J&S

Begin forwarded message:

> From: Eric Rescorla <ekr@rtfm.com>
> Subject: Summary of today's discussion on server-side signing
> Date: July 22, 2015 at 08:52:31 EDT
> To: Sean Turner <turners@ieca.com>
> 
> Sean,
> 
> Here's a summary of today's discussion on signing and KnownConfiguration.
> 
> SUMMARY
> The WG agreed that the server must sign whenever certificate authentication
> is used (even if the KnownConfiguration is used).
> 
> 
> BACKGROUND
> The current draft requires the server to send a Certificate/CertificateVerify
> whenever either:
> 
> (a) The KnownConfiguration option is not in use.
> (b) The server sends a ServerConfiguration
> 
> but it does not need to sign if the KnownConfiguration option is in
> use but no new ServerConfiguration is provided.  Several people (most
> recently Martin Thomson) have suggested that it would be simpler to
> just require the server to sign any time certificate-based
> authentication is in use. The penalty for this is an extra sign/verify,
> as shown in the following table:
> 
> Scenario                           Client                   Server
> ------------------------------------------------------------------
> 1-RTT                  1 (EC)DHE + Verify         1 (EC)DHE + Sign
> 
> 0-RTT (current,                 2 (EC)DHE                2 (EC)DHE
>   no new config) 
> 
> 0-RTT (current,        2 (EC)DHE + Verify         2 (EC)DHE + Sign
>   new config)
> 
> 0-RTT (proposed)       2 (EC)DHE + Verify         2 (EC)DHE + Sign
> 
> 
> So, the performance difference here is between line 2 and line 4,
> since whenever you provide a new config (line 3) you have to sign
> anyway. The benefit is that it makes the server side of the handshake
> essentially identical in both 0-RTT and 1-RTT, which is nice from an
> implementation and analysis perspective.
> 
> 
> SUMMARY OF WG DISCUSSION
> During the WG discussion today, there was rough consensus to adopt
> this change (i.e., always sign). A number of arguments were advanced
> in favor of this change.
> 
> (1) It's significantly simpler for implementors and (at least informal)
>     analysis. A side benefit is being able to merge the extension
>     logic for 0-RTT and KnownConfiguration, since KnownConfiguration
>     is only useful with 0-RTT.
>     
> (2) It extends the properties we were shooting for with online-only
>     signatures and requiring that the server always sign ServerConfiguration,
>     namely continuous proof of access to the signing key.
> 
> (3) The performance cost of an extra ECDSA signature is small and
>     shrinking fast (per Ian Swett channelling Adam Langley), and
>     people who care about speed will cut over to ECDSA (certs are
>     readily available).
> 
> (4) You can still do 0-RTT with PSK resumption, which is computationally
>     much faster.
> 
> On balance the WG seemed to feel that these were more compelling than
> the performance value of the optimization.
> 
> There was also a recognition that signature amortization was valuable,
> but the consensus was that instead of doing this here, it would be
> better to adopt Hugo's suggeston from a while back to have a
> certificate extension that allowed offline signatures. This allows
> both amortization *and* delegation, while not constituting a threat
> to existing TLS 1.2 implementations. We agreed that this could be
> worked in in parallel but shouldn't hold up TLS 1.3.
> 
> Per WG guidance, I'll be preparing a draft PR for this.
> 
> -Ekr
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>