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

[Eric Rescorla <[e-mail]>]

On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <[e-mail]>
wrote:
> These are good questions as they point to some of the choices we need to
> consider before defining the actual key derivation mechanisms in the
protocol.
> Below are some responses.

Thanks for your explanations.


> On Sat, Nov 1, 2014 at 3:44 AM, Eric Rescorla <[e-mail]> wrote:
> >
> > 3. WRT client auth, I think we've generally decided that the client's
> > certificate ought to be encrypted. Given that, I wonder if it would be
easier
> > for the client to just do a digital signature over the transcript and/or
> > an authenticator derived from the secret. Generally, the additional
> > cost of the RSA signature isn't a huge problem for most clients and
> > those which do should be able to quickly move to EC-based keys.
>
>
> ​I don't see the advantage of signatures in this case. It is possible to
design a
> hybrid protocol with signature authentication at the client side and
static DH
> at the server but I wouldn't do that without a clear advantage over the
more
> uniform approach using static DH on both sides. In any case, doing static
DH at
> the client should not be a problem, it is already doing it to
authenticate the
> server and compute keys.


Thinking this through some more, if the client is doing certificate
authentication, it is already provisioned with a long-term signature
key and the corresponding certificate.  In order to do static DH for
authentication, it must either:

- Generate a new "static" DH key on the fly and sign it.
- Have some long-term storage where it stuffs the static DH key and
  its signature.

The first option is obviously more computationally expensive than not
doing so (though as I said above, not dramatically so if you are doing
EC). As you suggest, this isn't an issue for servers since they are
doing a lot of handshakes and can amortize the computation. However,
because the client may be slow but not do a lot of exchanges, it may
be an issue for clients.

The second option may be trivial, if the client already has some
generic key storage mechanism (e.g., one in software) though it's of
course more work for the programmer. However, if the client has a
non-generic key storage mechanism, such as a smart card with their
key, then this becomes a significant problem, as it may not be able to
store a DH key and/or use it for the kind of key derivation that
would be required here. In that case, the client must find somewhere
to store the DH key, which may entail significant effort.


This last point points us to a larger issue we need to consider here,
which is as follows. In TLS as it currently stands (both in 1.2 and
the current TLS 1.3 draft), you can implement a system where the
authentication keys are stored in hardware and an attacker who
compromises either the client and the server cannot steal a credential
which he can then use to establish new sessions [Note that if
he steals the session cache, he can use it to resume old sessions.]
In particular, because each signature is tied to a specific exchange,
the attacker cannot reuse signed ephemeral values to impersonate the
server.

However, in a system where the server signs a long-term DH value, it
may be the case that that value cannot be stored in the same hardware
module that you are using for your signature key (purely for
implementation reasons having to do with the interface the module
exposes). In that case, the DH secret will be stored in software and
compromise of the server potentially leaks a credential which can be
used to impersonate the server for a significant period of time, where
that time is dictated by the maximum amount of client-side clock error
the server is willing to tolerate, so probably measured in days to
weeks (and more if you are concerned about the time resetting attack
Watson, Ilari, and I were discussing.) I haven't decided yet sure how
serious an issue this is, but it's probably worth addressing
explicitly.

-Ekr