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

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

On Mon, December 2, 2013 8:40 am, Watson Ladd 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.

  It is difficult to understand how to act on this comment. The specification
is of a cipher suite added to an existing protocol and as such has to
"mix" the
details of the underlying key exchange with the structure and format of the
protocol it is being added to. It is not a high-level description of the
algorithm,
it is a description of how to implement the key exchange as a TLS cipher
suit.

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

  Of course it's a recognizable commitment because it allows the sender
to commit to a particular value (the password) without exposing it to
anyone else.

>> Two final comments:
>> a) It is unclear why one should hard code in the draft that elliptic
>> curves
>> with co-factor h>1 would be ruled out. After all, this would make it
>> much
>> harder to extend the reach of the draft to prime curves with co-factor
>> larger than one and to binary curves.
> I think the authors wanted to specify secure curves and haddn't the
> slightest to do it right.

  (Note: I always like to have my intelligence questioned with a statement
that has multiple grammatical errors).

  As I mentioned to Rene, the reason for limiting the curves to those
over a prime field with a co-factor of 1 is to avoid the patent mine field.

> Weierstrauß form has big problems: Edwards is much better from an
> implementation security
> perspective. Cofactor isn't enough: you also need high embedding
> degree, big discriminant,
> or you could just use curves we agree are good instead of reinventing the
> wheel.
>
> Higher order protocols should be group agnostic.This prevents a major
> problem when
> Joux comes up with something new.

  It specifies a single group for interoperability purposes. It's "crypto
agility" is inherited from TLS.

  Dan.

>> 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.
>>
>> Best regards, Rene
>>
>>
>> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>>>
>>> This is the beginning of the working group last call for
>>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>> TLS-PWD
>>> has been reviewed by the IRTF CFRG group with satisfactory results.
>>> The
>>> document needs particular attention paid to the integration of this
>>> mechanism into the TLS protocol.   Please send comments to the TLS list
>>> by
>>> December 2, 2013.
>>>
>>> - Joe
>>> (For the TLS chairs)
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>> --
>> email: [e-mail] | Skype: rstruik
>> cell: [phone] | US: [phone]
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>