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

[Andy Lutomirski <[e-mail]>]

On Thu, Nov 6, 2014 at 9:45 PM, Watson Ladd <[e-mail]> wrote:
> 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.

Sorry, I wasn't very clear.  My thought is that, if we're going to
introduce a new object signed by the PKIX cert, such that a server
only needs the private key associated with that object and not the
certificate's private key, then we should take advantage of this to
add some features.  In particular, we should let it expire before the
certificate, and I think we should allow it to be pinned to a
particular hostname or maybe set of hostnames.  The former was covered
elsewhere in this thread.  The latter was not.

Also, ha ha ha ha.  We know how to user certs securely.  Yeah, right.

If I buy a cert for *.my.domain, I want to be able to provision
foo.my.domain with some secret that lets it act as foo.my.domain but
not bar.my.domain.  Since the PKIX people seem to be completely unable
to address this, pinning DH shares to a domain would solve the problem
without involving any PKIX changes.

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

The former is a big if, and it makes me nervous to say that, if
someone builds a quantum computer, that TLS 1.2 might be better than
1.3.  And my inner pundit expects NTRU to fail as soon as anyone
pushes it hard.

That being said, this may not be a big deal -- I suspect we'll have
*something* that fits in this framework.

--Andy