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

[Bodo Moeller <[e-mail]>]

2013/11/19 Bodo Moeller <[e-mail]>

> 2013/11/8 Douglas Stebila <[e-mail]>
>
>> I believe that where possible the IETF should aim to standardize
>> cryptographic protocols that have provable security results.  Such proofs
>> of course don't guarantee the protocol is secure in all scenarios, but at
>> least rule out some classes of attacks.  In the field of password
>> authenticated key exchange, there are many provably secure protocols, and
>> so it would be preferable to see one such protocol adopted.
>
>

> Right.  So there's already an RFC for using SRP in TLS, but it's
> Informational.  Many other such protocols can be found in the research
> literature (and, sometimes, in Internet-Drafts).  If we're picking a
> password-based key exchange for Standards Track, why this one?  What are
> the advantages of this specific protocol over the others?
>
> From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack of
> formal security arguments appears to be that it's presumably less efficient
> than some other such protocols ("hunt-and-peck" loop).
>

Besides the *general* security concerns about this protocol (cursory review
by CFRG doesn't make up for a lack of formal security arguments), here's a
*specific* concern.  (This should be considered "pars pro toto": for all we
know, the protocol could have countless other problems, as isn't uncommon
for cryptographic protocols not justified by format security arguments.)

Given how draft-ietf-tls-pwd-02 specifies negotiation of domain parameters,
I think that a trapdoor-prime attack similar to the one I previously
described for SRP applies (
https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ).
 It makes more sense to standardize domain parameters (allowing a selection
of "named groups").  Full flexibility sounds nice at first, until you
realize that it couldn't only be used by legitimate protocol participants
to select groups that they might deem more secure than whatever is
specified, but could also used by an attacker to select particularly bad
groups (in particular if the scenario doesn't provide for any
authentication other than the password-based authentication the protocol is
meant to provide).

Bodo