Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

Dan Harkins <> Fri, 30 August 2019 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C235120922 for <>; Fri, 30 Aug 2019 13:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BSjFLhURrw3b for <>; Fri, 30 Aug 2019 13:02:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86AB4120879 for <>; Fri, 30 Aug 2019 13:02:02 -0700 (PDT)
Received: from ( []) by (PMDF V6.8-0 #1001) with ESMTP id <> for; Fri, 30 Aug 2019 15:02:00 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([]) by (PMDF V6.7-x01 #1001) with ESMTPSA id <> for; Fri, 30 Aug 2019 13:01:57 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by ([]) (PreciseMail V3.3); Fri, 30 Aug 2019 13:01:57 -0700
Date: Fri, 30 Aug 2019 13:01:58 -0700
From: Dan Harkins <>
In-reply-to: <>
To: Paul Wouters <>
Cc:, Tero Kivinen <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO Dans-MacBook-Pro.local)
References: <> <> <> <> <> <> <> <> <>
X-PMAS-Software: PreciseMail V3.3 [190830] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Aug 2019 20:02:05 -0000

On 8/30/19 10:51 AM, Paul Wouters wrote:
> On Fri, 30 Aug 2019, Dan Harkins wrote:
>>>  Administrators doing site-to-site VPNs are better of using a true 
>>> random
>>>  strong PSK instead of a weaker PAKE.
>>   Well how many administrators generate a nice string of 256-bits of 
>> "true
>> random strong PSK"? Seriously, if administrators followed such advice 
>> then
>> we would not continually adding another "die" on the "die die die IKEv1"
>> routine we seem to do every 9 months. How many "dies" are we up to now?
> I did not add killing PSKs to that draft, precisely because some
> objected because strong PSK's are stronger than PAKEs.

   Strong PSKs are not stronger than PAKEs. A PAKE will offer you the added
protection of resistance to dictionary attack against the symmetric 
(which could, in fact, be a PSK).

   The definition of dictionary attack is one in which the adversary 
gains an
advantage through computation and not interaction. So even with a strong PSK
you are still susceptible to a dictionary attack since it is the 
protocol that
is susceptible to attack and not the credential. With a strong PSK it just
makes the dictionary attack use much more time to be successful (and yes the
"true random strong PSK" that's 256 bits could make the attack 
infeasible but then managing such a credential is similarly infeasible).

   Think of it this way, if your strong PSK has 64 bits of good randomness
it will take around 2^32 offline computations after A SINGLE ACTIVE 
get a probability of 0.5 of success while if you used that same thing with a
PAKE it would take around 2^32 ACTIVE ATTACKS to get a probability of 0.5.

   What a PAKE allows you to do is retain security even in the presence of a
not-so strong PSK. It does not mean the PAKE is weak. We should not be
standardizing a weak PAKE and I don't think any of the candidates that CFRG
is considering are weak.

   If you can manage a "strong PSK" then using it with a PAKE makes it 
If you can't manage a "strong PSK" then a PAKE still increases security. 
really no reason to use a PSK exchange susceptible to dictionary attack when
something like SPEKE is available.