Re: [Cfrg] 40 bit loop and DragonFly

[Feng Hao <[e-mail]>]

Hi Dan,

On 07/01/2014 08:36, "Dan Harkins" <[e-mail]> wrote:

>
>  Hi Trevor,
>
>  I guess it was just an idle threat then for you to say you would "give
>up participating in IETF/IRTF any further" if Kevin was endorsed through
>an open process (note: he actually was, and that decision has been
>confirmed by the IRTF chair). Oh well..


I am afraid this kind of comment is not helpful; it only creates tension
and animosity. Please, can we limit ourselves to strictly technical
arguments only?

>
>On Mon, January 6, 2014 6:02 pm, Trevor Perrin wrote:
>> On Mon, Jan 6, 2014 at 9:18 AM, Watson Ladd <[e-mail]>
>>wrote:
>>> On Mon, Jan 6, 2014 at 8:46 AM, Igoe, Kevin M. <[e-mail]> wrote:
>>>>
>>>> I believe there aren't any insurmountable issues associated
>>>> with DragonFly, but that doesn't mean Dan and the RG don't
>>>> have some work to do.
>> [...]
>>> Why are we still trying to fix Dragonfly? We've got alternatives that
>>> don't have the
>>> significant theoretical issues, don't have the implementation issues,
>>> don't have the IPR issues
>>> (pith and marrow makes me think Dragonfly is covered by SPEKE patent),
>>> and have been
>>> vetted far more extensively.
>>
>> I share Watson's incredulity that Kevin expects further work on
>> Dragonfly.  As Watson states, there are better alternatives (SPAKE2,
>> J-PAKE, SRP, AugPAKE, and Elligator-based variants).
>>
>> Dan insists that he wants a balanced EC PAKE without patents, so let's
>> talk about SPAKE2 and J-PAKE.  Both have been around for years, have
>> formal security analysis, and are easily implemented without
>> side-channels.
>>
>> Kevin and Dan: please explain why you prefer Dragonfly to these
>>protocols.
>
>  Where did you divine Kevin's preferences from? I have not heard
>or read any statements from him that he prefers dragonfly as a PAKE
>over any other protocol.
>
>  I think SPAKE2 and j-PAKE are great. But for the uses I'm interested in
>right now they are not the best choice. I'm looking for something to
>protect an EST exchange where the group used for the PAKE is the same
>as the group in which the key-to-be-certified was generated in, and I'm
>also looking for something also to allow for small, constrained devices
>in a home network setting to be provisioned by people with no security
>clue so they can securely connect to a local server-- this means ECC
>and it means as simple and idiot-proof a configuration as possible.
>
>  SPAKE2 requires establishment of additional elements in the group that
>are assigned to the players. This increases provisioning cost and requires
>a certain amount of security clue on the part of the person doing the
>provisioning. Dragonfly does not; just configure a simple password on each
>end and voila. In addition, SPAKE2 cannot support different groups on the
>fly so it won't work with the EST need. SPAKE2 does not work for either of
>my two primary uses of Dragonfly.
>
>  J-PAKE does not fit into TLS very well. It has an additional round of
>message exchanging. Dragonfly fits in perfectly, key establishment
>is done entirely in the client/server key exchange messages and
>key confirmation fits into the finished message.


You're correct that J-PAKE needs an extra round. I am not too familiar
with TLS, but I am inclined to think if SRP can be fit into TLS, so can
J-PAKE. From the SRP-6 protocol description, SRP needs 6 passes to
complete the key agreement with explicit key confirmation. For J-PAKE, it
actually only needs 4 passes to do the same. So it looks that fitting
J-PAKE into TLS shouldn't be impossible.

To me, the biggest question is if the TLS community perceives a need for
TLS-JPAKE (or similar).

If not, let us not bother. If yes, I am more than happy to spend time
working it up to an RFC, and I sincerely welcome TLS experts and other
interested parties to contact me (online or offline), so we can write the
document together.

I could see three arguments against TLS-JPAKE: 1) there is already
TLS-SRP; 2) an augmented PAKE should be preferred; 3) TLS-SRP is rarely
used in practice. 

For 1) I don't think the existence of TLS-SRP must exclude other entries.
At the moment, SRP doesn't readily support ECC, which is a practical
limitation. J-PAKE doesn't have this limitation.

For 2) There is one practical advantage with an augmented PAKE (SRP) that
if the server database is compromised, the stolen password verifiers can't
be directly used to allow the thief to authenticate back to the
(compromised) server without first doing an offline password search. (The
scenario is a bit artificial but anyway...) The advantage is actually
limited, as it merely slows down the attack rather than prevents it.
Furthermore, an augmented PAKE is inherently more complex than a balanced
PAKE. One may wonder if the limited advantage justifies the extra
complexity. This is not to argue which one is better, but as you can see,
a balanced and augmented PAKEs present different trade-offs. I think
TLS-SRP and TLS-JPAKE can co-exist, to suit different application
requirements.

For 3), this concerns me most. I can see the benefits of including PAKE
(balanced/augmented) into TLS, but I don't understand why in reality few
people use TLS-SRP. Something is amiss somewhere and it's not clear to me
exactly what and why. This is an important question, as otherwise, we will
be wasting time to work on something no one cares.

In my opinion, a potentially major advantage of TLS-JPAKE is protection
against "phishing attacks", which are currently a big industry problem.
However, that would require a trusted user interface for the user to enter
the password; if the user enters the password in the wrong place, the
security promise of TLS-JPAKE is gone. If the user uses a web browser,
then the log in interface should be tightly built within the web browser
(not the web page), which will be impossible without the active
participation from browser vendors. Not sure if that caused the low-uptake
of TLS-SRP.

Regards,
Feng


>  But even if those were not the case and J-PAKE and/or SPAKE2
>were acceptable, it's because there are no alternatives ready RIGHT
>NOW. As I have explained numerous times to you, this is already late.
>EST was already published and implementations exist. The need for a
>certificate-less TLS cipher suite that supports ECC and does not bind
>a single group to a password is already several months past due.
>
>  Also, I have stated to you earlier that I think EKE with elligator
>curves
>would be perfect. But such a draft doesn't exist. Even if you had a -00
>draft written today we're still looking at 2+ years before it's published
>as an RFC. So that doesn't work.
>
>  Of course, you are more than welcome to write a draft specifying
>any other kind of PAKE you want. You have previously stated that
>you see no need for another PAKE in TLS so doing so would be,
>according to you, a pointless endeavor. But, as we have seen, your
>statements (e.g. "I will give up participating in IETF/IRTF") seem to
>be made primarily for effect. So hopefully your statement against
>any other PAKEs in TLS besides SRP was similarly made just for
>effect and you will be advancing a PAKE draft really soon now.
>
>  I await your draft of J-PAKE or SPAKE2 or anything else you think
>is more appropriate. But, unfortunately, it is not of any use to me
>right now.
>
>  Dan.
>
>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg