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

[Hugo Krawczyk <[e-mail]>]

​A few notes on the potential use of HMQV for TLS.

I do believe that HMQV could be a good basis for TLS 3.0 due to its
efficiency,
versatility, and proof of security (I comment a bit on these aspects
below).
But given the patent issues surrounding the protocol I doubt it would be
feasible to get this standardized by the IETF. As I understand, Certicom has
some claims on the MQV protocol and IBM has a patent on HMQV.

HMQV gives an authenticated DH exchange *at essentially the cost of plain
DH*
(plus certificate verification) and can support "seamlessly" several
functional
variants: from implicit mutual or unilateral authentication to explicit
authentication with key confirmation to a single message key exchange with
unilateral or mutual authentication. The latter mode is particularly well
suited
as a one-message key exchange of the type I've seen in some "TLS 3.0"
proposals
(which assume some form of anti-replay state) and has the advantage of
optionally accommodating client authentication almost for free.

The protocol has a proof of security (scrutinized through several hundred
papers
that build upon HMQV) which not only serves to have confidence in the
design but
also avoids the "safety margins" typically needed for not-well-understood
protocols. Very importantly, it avoids the need to rely on the CA to check
the
algebraic properties of public keys (as it is required, for example, by
MQV).
Indeed, such reliance would be a kiss of death to a protocol intended for
wide
use as CA's do not typically do such tests. In particular, it would be
totally
unusable for TLS where a server signs its own HMQV key (and the CA
certifies the
server signature key).

There has been some contention about the need to do group membership tests
in
HMQV. Indeed, the need for this depends on the use case and security model.
However, this issue is relevant for mod p groups where such tests are
expensive.
For elliptic curves the test is inexpensive hence can be made an integral
part
of the protocol.

Finally, for those wondering if UKS attacks should be avoided in TLS. For
many
years I had to work hard to convince people that UKS attacks are real
threats.
The counter-intuitive nature of these attacks is that an attacker can cause
harm
without having to learn the key. Fortunately (or should I say
unfortunately), the
"re-negotiation bug" in TLS is an excellent demonstration of how practical
such an
attack can be. Nothing better than the history of TLS to show that one
better
takes seriously attacks that seem theoretical at first glance.
​

Hugo


On Tue, Mar 4, 2014 at 12:10 PM, Dan Brown <[e-mail]> wrote:

> 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&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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>
>