Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

[Watson Ladd <[e-mail]>]

I disagree with the summary of my position.
TlS-SRP is deployed and implemented now. It can be used freely by
everyone, because the patent is freely licensed.
It has been a part of the TLS standard for years.

There are PAKE protocols with security proofs. It is not unreasonable
to demand that a new PAKE meet the standard which existing
protocols have set. A ZKPK on a hash of the temporary Diffie-Hellman
key+the password is perfectly fine, but quite computation heavy.
But for the examined use case computation work isn't a problem:
embedded devices don't handle thousands of connections.

The history of authentication protocols is littered with protocols
believed secure by their creators which were flawed, only for
the flaws to be discovered years later. Wide-Mouth Frog, early
Kerberos, station-to-station protocol, the various Tor key exchanges,
etc. As a result it is reasonable to demand a proof of any new
protocol in this field, especially when once in the standard it will
take years
to remove if a problem is found.

Dragonfly isn't secure in the sense that there exists an algorithm
that carries out an offline guessing attack. I can't provide the
algorithm:
it depends on a bunch of numbers which are the discrete logarithms of
the various PKEs in the terminology of dragonfly. But it exists,
meaning that stating what it means for dragonfly to be secure is
beyond our current knowledge. (Hash functions suffer from this also,
but in practice this can be worked around) In particular, there are
some random oracles for which dragonfly is broken (namely ones which
jigger the point picking process).

Users depend (unwisely, given the history of this WG) on TLS to be
secure above all else. Arguing that the processes previously existing
in the WG has not provided this guarantee is arguing for increased
scrutiny, not less. Adding complexity to TLS has a cost in making
implementations larger and harder to audit, as well as introducing all
sorts of ways to have misconfiguration. We should only introduce
new options when they satisfy usecases existing ones do not.

What does Dragonfly offer over J-PAKE? What does Dragonfly offer over
SRP? Are these benefits worth losing the benefit of security proofs
and years of analysis? And why isn't J-PAKE suitable for your usecase?
Sincerely,
Watson Ladd