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

[Watson Ladd <[e-mail]>]

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]>
> 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 added cost is the cost of one fixed base and one variable base
exponentiation, over the existing ECDHE.
Whether this is enough to recommend making one side sign the
transcript and other DH is a judgement call I can't make.

>
> 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.
2: "Can" is the operative word here. Many people didn't, as we learned
the hard way with heartbleed. The reason for this complex, but part of
the issue is that the spec for using hardware devices is inherently
single-threaded, so making one request per connection starts to get
old real fast. Furthermore, this proposal accommodates having the key
on a single device, no matter how many connections you want to serve,
with no downside. It makes key separation easy.
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.

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

Sincerely,
Watson Ladd
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin