Subject: [TLS] RFC 4492 and HSM

From: Watson Ladd <[email-masked]>
Date: Mon, 21 Apr 2014 18:00:56 -0700

Dear all,
RFC 4492 specifies an ECDSA signature of the server's curve parameters
and ephemeral point, but not any fresh data. As a result the ephemeral
exponent is equal in sensitivity to the long-term exponent of the
ECDSA key, forcing an HSM to protect both, and thus do three
exponentiations per connection.

If an HSM has limited signing power compared to the CPU of the machine
it is attached to this is a real limitation. An extra layer of
indirection, in which a time limited key is signed by the certificate,
avoids this issue, but is not currently supported if I'm reading
everything correctly. Triple-DH handshakes partially mitigate this
issue, reducing the online impact to one exponentiation per
connection.

If this wrinkle doesn't get ironed out I'm not terribly unhappy. But
if we are going to do major surgery on the PRF and related things, the
ECDHE handshake is exposed anyway.

Sincerely,
Watson Ladd

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 22 Apr 2014 00:07:16 -0400

> exponentiations per connection.

It looks to me like RFC 4492 specifies that the data signed includes
both the ClientHello.random and the ServerHello.random:

 https://tools.ietf.org/html/rfc4492#page-20

fwiw the traditional discrete-log-based DHE key exchange includes the
same data in the signature:

  https://tools.ietf.org/html/rfc5246#page-52

I would consider this "fresh data", particularly the inclusion of the
ClientHello.random.

I agree that if there were no fresh data, then every single ephemeral
key used would be equivalent to the server's static public key for reuse
by an active attacker, which seems like it would a problem (especially
given any attacker's ability to trivially harvest new signatures over
novel ephemeral keys).

> issue, reducing the online impact to one exponentiation per

if the ClientHello.random isn't enough protection for you, how are you
proposing that the key be time-limited?  are we assuming some minimal
clock skew?  Would stuffing a timestamp in the SignedParams satisfy your
concern?  What guidelines would we suggest for a client for deciding
whether to accept or reject the timestamp?   inclusion of a timestamp
raises similar concerns about fingerprinting as discussed in:

https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00#section-1.3

Do you see other ways to mitigate those concerns?

> ECDHE handshake is exposed anyway.

I think the triple-DH handshake has some very nice properties in
general, by avoiding any sort of non-repudiable signature; i'm not
convinced that we need to make that radical a change for TLS 1.3, but
i'm open to the argument.

	--dkg

---

From: Watson Ladd <[email-masked]>
Date: Mon, 21 Apr 2014 21:09:45 -0700

>  https://tools.ietf.org/html/rfc4492#page-20

This is correct. I was confused because section 2.2 says the
parameters are signed, but doesn't mention the fresh data.
Ignore previous email.

Sincerely,
Watson Ladd

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