Subject: [Cfrg] Adoption of draft-ladd-spake2 as a RG document

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Dec 2014 16:41:54 +0000

Hi,
This message starts 3 weeks adoption call for draft-ladd-spake2. Please reply to this message or directly to CFRG chairs, stating one of the following

1) that you are happy to adopt the draft as a starting point
2) that you are not happy to adopt this draft
or
3) that you think the document needs more work before the RG should consider adopting it

While detailed document reviews are generally welcome, this not a call to provide detailed comments on the document.

Alexey,
On bahalf of CFRG chairs.

---

From: Rene Struik <[email-masked]>
Date: Sun, 14 Dec 2014 17:27:49 -0500

Dear Alexey:

I am unhappy with this draft. Besides, I do not understand at all why 
the CFRG co-Chairs choose to take this step (call for adoption of this 
draft, at this specific moment in time) right now. What triggered this? 
This seems to be a random move, at a random moment in time.

I think it would be good if the CFRG leadership could explain its thinking.

Best regards, Rene

    Charter

TheCrypto Forum Research Group(CFRG <https://irtf.org/cfrg>) is a 
general forum for discussing and reviewing uses of cryptographic 
mechanisms, both for network security in general and for theIETF 
<http://ietf.org/>in particular.

TheCFRG <https://irtf.org/cfrg>serves as a bridge between theory and 
practice, bringing new cryptographic techniques to the Internet 
community and promoting an understanding of the use and applicability of 
these mechanisms via Informational RFCs (in the tradition of, e.g.,RFC 
1321 <http://wiki.tools.ietf.org/html/rfc1321>(MD5) andRFC 2104 
<http://wiki.tools.ietf.org/html/rfc2104>(HMAC). Our goal is to provide 
a forum for discussing and analyzing general cryptographic aspects of 
security protocols, and to offer guidance on the use of emerging 
mechanisms and new uses of existing mechanisms.IETF 
<http://ietf.org/>working groups developing protocols that include 
cryptographic elements are welcome to bring questions concerning the 
protocols to theCFRG <https://irtf.org/cfrg>for advice.

Rene

On 12/14/2014 11:41 AM, Alexey Melnikov wrote:
> Hi,
> This message starts 3 weeks adoption call for draft-ladd-spake2. 
> Please reply to this message or directly to CFRG chairs, stating one 
> of the following
>
> While detailed document reviews are generally welcome, this not a call 
> to provide detailed comments on the document.
>
> Alexey,
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Watson Ladd <[email-masked]>
Date: Sun, 14 Dec 2014 14:38:14 -0800

On Sun, Dec 14, 2014 at 2:27 PM, Rene Struik <[email-masked]> wrote:
> Dear Alexey:
>
> I am unhappy with this draft. Besides, I do not understand at all why the
> CFRG co-Chairs choose to take this step (call for adoption of this draft, at
> this specific moment in time) right now. What triggered this? This seems to
> be a random move, at a random moment in time.

> The Crypto Forum Research Group (CFRG) is a general forum for discussing and
> reviewing uses of cryptographic mechanisms, both for network security in
> general and for the IETF in particular.
>
> The CFRG serves as a bridge between theory and practice, bringing new
> cryptographic techniques to the Internet community and promoting an
> understanding of the use and applicability of these mechanisms via
> Informational RFCs (in the tradition of, e.g., RFC 1321 (MD5) and RFC 2104
> (HMAC). Our goal is to provide a forum for discussing and analyzing general
> cryptographic aspects of security protocols, and to offer guidance on the
> use of emerging mechanisms and new uses of existing mechanisms. IETF working
> groups developing protocols that include cryptographic elements are welcome
> to bring questions concerning the protocols to the CFRG for advice.
>
>
>
> Rene
>
>
>
> This message starts 3 weeks adoption call for draft-ladd-spake2. Please
> reply to this message or directly to CFRG chairs, stating one of the
> following
>
> While detailed document reviews are generally welcome, this not a call to
> provide detailed comments on the document.
>
> Alexey,

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Watson Ladd <[email-masked]>
Date: Sun, 14 Dec 2014 14:42:30 -0800

My apologies for the truncated reply.

>> be a random move, at a random moment in time.

This is option 2, correct? You don't think we need another PAKE, at
all. Or is this Option 3: you think it is too immature to adopt as a
work item today?

This is in accordance with a previous plan, once it became clear that
there was a shortage of PAKE proposals that could be used with ECC and
that had security analyses. Dragonfly has been contentious precisely
because of it's 1990's style design: a heuristic modification to avoid
certain attacks The hope is that by using an already published design,
we will have a more secure protocol.

Sincerely,
Watson Ladd

---

From: David Leon Gil <[email-masked]>
Date: Sun, 14 Dec 2014 17:23:34 -0800

> 1) that you are happy to adopt the draft as a starting point

I am happy for draft-ladd-spake2 to be adopted as a starting point for
discussion.

(I do not have any firm view on whether SPAKE2 should be recommended
by the CFRG, but the draft is concise and clear enough that it will be
useful to discuss it.)

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Dec 2014 11:05:14 +0000

Hi Rene,

On 14/12/2014 22:27, Rene Struik wrote:
> Dear Alexey:
>
> I am unhappy with this draft.
A one sentence summary of why you think it should not be accepted as a 
RG document (as opposed to being accepted and then fixed up later) would 
be appreciated.
> Besides, I do not understand at all why the CFRG co-Chairs choose to 
> take this step (call for adoption of this draft, at this specific 
> moment in time) right now. What triggered this? This seems to be a 
> random move, at a random moment in time.
Chairs have a backlog of non EC related stuff to go through. While some 
of it has to be dealt with serially, other things can progress in 
parallel. I was already on record saying that Watson's earlier request 
to accept the document was recorded 
(https://www.ietf.org/mail-archive/web/cfrg/current/msg05250.html) and I 
wanted to deal with it. Maybe timing of my email was not perfect because 
of the ongoing EC discussion, but timing is *never* right in CFRG...

Best Regards,
Alexey
> community and promoting an understanding of the use and applicability 
> of these mechanisms via Informational RFCs (in the tradition of, 
> e.g.,RFC 1321 <http://wiki.tools.ietf.org/html/rfc1321>(MD5) andRFC 
> 2104 <http://wiki.tools.ietf.org/html/rfc2104>(HMAC). Our goal is to 
> provide a forum for discussing and analyzing general cryptographic 
> aspects of security protocols, and to offer guidance on the use of 
> emerging mechanisms and new uses of existing mechanisms.IETF 
>> While detailed document reviews are generally welcome, this not a 
>> call to provide detailed comments on the document.
>>
>> Alexey,

---

From: Yoav Nir <[email-masked]>
Date: Mon, 15 Dec 2014 13:16:22 +0200

> On Dec 14, 2014, at 6:41 PM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi,

Definitely not (3), as I think the document is in fine enough a shape to be adopted, despite it needing a lot of work.

But I would really like to know who needs a PAKE right now. PAKEs require the server to store the cleartext password or a password equivalent, creating a security issue that is potentially worse than sending cleartext passwords through authenticated channels (as in form-based or basic authentication to a TLS-protected server)

So, yes, there’s a framework for PAKEs in IKE, and one can be created for TLS, and an EAP method with a PAKE could also be used in a number of places, but all those things get little use. So without comparing the merits of SPAKE2 to the previous PAKE that got discussed in this working group, who is the “customer” for any PAKE?

Yoav

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Dec 2014 11:40:20 +0000

Hi David,

> I am happy for draft-ladd-spake2 to be adopted as a starting point for
Thank you for your feedback.
> by the CFRG,
This is definitely not a call to discuss whether SPAKE2 should be 
recommended, this is only a call to discuss whether it should be documented.
> but the draft is concise and clear enough that it will be
> useful to discuss it.)

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Dec 2014 11:52:56 +0000

On 15/12/14 11:16, Yoav Nir wrote:
> But I would really like to know who needs a PAKE right now. PAKEs
> require the server to store the cleartext password or a password
> equivalent, creating a security issue that is potentially worse than
> sending cleartext passwords through authenticated channels (as in
> form-based or basic authentication to a TLS-protected server)

+many - PAKEs are IMO cool but mostly-useless crypto for exactly
this reason (and before others disagree, yes, I know some folks
disagree:-) If however, CFRG folk want to work on 'em I've no
objection but just so you all know, there is no horde of IETFers
waiting with bated breath for more PAKE protocol options.

There are to be fair a quite small number of sensible people who
do figure there's a niche there to fill though (Dan H. for example
but not sure who else), so I could of course be wrong about that.
As I understand it, the niche Dan has in mind is for signing up
to get a certificate in a PKI, where the password is used to
authenticate the certificate request. Even in that case, I'm
not convinced that PAKEs add value - esp since a one (or limited)
time use password could be better there and requires no new
crypto.

It's also fair to say that the IETF hasn't ever done any kind of
generic consensus call on the (lack of) value of PAKEs, and the
IETF does have a history of adding PAKE options to protocols, (for
some to me unfathomable reason:-) so the above is just my personal
opinion.

S.

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 15 Dec 2014 09:34:17 -0800

> On Dec 15, 2014, at 3:52 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

It is definitely a disadvantage of the SPAKE2 draft as currently written that it does not support augmentation, which would allow the server to store a non-password-equivalent token.  Perhaps this part of the feedback would best be expressed as “there should be an augmented option in the draft, such as PAKE2+”?

> time use password could be better there and requires no new

PAKEs are definitely a niche technology, but they are occasionally useful.  For example, they would be handy to protect WiFi, and possibly to add a layer of protection to protocols like SSH and IMAP which are often accessed with a password.

> some to me unfathomable reason:-) so the above is just my personal

Cheers,
— Mike

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 15 Dec 2014 10:19:50 -0800 (PST)

Hello,

> 3) that you think the document needs more work before the RG should

  I'm in favor of another PAKE being documented but I'm not sure
