On Tue, Nov 24, 2015 at 8:25 AM, Bill Cox <waywardg...@google.com> wrote:
> Much of the world seems to have switched to Schnorr-signature inspired ECC
> signature schemes such as ECDSA-P256 and Ed25519. These schemes are very
> fast, but require two point multiplications to do a Schnorr-style
> verification. A simpler proof-of-possession can be verified with only one
> point multiplication.
>
> The server authentication scheme used in QUIC is for the server to prove
> possession of the static key when it encrypts the new ephemeral key share.
> The trick is to take advantage of the key shares that have already been
> computed. The client has already computed its ephemeral keyshare, and the
> server just uses its static keyshare from the server config. The
> CertificateVerify message could be generated by the server computing the
> ECDHE shared secret between its static secret and the client's ephemeral
> keyshare, and then encrypt of the client random as it's proof. The client
> verifies the proof by decrypting the nonce. As with Schnorr signatures,
> creating the proof takes only one multiply: in this case the server
> multiplies the client's keyshare by it's static keyshare secret. Instead
> of having to do two scalar point multiplications, the client only has to
> multiply the server's static keyshare by its ephemeral keyshare secret.
> The proof is also smaller: 32 bytes vs 72 for ECDSA-P256.
>
This is a sort of complicated question.
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:
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 :)
> This proof-of-possession is not a digital signature, since it can only be
> used to prove to the client that the server possesses the static private
> key. However, I don't see any reason to create a full digital signature.
> Is there any?
>
See above. In addition, because the signature covers the entire handshake
transcript, it provides some defense against downgrade in cases where the
weakest common group is weaker than the server's signing key.
-Ekr
[0] See also:
http://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
