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

[Hugo Krawczyk <[e-mail]>]

The issue of validity period of the static key g^s is not different than
that of a regular certificate except that the server can choose a shorter
validity period for g^s than the one for the certificate. That is, if the
client's clock is skewed by Delta and the validity of g^s is up to time T,
the client will accept g^s till time T+Delta. Similarly, if the certificate
expires at time T', the client will accept it until T'+Delta. In either
case, if T<T' the client will accept g^s for less time than it would accept
the certificate.

(Needless to say, a client should not accept a signed g^s past the
expiration date of the certificate signing g^s).

Am I misunderstanding/missing something?

Hugo



On Tue, Nov 4, 2014 at 4:12 PM, Eric Rescorla <[e-mail]> wrote:

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