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

Paul Lambert <> Wed, 17 December 2014 23:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CCCC1A0010 for <>; Wed, 17 Dec 2014 15:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z9UMk23C6vWr for <>; Wed, 17 Dec 2014 15:17:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EEA41A0007 for <>; Wed, 17 Dec 2014 15:17:04 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id sBHNF8IR023899; Wed, 17 Dec 2014 15:16:57 -0800
Received: from ([]) by with ESMTP id 1rb9kr1kt9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Dec 2014 15:16:57 -0800
Received: from ([]) by ([::1]) with mapi; Wed, 17 Dec 2014 15:16:56 -0800
From: Paul Lambert <>
To: Stephen Farrell <>, Yoav Nir <>, Alexey Melnikov <>
Date: Wed, 17 Dec 2014 15:17:02 -0800
Thread-Topic: [Cfrg] Adoption of draft-ladd-spake2 as a RG document
Thread-Index: AdAYXcQrKr3j/+qMREaQ0KMyT5PxGwB8F4JA
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-17_07:2014-12-17,2014-12-17,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412170232
Cc: "" <>
Subject: Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Dec 2014 23:17:07 -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.

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.


]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.
]Cfrg mailing list