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

[Watson Ladd <[e-mail]>]

On Thu, Nov 6, 2014 at 6:41 PM, 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.

Note that in the above proposal, long-term can be entirely defined by
the server or client as the case may be. I feel I'm missing something
here.

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

The client cert that is? I'm not sure what this gets you: we know how
to use certs securely.

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

If supersingular isogeny volcanoes are secure, it won't be a problem.
NTRU for old TLS is also a possible backup plan.

>
> --Andy
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin