Re: [TLS] RFC 4492 and HSM

[Daniel Kahn Gillmor <[e-mail]>]

On 04/21/2014 09:00 PM, Watson Ladd wrote:

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

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

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

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

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