Re: [TLS] Fwd: Summary of today's discussion on server-side signing
Eric Rescorla <ekr@rtfm.com> Sat, 01 August 2015 01:01 UTC
Return-Path: <ekr@rtfm.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 49DE61A906F
for <tls@ietfa.amsl.com>; Fri, 31 Jul 2015 18:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_LOW=-0.7] 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 A-ZGM2z-Mljq for <tls@ietfa.amsl.com>;
Fri, 31 Jul 2015 18:01:38 -0700 (PDT)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
[209.85.212.180])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id D61181A9034
for <tls@ietf.org>; Fri, 31 Jul 2015 18:01:37 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so75723932wib.1
for <tls@ietf.org>; Fri, 31 Jul 2015 18:01:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=d3WZvxiyr/QYjT4VVwcIyOKTfLKlNgQVbPadsg4oSs4=;
b=RQtQAV/F0MQDRnM7ZSpp/I9peWgQytb/AE+qBE2YhYOpUVbYSWfRlzAKVLhfy4z6Ki
JRrs7HA/uQO85IhKpIr7MoUpkw0+2Vbzxx/8dQIZawkLuwOGRUlmvh8IujwbJUldJOw4
vFikH3iFDfrtotCcS7tczKtuK4Yqe0QBtIJBhsuUMwJPs6z2TKH6xjsMCqHS3SwGQiEv
P1vzH18jgerDgNEP+gxiRvtI6pfTb6QkZyjAXJfo2yNZbxpCDuD7jdl0qiqtYNzz3I2S
/svWIaDwJmycOFNHqItB9q3z3YOx6OaU9UzXbD7H3Uw5RFfmqeU6YVQYGcn8DBoUREgB
JZoA==
X-Gm-Message-State: ALoCoQmi7Es756gknts1BhrWMOHvM7Y3+6MsquZNvDplOYwMReMBPBj5FDWUpEUV91LkHx5knyWi
X-Received: by 10.194.216.68 with SMTP id oo4mr11169707wjc.81.1438390896541;
Fri, 31 Jul 2015 18:01:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.86 with HTTP; Fri, 31 Jul 2015 18:00:57 -0700 (PDT)
In-Reply-To: <CADi0yUOioWUErvES8Hy-P+q1xKv1sA_v6U3J97mgTf=fiMRJ7w@mail.gmail.com>
References: <CABcZeBNeT5vijK=6T78P9VenPw0reO98qtuJAB_frJmppKwc+A@mail.gmail.com>
<11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com>
<CADi0yUOioWUErvES8Hy-P+q1xKv1sA_v6U3J97mgTf=fiMRJ7w@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 31 Jul 2015 18:00:57 -0700
Message-ID: <CABcZeBNmasdzN2XkSKWLVMVhkmBezUrZPBmusWFUA17bKn48uA@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: multipart/alternative; boundary=089e0141a0926fd799051c357ac5
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0oWvHeipvTKPO5Jga7p8ZyZXFuA>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [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: Sat, 01 Aug 2015 01:01:41 -0000
On Fri, Jul 31, 2015 at 5:56 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote: > I am ok with whatever the WG decides, particularly when the reasons are > non-cryptographic but rather based on implementation considerations. > > Still, for the record, I'd like to correct the statement " > > KnownConfiguration is only useful with 0-RTT. > ". > > KnownConfiguration could be used with 1-RTT even if the client does not > send early application data in the first flight. > This would have allowed to save a signature also in the 1-RTT case > whenever the client has cached a KnownConfiguration. > Saving a signature is a major performance benefit with RSA signatures (are > they really going away soon?) but is a benefit also with ECDSA as it avoids > the need to send a certificate chain (shortening the handshake) and the > need to verify these certificates. ECDSA also has a cost for the client. > This was very bad writing on my part. What I was trying to say was that once you commit to signing every transaction, then it's not helpful to use the KnownConfiguration mechanism with 1-RTT because you've already given up the optimizations you quite rightly point out. Sorry for the confusion. Lastly, the protocol would be secure without the signature (in the case the > client uses a known configuration), a property that enables the use of the > protocol with offline signatures (to-be-specified). > Thanks for pointing this out. Best, -Ekr Hugo > > On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner <turners@ieca.com> wrote: > >> 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 >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
- [TLS] Fwd: Summary of today's discussion on serve… Sean Turner
- Re: [TLS] Fwd: Summary of today's discussion on s… Hugo Krawczyk
- Re: [TLS] Fwd: Summary of today's discussion on s… Eric Rescorla