[TLS] Minor note: static DH key exchange also impacted by KCI attacks

[Dan Brown <[e-mail]>]

The following point about attacks on static DH may be moot because (1)
static DH key exchange is rarely (or never?) used in TLS, especially on the
client side, (2) maybe most hosts do not even have static DH certs to
support these TLS ciphersuites, (3) static DH is already vulnerable to FS
attacks, and (4) static DH is likely to be deprecated in favour of ephemeral
DH (I'm only presuming this, because I haven't been following TLS closely
enough to be sure).

 

Recall that key-compromise impersonation (KCI) means that if Eve learns
Bob's long-term private key, then Eve can use it to impersonate Alice to Bob
(i.e. not just impersonate Bob to anybody else).  Like a forward secrecy
(FS) attack, its pre-requisite is a compromised long-term key, but the
negative consequence is impersonation rather than secret compromise.  Static
DH has long been known not to resist either KCI or FS attacks.

 

The heartbleed bugs suggests that the long-term private key compromise
pre-requisite to both FS and KCI attacks might have been available.  Static
DH usage in TLS may therefore have been affected by KCI or FS attacks.  If a
server lost its static DH private key via heartbleed, then a KCI adversary
may have been able to impersonate client's static DH keys (or re-used
ephemeral DH keys for any server trusting re-used ephemerals as in TOFU).

 

If some similar bug, or something else, ever leaks client static DH private
keys, or re-used ephemeral DH private keys, then such a client may be
affected by a KCI attack in which servers using static DH for authentication
are impersonated.

 

So, KCI attacks give all the more reason (i.e. in addition to FS attacks) to
use key agreement involving ephemeral keys from both sides, and in
particular to deprecate static DH key exchange.  It TLS wants to keep static
DH around, then it should somehow explain or remedy both FS and KCI threats.

 

Authentication via run-time signing prevents KCI attacks, so TLS's [EC]DHE
suites resist KCI attacks.  

 

If TLS wants authentication without signing (say, for better efficiency or
for better off-the-record properties), then it should also be careful to
avoid KCI attacks.  

 

By the way, resistance to FS attacks does not imply resistance to KCI
attacks: for example, the unified model key agreement scheme from SP 800-56A
does not resist KCI attacks. 

 

Best regards,

 


Daniel Brown


Research In Motion Limited