Re: [Cfrg] small editorial error in and question on draft-irtf-cfrg-dragonfly-01 (was: Re: CFRG meeting at IETF 87)

Rene Struik <rstruik.ext@gmail.com> Mon, 29 July 2013 13:40 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BA521F9D2A for <cfrg@ietfa.amsl.com>; Mon, 29 Jul 2013 06:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.759
X-Spam-Level:
X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCo5IZxhEdUu for <cfrg@ietfa.amsl.com>; Mon, 29 Jul 2013 06:40:35 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75F21F9E45 for <cfrg@irtf.org>; Mon, 29 Jul 2013 06:40:29 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id o10so1454867qcv.5 for <cfrg@irtf.org>; Mon, 29 Jul 2013 06:40:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/F3MAVkJTyqSzhCiJukY3Lan6Tv1+KmS6bqKmS1Xzc0=; b=rkWYeCq1dZE0Bbz3brvNvxWcA9DnFtdQOuINi3IWdu1YJFcBNLK1Eg4jjsVeH0zlkN ii8v2brnVNhUtCsSQUACePTxbROlvxRzdBsnkSbllixj9ecF3N0X+nmwCHFwjvxnqVMq UT15ibMq7w582szSTe//b4vBYl/LLGfeh4kJs3hgSFdNYY4/fJhEbMGdhH1vRNEcwREu ph2DS+vBbYylO7UlnO/4D5EWaD7NVQHGCUjQramSUovCkiTwhBkv4FVXkKLbAHxJzKUX FPEmlLqyMAQNYN6TyID3LflWzUr8ibk6Tfrr/25J9A0qGhIpVLw8NHk+jfWcWEac0ZYf BFOw==
X-Received: by 10.49.131.36 with SMTP id oj4mr69874696qeb.51.1375105214339; Mon, 29 Jul 2013 06:40:14 -0700 (PDT)
Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPSA id a8sm22571801qae.11.2013.07.29.06.40.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 06:40:13 -0700 (PDT)
Message-ID: <51F670B8.9070809@gmail.com>
Date: Mon, 29 Jul 2013 09:40:08 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Dan Harkins <dharkins@arubanetworks.com>
References: <CE1B626A.1EBB0%dharkins@arubanetworks.com>
In-Reply-To: <CE1B626A.1EBB0%dharkins@arubanetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] small editorial error in and question on draft-irtf-cfrg-dragonfly-01 (was: Re: CFRG meeting at IETF 87)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 13:40:37 -0000

Hi Dan:

Thanks. Perhaps, it would have some merit generalizing the draft to cover the tls-pwd draft as well (include salt, but also potentially nonces).

Is there any technical benefit for "refreshing" the password-derived base point (PE element) from one password-based scheme invocation to the next? I do not see how, e.g., mixing in nonces or other public parameters would prevent offline dictionary attacks in the event that one somehow learns the ephemeral private key during a protocol run, but perhaps I am missing something or there is another benefit. Down-side is that one has to recompute those base points online, thereby potentially exposing this to side channel attacks.

Best regards, Rene

==

In TLS-pwd the base, which is a function of the salt and the password,
is fixed
throughout the lifetime of the password/parties pair. The nonces passed by
the two
parties are mixed into the "PE element" calculation so that will be
different with
each run of the protocol.

The specification of dragonfly in the draft in question is general and
is intended to also work in a peer-to-peer protocol. It is impossible to
use salt in that case. That said, I think it might be a good idea to add
a section mentioning that if you are instantiating the key exchange in a
protocol that is strictly client-server then the server can salt stored
passwords as long as there's a way in the protocol for the server to tell
the client what the salt is.



On 7/29/2013 3:23 AM, Dan Harkins wrote:
>    Hi Rene,
>
> On 7/26/13 4:05 PM, "Rene Struik" <rstruik.ext@gmail.com>; wrote:
>
>> Hi Dan:
>>
>> I just quickly revisited the "password to point" mapping for elliptic
>> curves in draft-irtf-cfrg-dragonfly-01 (Section 3.2.1) and noticed a
>> small error: the seed is recursively defined. Fortunately, this is easy
>> to fix, as follows:
>>
>> was:
>>
>> base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
>> seed = KDF-n(seed, "Dragonfly Hunting And Pecking")
>>
>>
>> suggested change:
>>
>> base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
>> seed = KDF-n(base, "Dragonfly Hunting And Pecking")
>    Thank you for catching that! I'll include the fix in the next
> revision of the draft.
>
>> On a more general note, with the draft rev1 version, the found point Q is
>> a function of the password itself and the presumed key sharing parties
>> Alice and Bob. In other words, the password-derived generator of the
>> curve "PE Element" is fixed throughout the
>> lifetime of the pair (password, key sharing parties). With
>> draft-harkins-tls-pwd-03, a similar procedure is proposed, but there a
>> "salt" is mixed in as well. Just curious: why the difference?
>> <http://tools.ietf.org/pdf/draft-harkins-tls-pwd-03.pdf>
>    In TLS-pwd the base, which is a function of the salt and the password,
> is fixed
> throughout the lifetime of the password/parties pair. The nonces passed by
> the two
> parties are mixed into the "PE element" calculation so that will be
> different with
> each run of the protocol.
>
>    The reason salt was added to TLS-pwd is because the TLS is a
> client-server
> protocol and there was consensus in the WG that support should be added to
> support the many deployed password databases that salt the password.
>
>    The specification of dragonfly in the draft in question is general and
> is intended to also work in a peer-to-peer protocol. It is impossible to
> use salt in that case. That said, I think it might be a good idea to add
> a section mentioning that if you are instantiating the key exchange in a
> protocol that is strictly client-server then the server can salt stored
> passwords as long as there's a way in the protocol for the server to tell
> the client what the salt is.
>
>    Thanks for your input.
>
>    regards,
>
>    Dan.
>
>> Best regards, Rene
>>
>>
>>
>> On 7/26/2013 5:50 PM, David McGrew wrote:
>>
>>
>> Hi,
>>
>> here is the agenda for our upcoming meeting; we are looking forward to
>> seeing you there.
>>
>> David and Kevin
>>
>> ---
>>
>> Crypto Forum Research Group at IETF 87
>> Monday, July 29, 2013
>> 1510-1610  Afternoon Session II
>> Room: Tiergarten 1/2
>>
>> Agenda Bashing
>>
>> Randomized Hashing (as described in NIST SP-800-106/107) - Quynh Dang
>>
>> Updates on active drafts
>>
>> - OCB Mode of Operation, draft-irtf-cfrg-ocb-03
>>
>> - Dragonfly Key Exchange, draft-irtf-cfrg-dragonfly-01
>>
>> - Hash-Based Signatures, draft-mcgrew-hash-sigs-00
>>
>> "Selection of Future Cryptographic Standards", Sheffer, Grieco, McGrew.
>> draft-mcgrew-standby-cipher-00
>>
>> Discussion on other crypto work
>>   Salsa20
>>   DTLS In Constrained Environments (DICE)
>>   CAESER
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.orghttp://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>> -- 
>> email: rstruik.ext@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363