[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) by gateway32.websitewelcome.com (Postfix) with ESMTP id 056899C78870A for <tls@ietf.org>; Mon, 27 Jul 2015 09:26:16 -0500 (CDT)
Received: from [] (port=55139 helo=[]) 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-Exim-ID: 1ZJjM7-0000Tq-C1
X-Source-Sender: ([]) []: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


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.


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.
> The WG agreed that the server must sign whenever certificate authentication
> is used (even if the KnownConfiguration is used).
> 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.
> 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