On Tue, Nov 24, 2015 at 9:53 AM, Mike Hamburg <m...@shiftleft.org> wrote:
> > > In general, servers have signature keys, not static DH keys. QUIC bridges > this by > having the server generate an offline signature over a static DH key, but > TLS explicitly > rejected this as a generic approach because of concerns about the impact > of producing > a long-term delegated credential, especially if generic TLS credentials > could be used to > do so (see the extensive discussion on the list a while back on the > mailing list as well > as [0]). So, the current design requires the server to prove present > possession of the > signing key, not just that it possessed it at some point. > > It's correct that demonstrating proof of possession of a long-term DH > share is > somewhat faster than signatures. There are two potential ways to do this > with > TLS while retaining the guarantees above: > > > Correct-ish. For example, the current implementation of ed448 takes 463k > skylake cycles (new cpu, top of the chart, I'm on a phone, sorry) to > compute ecdh, which would need to happen twice. But it takes 162kcy to sign > and 509k to verify, for a total of 671k vs 926k. Signing favors the server > while double DH favors the client; there are good reasons to go in either > direction in this. > In general, I tend to want to favor the server, I think :) 1. Issue DH (or probably ECDH) certificates. > 2. Have a certificate extension that indicates that the certificate can be > used > for offline signatures (following a suggestion by Hugo Krawczyk) > > The general sense of the WG is that while these are both good ideas, ECC > is now > so fast that they can be pursued separately rather than in the critical > path. If you're > interested in working on that, it would be great to get someone on it, so > please > contact me or the chairs offline :) > > > I agree that the speed and size savings are not necessarily worth the > complexity. If we were rolling a new protocol from scratch they probably > would be though. > It's worth noting that it's not just a matter of an existing protocol but also of an existing authentication infrastructure (i.e., widespread RSA and ECDSA signing certs.) Thanks, -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
