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

Hugo Krawczyk <hugo@ee.technion.ac.il> Sat, 01 August 2015 00:57 UTC

Return-Path: <hugokraw@gmail.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 96FFC1A8A86 for <tls@ietfa.amsl.com>; Fri, 31 Jul 2015 17:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6CdJ5JuU_VpO for <tls@ietfa.amsl.com>; Fri, 31 Jul 2015 17:57:17 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 4386E1A8862 for <tls@ietf.org>; Fri, 31 Jul 2015 17:57:17 -0700 (PDT)
Received: by lblf12 with SMTP id f12so55039827lbl.2 for <tls@ietf.org>; Fri, 31 Jul 2015 17:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=thAJIRLOi8Uo3b1SP820EBYScm1bFat2Ev5dn6Ljukw=; b=lyWA4oA9mD1T5ZI0wSGC5ZEYpFLJskIQRVh62KS+XGmX+aBO23Gl6AIINgCqQtutX2 ZV6p8VLFCaothUEEwewtYvF9Te167HHRziSvxReKB/q+xnm9ZBp02ZGq5K8aew1Ru2vP WrF2yBSYRee3vpgE7cIFFU6nJguekNefJvIZvSdKlZXuqwaYtZHMrGIG32TtXdlljU9R X0Sd2xgcaCcJpRRysTpKW6NF5b5Rmpm6qWTgtFqiCfqmgs0tdtpKd38d8tL/HDeDQ5WM JQ50v0zARhTvOz/8J/hhTGEL22vCrqMLr0g98Fzad8rH1eo2/potGxd1/RgDhNcVPJ4F OPGQ==
X-Received: by 10.112.85.3 with SMTP id d3mr6144713lbz.33.1438390635641; Fri, 31 Jul 2015 17:57:15 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.151.131 with HTTP; Fri, 31 Jul 2015 17:56:46 -0700 (PDT)
In-Reply-To: <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com>
References: <CABcZeBNeT5vijK=6T78P9VenPw0reO98qtuJAB_frJmppKwc+A@mail.gmail.com> <11AD662A-5D47-4E8F-98FE-8BE11D44B4BE@ieca.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 31 Jul 2015 17:56:46 -0700
X-Google-Sender-Auth: FphpsuhVVBNx0vSvghT2_mPD6co
Message-ID: <CADi0yUOioWUErvES8Hy-P+q1xKv1sA_v6U3J97mgTf=fiMRJ7w@mail.gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary=001a1134946ce2c2c5051c356a9d
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Alhb7_jNSHOECWVvzqWxpKC3llE>
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 00:57:20 -0000

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.

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).

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
>