On Fri, Jul 31, 2015 at 5:56 PM, Hugo Krawczyk <h...@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 <turn...@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 <e...@rtfm.com> >> > Subject: Summary of today's discussion on server-side signing >> > Date: July 22, 2015 at 08:52:31 EDT >> > To: Sean Turner <turn...@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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
