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

Andy Lutomirski <> Mon, 15 December 2014 19:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F60A1A87AA for <>; Mon, 15 Dec 2014 11:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a42Kh7SL2uZl for <>; Mon, 15 Dec 2014 11:40:01 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 318211A87BD for <>; Mon, 15 Dec 2014 11:39:22 -0800 (PST)
Received: by with SMTP id f15so10394047lbj.41 for <>; Mon, 15 Dec 2014 11:39:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=m5ydTFw6oVLgORhgONWAh0d5XnF2DQsbLqY05+5FUT8=; b=ehL20QPq9koBbVdctTI8HxUSZQyUnzassqZeVFLytnMVXE4P7i8iu5E/9/m80xs7/M Vu8k+366BQNHGDCAZP+q5ZnKP9Tti8DCSBebUOVXUbQ8e7mTxpubTMh7lnXYR0hDp6GL ZN/9nVvZzBRK+2kY4lrgC5F5VB7IfZ/mXPVMBbJB3y9n4vxEonCzPDqNyKDPYYe+CHSc hTIbPy0hX/MDTEndzxc7SV/KA5VQqFsu5K8X8hmxcAWtgauyG/eibOaRBpviNdayMRz8 6WD3iwV2LtyuZXycmRqYRXUXHHnIwqW/zrkdxpYAbkHq638nXuQciLyEwjlNEPxHwKXA AzlQ==
X-Gm-Message-State: ALoCoQmb2d2Thp7dUlWrmVw7KuQSoxS8DDV8sXBUSdGfb/rjLCwlvffv0x3/fu7jVD/zXncDur1/
X-Received: by with SMTP id bm10mr31172725lbc.74.1418672360668; Mon, 15 Dec 2014 11:39:20 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 15 Dec 2014 11:39:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Andy Lutomirski <>
Date: Mon, 15 Dec 2014 11:39:00 -0800
Message-ID: <>
To: Michael Hamburg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 15 Dec 2014 19:40:03 -0000

On Mon, Dec 15, 2014 at 9:34 AM, Michael Hamburg <> wrote:
>> On Dec 15, 2014, at 3:52 AM, Stephen Farrell <> wrote:
>> 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)
> 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+”?
>> +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.
> 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.

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.