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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 3, 2014 at 7:02 PM, Watson Ladd <[e-mail]> wrote:

> On Sun, Nov 2, 2014 at 2:33 PM, Eric Rescorla <[e-mail]> wrote:
> > On Sun, Nov 2, 2014 at 2:05 PM, Hugo Krawczyk <[e-mail]>>
> 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.
>
> 1: If ephemerals are reused, you can MITM until they are refreshed. A
> time-bounded cert equivalent isn't worse in this regard.
>

I'm not following your reasoning here. For convenience, let's
restrict ourselves to thinking about 1-RTT handshakes. With
TLS 1.2 (or the current TLS 1.3 draft), the server can stop future clients
from accepting any DH share simply by refusing to sign any
further handshakes with that share. If, for instance, it determines
a share has been compromised, it can prevent any new connection
initiations with that share. By contrast, with a time-bounded
cert, an attacker can get clients to continue using that share until
the time expires (or perhaps longer, as you suggested elsewhere).

The situation is of course somewhat more complicated with 0-RTT
because the server must provide the client with a DH share which
he can use for future connections. However, he need not provide
every client with the *same* key, and if the key is authenticated
as part of the initial connection establishment, an attacker cannot
convince other clients to use that key. This is not true with certificates
(or of statically signed keys) which are inherently portable.



3: 0-RTT requires a certificate that can be used for encryption as
> well as signing, in ways that don't interfere. We need to use a DH
> share anyway for this, and might as well use it again.


I'm not sure I follow what you're saying here either. It's true that the
server needs to supply a semi-static DH share, but there's no inherent
reason it needs to be supplied as part of a free-standing transferrable
credential such as a certificate, though of course doing so allows you
to amortize the signature.


> 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.
>
> I'm not sure, because it wasn't explicitly addressed in Hugo's
> original email, but it seems that the relevant server question is how
> long it wants to receive 0-RTT without requiring the client to find
> the new address: I don't remember resumption being addressed one way
> or the other. So the server isn't picking the DH share lifetime for
> reasons of clock skew, but rather for PFS refreshment if 0-RTT is
> being used.


I think we may be talking past each other. Let me try again.

Forget about 0-RTT and just consider the 1-RTT flow. In the first flight
the server needs to supply a signed version of g^s. Unless we want
that value to be acceptable to clients indefinitely, it must have some
validity interval. However, because clients have inaccurate clocks,
that interval can't be too narrow or it will cause clients to reject the
g^s value. I'm not sure how narrow it can be, but I would be surprised
if it were less than 12 hours or so. Perhaps someone who runs a
large server farm can report on the values they have historically
seen in the GMT field of the ClientRandom.

-Ekr