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

["Dan Harkins" <[e-mail]>]

  Hi Bodo,

On Wed, November 27, 2013 9:09 am, Bodo Moeller wrote:
> 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).

  TLS-pwd does allow for a selection of "named groups". If you look at
the example exchange in appendix A of -02 you'll see that that is how
an elliptic curve is agreed upon (a whole slew of named curves are offered
by the client in the ClientHello and they end up using brainpoolP256r1:
curve_id = 26).

  That said, the issue you bring up remains since it is also possible to
just send the complete domain parameter set. But this is how TLS handles
discrete logarithm-style cryptographic parameter negotiation. So this
issue applies to every TLS cipher suite that provides for some kind of
exchange using discrete logarithm cryptography, including all of the
ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This
"full flexibility" issue sounds more like something for TLSv1.3  than for
TLS-pwd.

  regards,

  Dan.