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

[Robert Ransom <[e-mail]>]

On 12/2/13, Watson Ladd <[e-mail]> wrote:
> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik <[e-mail]> wrote:
>> Dear colleagues:
>>
>> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work that
>> went into this draft, I have to concur with some other commenters (e.g.,
>> Doug Stebila, Bodo Moeller) that it is unclear what makes this protocol
>> special compared to other contenders, both in terms of performance and
>> detailed cryptanalysis. One glaring omission is detailed security
>> evidence,
>> which is currently lacking (cross-referencing some other standards that
>> have
>> specified the protocol does not by itself imply the protocol is therefore
>> secure). I am kind of curious what technical advantages the "Dragonfly"
>> protocol has over protocols that seem to have efficiency, detailed and
>> crypto community reviewed evidence, such as, e.g., AugPAKE (which is
>> another
>> TLS-aimed draft) and others. So, if the TLS WG has considered a feature
>> comparison, that would be good to share.
>>
>> I would recommend to ask CFRG to carefully review the corresponding
>> irtf-dragonfly-02 document (to my knowledge, there has been no LC and it
>> is
>> still a draft document there) and align the TLS document
>> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
>> (currently, there are some security-relevant differences). This time
>> window
>> could also be used for firming up security rationale, thus aleviating
>> concerns on that front.
> I do not like the way this standard mixes algorithmic details with
> instantiation
> details. It makes it hard for me to understand what the protocol actually
> is.
> I also do not understand why H needs to be a random oracle as opposed to
> something we have in the standard model.
>
> I also do not like the language of "commitment" used. What is sent is
> not a Pedersen commitment or any other recognizable commitment.
> It is very malleable in ways that make me question the informal security
> analysis.

I don't see what advantage their ‘committment’ [sic] provides over
using standard Diffie-Hellman with a password-derived secret
basepoint.  All of the protocol's security against offline attacks and
impersonation appears to be provided by requiring that both parties'
group elements are in the prime-order subgroup.


>> b) The probabilistic nature of the "hunting and pecking" procedure may be
>> a
>> recipe for triggering implementation attacks. Wouldn't one be much better
>> off removing dependency on non-deterministic password-to-point mappings
>> (e.g., AugPAKE, Icart map, German BSI-password protocol)?
> Well, one could use Elligator to solve this problem.

The Elligator paper (published in August) cites a PAKE paper from 2001
as a possible use for injective maps.  The J-PAKE paper (published in
2008) states that there were no good unpatented PAKE protocols
available at the time J-PAKE was published, and even the patented
protocols were not secure.  Is this protocol related to the 2001
protocol, is that protocol patented, and if so, does that patent cover
this protocol?


Robert Ransom