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

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

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

IMHO, yes.

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

I'd love to see an MQV-like algorithm, with my personal preference being
FHMQV. I'm aware of the fact that X9.63 stays with MQV itself, still I'd
rather see FHMQV. Even though it is unclear (to me) whether the attacks
published against MQV are practical.

My main concern with *MQV is its IPR status. MQV was patented. I don't know
when that patent (those patents?) expires. Also, I don't know whether those
patents would cover HMQV/FHMQV as well (but suspect they would?).

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

:-) That these are benefits worth of having, what else? :-)

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

AFAIK, it has been a tradition at IETF to fully document the
algorithms/protocols it standardizes, rather than just referring to another
standards body. For example, see RFC 6234.

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

Waiting for others to join & comment.

>  Also, I’m not sure how other key establishment schemes fare under these more
> stringent requirements (session-state reveal attacks, and so on).

This should not matter. If we have a better scheme that resists attacks,
which affect other schemes – all the more reasons to adopt the stronger one.

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

If it is possible to adopt a stronger method – I don't see why not.

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

Great!

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

Since *MQV won't become the only mechanism – it shouldn't be a concern:
whoever has client anonymity as a higher priority, will use something else.
Whoever is more concerned of UKS, would use FHMQV. Sounds like a win-win to
me. :-)

TNX!

> ***
> 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&oldd
> rafts=on&sort=