why SPAKE2 is the one.

> provide detailed comments on the document.

  SPAKE2 seems to be the Dual_EC_DRBG of PAKEs (and I'm very surprised
the author isn't being accused by a bunch of people on twitter, and some
hack tech blogger, of being an NSA plant out to subvert the Internet). There
are 2 constant elements used in the calculation and knowledge of the scalar
used to generate either of them would allow an attacker to break the
exchange. This draft will need to go through a rigorous NUMS procedure in
order to populate (the currently empty) section 3, a contentious step that
other PAKEs would not need to go through.

  There are other PAKEs out there so it would be nice to know why SPAKE2
is the one that should be pursued.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 15 Dec 2014 10:47:20 -0800

> other PAKEs would not need to go through.

Google has deployed this protocol with parameters generated by the
following code:
http://src.chromium.org/viewvc/chrome/trunk/src/crypto/p224_spake.cc

Do you see any way in which the discrete logarithm could be determined
from this or any other substantially similar procedure? If so, please
provide the procedure to this list, give us a week or two to think
about it, and then reveal the logarithm of the generated points.

> is the one that should be pursued.

I understand there is an AugPAKE draft already. But AugPAKE is
patented. There are alternatives, and I'm not committed to the
particular choice of PAKE: I've been informed of a few others to look
at and am examining them to see if they offer any advantages to
switch. I do think we need a PAKE with a solid security proof, and
several people have placed augmentation on the list of desiderata.

Sincerely,
Watson Ladd

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 15 Dec 2014 10:55:32 -0800 (PST)

On Mon, December 15, 2014 3:16 am, Yoav Nir wrote:
[snip]
> But I would really like to know who needs a PAKE right now. PAKEs require
> the server to store the cleartext password or a password equivalent,
> creating a security issue that is potentially worse than sending cleartext
> passwords through authenticated channels (as in form-based or basic
> authentication to a TLS-protected server)

  Augmented PAKEs do not require a cleartext password. And any
scheme that sent a cleartext password over a TLS connection would
also require "the server to store the cleartext password" so it's not clear
how using a PAKE is "potentially worse".

  The need is illustrated by the fact that the "do not verify server
certificate" or "continue with exchange, I know what I'm doing" check
box exists. In other words, its needed because an authenticated
channel is not a given. Another need can be described by the ever
popular "Use your Facebook credentials to log in", how many people
do you think do? Also, passwords are simple to use and TLS is very
convenient but the world is not all browsers. Furthermore, in the
scheme you are describing there is no guarantee that cleartext
password verification is done on the same box that terminates TLS,
providing another potential for problems.

  Security should be easy to use correctly and hard to use incorrectly.
PAKEs are misuse resistant and they make it hard to use passwords
incorrectly.

  regards,

  Dan.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 15 Dec 2014 14:02:01 -0500

On Mon, December 15, 2014 1:55 pm, Dan Harkins wrote:
>> require

Actually, no, the server can store the (salted) hash of the password, so
the cleartext password is only available to the server during the time it
takes to generate the (salted) hash and verify it against storage.  So I
would argue that your statement "any scheme..." is clearly incorrect.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 15 Dec 2014 11:26:01 -0800 (PST)

On Mon, December 15, 2014 10:47 am, Watson Ladd wrote:
>>> to

  A very rudimentary hunting-and-pecking loop!

> about it, and then reveal the logarithm of the generated points.

  Well there's baby step giant step but I'm not going to be revealing the
scalars in a week or two. But then I am not a tinfoil hat conspiracist
(like the aforementioned twitter army and hack tech blogger) either so
I don't actually think a secret cabal knows the scalars, only pointing
out that more has been made over less and if SPAKE2 is pursued the
draft will have to address this issue.

  So instead of populating section 3 with Ms and Ns for various groups
you could describe a hunting-and-pecking loop with a constant seed
(or deterministic way to get a seed for a particular named group). But
again, this is unnecessary if you choose a different PAKE.

> several people have placed augmentation on the list of desiderata.

  Wouldn't RFC 2945 satisfy those people?

  regards,

  Dan.

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 15 Dec 2014 11:39:00 -0800

> PAKEs are definitely a niche technology, but they are occasionally useful.  For example, they would be handy to protect WiFi, and possibly to add a layer of protection to protocols like SSH and IMA…

IMO essentially all password-protected crypto tokens (chip-and-PIN
cards, etc) should be using PAKEs to protect the PIN.  Otherwise if
you sniff a valid transaction between the keypad and the token, you
can very easily brute-force the PIN.

Admittedly, the usual threat models probably don't distinguish such
attacks from attacks that directly compromise the keypad, but I bet
that it's easy to sniff enough of the transaction from RF leakage to
do the same thing if you can put some malicious device near the
keypad, even if you haven't compromised the keypad or token and both
have perfect internal side-channel countermeasures.

--Andy

---

From: Paul Lambert <[email-masked]>
Date: Wed, 17 Dec 2014 15:17:02 -0800

]
]On 15/12/14 11:16, Yoav Nir wrote:
]> But I would really like to know who needs a PAKE right now. PAKEs
]> require the server to store the cleartext password or a password
]> equivalent, creating a security issue that is potentially worse than
]> sending cleartext passwords through authenticated channels (as in
]> form-based or basic authentication to a TLS-protected server)
]
]+many - PAKEs are IMO cool but mostly-useless crypto for exactly
]this reason (and before others disagree, yes, I know some folks
]disagree:-) If however, CFRG folk want to work on 'em I've no objection
]but just so you all know, there is no horde of IETFers waiting with
]bated breath for more PAKE protocol options.

Yes there is ... The Wi-Fi industry needs a stable, open and broadly published version of the SAE protocol.  Approval of the previously discussed draft-irtf-cfrg-dragonfly-05 would meet this need. Yes, it's not favored by some for the perceptions associated with the difficulty of construction of mathematically proof's for the protocols.  Yes, Dragonfly is on a track to get wired into products and it would be very nice to have an open, concise and free (versus IEEE 802) specification of this one type of PAKE.

While more stylish and acceptable by mathematicians, I see little value in SPAKE2.  In this context I agree with your comment.  There is not a good reason to create new applications of PAKE.  There are better systems solutions where effort would be better spent.

Paul

]
]There are to be fair a quite small number of sensible people who do
]figure there's a niche there to fill though (Dan H. for example but not
]sure who else), so I could of course be wrong about that.
]As I understand it, the niche Dan has in mind is for signing up to get a
]certificate in a PKI, where the password is used to authenticate the
]certificate request. Even in that case, I'm not convinced that PAKEs add
]value - esp since a one (or limited) time use password could be better
]there and requires no new crypto.
]
]It's also fair to say that the IETF hasn't ever done any kind of generic
]consensus call on the (lack of) value of PAKEs, and the IETF does have a
]history of adding PAKE options to protocols, (for some to me
]unfathomable reason:-) so the above is just my personal opinion.
]
]S.
]
]_______________________________________________
]Cfrg mailing list
][email-masked]
]http://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Dec 2014 17:49:21 -0800

> Yes there is ... The Wi-Fi industry needs a stable, open and broadly published version of the SAE protocol.  Approval of the previously discussed draft-irtf-cfrg-dragonfly-05 would meet this need.…

I don't want to open up a dead horse, but:

Why can't the Wifi alliance publish it's own spec? Anyone implementing
Wifi has to pay for specs for the rest: not clear to me why this is
that special, or why we are the goto group for publishing this. This
doesn't seem to be a relevant consideration for us, since we deal with
IETF protocols.  Furthermore, draft-irtf-cfrg-dragonfly-05 went
through last call a few months ago: it's no longer an issue, and I
don't see why this draft has anything to do with that draft.

> While more stylish and acceptable by mathematicians, I see little value in SPAKE2.  In this context I agree with your comment.  There is not a good reason to create new applications of PAKE.  There…

So, we're going to get rid of passwords in five years for the nth time?

The effort of publishing does nothing to solve problems: implementing
does. But when the only PAKE that works over ECC that is
standardized/in an RFC, isn't very well understood, implementors will
reach for it instead of potentially more analysed schemes. Insofar as
we need a PAKE, it would be a good idea to get one in which we have
confidence in the security. It's true that PAKEs have seen limited
adoption compared to plain passwords, but there are many applications
outside of the realm of IETF protocols that have used them.

Furthermore, there is an augmented variant Dan Boneh calls PAKE2+. I
am going to track it down, and it will partially resolve the issue of
servers storing password equivalents. Currently there is no good
reference for it.

Sincerely,
Watson Ladd