[Cfrg] Key establishment advice (say, for TLS): How about MQV?

[Dan Brown <[e-mail]>]

Dear CFRG list,

 

If I understand correctly, the TLS WG plans a protocol revision which will
modify the underlying key establishment scheme.  Should CFRG advise TLS on
key establishment?  

 

Naturally, TLS may have some specific requirements, directed towards the
nature of the client and server in the transport layer, whereas CFRG might
have expertise on a more generic security level.  So, perhaps, TLS could
convey its requirements to CFRG, and CFRG could return a set of key
establishment schemes that meet those requirements, in particular, those
which have been extensively researched.  (Well, that's a bit formal, and
probably requires a few more iterations than I described, but seems sensible
to me.)  More likely, TLS will pick their own key establishment scheme, and
ask for CFRG's blessing. 

 

I haven't followed the TLS list too closely, but I'd summarize two main
possible approaches as: (1) patch and (2) overhaul.  On the overhaul side,
I've seen Watson Ladd's suggestion of signed ephemeral DH: which is
something TLS already has, with the core of the proposal being to narrow the
options drastically.  I've also seen a couple of IACR eprints analyzing the
security of certain TLS ciphersuites.  (Maybe these would go on the patch
side?)  If I recall those papers correctly, they define some special
security models just for TLS, but I forget if these models were chosen just
to make the proofs work for the protocols used in the ciphersuites, or for
something more fundamental like the nature of the transport layer.

 

***

 

I'd like to suggest a key establishment scheme for CFRG consideration: MQV
(or one of its successors, maybe), with an eye to perhaps recommend to IETF
WGs such as TLS.  

 

***

 

Some generic (non-TLS-specific) issues for MQV:

 

Two benefits of MQV over signed ephemeral DH, as I see it, would be
efficiency (though I'm no expert) and better plausible deniability (due to
the lack of signatures).  I wonder what CFRG thinks of these benefits.

 

Existing standards that specify versions of MQV include ANSI X9.{44,63,98},
NIST SP 800-56A, IEEE P1363, and SEC1.  Therefore, it may be redundant for
CFRG to draft on RFC for MQV, although CFRG may wish to write an RFC to
profile the version that they like best.   

 

These standards go towards the maturity of MQV, in the sense that they
received scrutiny from the committees that drafted them, and have been
public for a long time, and have served as an incentive to cryptanalytic
research, being fairly high profile targets.

 

The HMQV paper by Krawczyk critiques MQV, but these critiques did not seem
terribly serious to me, at least when I last read them years ago.  Also, I'm
not sure how other key establishment schemes fare under these more stringent
requirements (session-state reveal attacks, and so on).

 

The version of the MQV from NIST requires identifiers in the KDF, which
helps prevent UKS attacks.  (I'm not sure if TLS needs to resist UKS
attacks, but a recent thread on the TLS reminds of UKS attacks.)

 

I recently released a (rather theoretical and very incomplete) IACR eprint
on MQV.  It only covers a modest, but essential, level of security for key
agreement schemes.  I think other people on the CFRG list are much more up
to speed on the key establishment schemes.  

 

***

 

Some TLS-specific issues for MQV, but at a high level for CFRG
consideration:

 

Past proposals to integrate MQV into TLS a few times include:

 

https://datatracker.ietf.org/doc/search/?name=mqv
<https://datatracker.ietf.org/doc/search/?name=mqv&rfcs=on&activedrafts=on&o
lddrafts=on&sort> &rfcs=on&activedrafts=on&olddrafts=on&sort=

 

Perhaps these could be improved, given current knowledge on key agreement.

 

A major issue is that MQV usually presumes mutual authentication, but TLS
accommodates anonymous clients. Leaving the MQV client "static" key
unauthenticated seems, at least intuitively, to reduce MQV to DH, on the
client side, which is not much of a loss.  It may be possible to have
stateful TLS client retain a static MQV key, but still unauthenticated. This
could be used for the weaker TOFU model of trust, so may still have some
security benefit.

 

If I understand correctly, TLS may now want to add some kind of anonymity,
e.g. encryption of certificates and other identifiers.  Since MQV involves
sending ephemeral key, these could, at the cost of an extra shared key
computation, protect the static (certified or trusted) keys against passive
adversaries.  I'm not sure if the resulting double use of the ephemeral keys
would undermine the security of MQV.

 

Best regards,

 

-        Dan