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