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

[Eric Rescorla <[e-mail]>]

On Wed, Nov 5, 2014 at 8:27 AM, Hugo Krawczyk <[e-mail]>
wrote:

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

I'm not sure.

The point I was trying to make below is that there are settings in which the
signing key is stored in an HSM but the DH share cannot. In those cases,
there is an additional risk of compromise of the machine holding the DH
share, which can steal the share but cannot steal the signing key
(because of the HSM). I agree that this is partially ameliorated by
having g^s be only valid up to the expiry of the certificate, but since
certificate lifetimes are generally long, only partially so, especially
since
if the signing key is online (as will be required for TLS 1.2 compat)
compromise of the machine will let you sign a DH share with a very
long lifetime.

is that clearer?

-Ekr


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