Re: [TLS] OPTLS: Signature-less TLS 1.3

[Andy Lutomirski <[e-mail]>]

On 10/31/2014 05:54 PM, Hugo Krawczyk wrote:
> During the TLS interim meeting of last week (Oct 22 2014) I suggested
> that TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
> static Diffie-Hellman for authentication. This has multiple benefits
> including
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> option, and a simple extension without signatures for client authentication.

I like this idea a lot.

> Note on certificates: Since in current practice servers hold
> certificates for
> RSA signature keys rather than for static DH keys, the certificate field
> in the
> above protocol will be implemented by a pair consisting of (i) the
> server's RSA
> signature certificate and (ii) the server's signature using this RSA key
> on the
> server's static public DH key g^s. The latter signature by the server is
> performed only when a new static DH key is created (how often this
> happens and
> how many such keys are created is completely up to the server - it has the
> advantage that these keys can be changed often to increase security against
> leaked keys). This use of RSA also enjoys the high efficiency of RSA
> verification for the client. 
> The handling of Client certificates would be similar.

I would like to see one modification of this: I think that the
certificate should be (RSA/ECDSA certificate, server's long-term DH
share, expiration), signed by the cert.  That way any user of a
certificate can sign short-term shares instead of long-term shares,
significantly reducing the impact of a leak.

It would be even better if there were a way to limit one of these things
to a certain host.



That being said, I do have one significant concern with this: what
happens when someone builds a quantum computer?  I don't expect TLS 1.3
to be post-quantum secure, but I would like the road to replacing
primitives for post-quantum security to be reasonably clear.

Unfortunately, I'm not aware of a credible post-quantum DH-like
construction.  On the other hand, post-quantum signatures are
straightforward if rather large right now, and post-quantum public-key
encryption is, as far as I remember, not guaranteed to be a drop-in
replacement for DH.

Will this end up being a problem?

--Andy