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

[Hugo Krawczyk <[e-mail]>]

Regarding the post-quantum question below: Any public key encryption (PKE)
mechanism can be used for PFS, you just need to generate session-specific
private-public key pairs and use them for that session only. So any
quantum-resistant PKE (QR-PKE) scheme can be used for PFS. More
fundamentally, digital signatures do not suffice for key exchange. You need
a  PKE, or similar mechanism, to actually exchange the key (signatures are
only good for authenticating the exchange). Once you have a QR-PKE, you
replace the key g^{xs} in OPTLS with an encryption of a random key under
the server encryption public key and use this random key for computing the
Finished message.

By the way, I am personally more concerned about the possibility of a
significant advance in (classic) ECC cryptanalysis in the near-medium
future than with a practical-enough quantum machine that can break the ECC
cryptography. In particular, progress in quantum will most likely be
gradual and will give us time to prepare the next-generation QR
cryptography while a mathematical break of ECC could happen overnight (or
over several nights :). For all we know, it might have already happened...
(I guess one can say that someone might have already built a quantum
computer but to me that looks much more unlikely).

Hugo


On Fri, Nov 7, 2014 at 4:41 AM, Andy Lutomirski <[e-mail]> wrote:

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