Re: [Cfrg] Adoption call for draft-harkins-pkex-05

Richard Barnes <rlb@ipv.sx> Fri, 13 April 2018 01:39 UTC

Return-Path: <rlb@ipv.sx>
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 029B8124205 for <cfrg@ietfa.amsl.com>; Thu, 12 Apr 2018 18:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCz_Q2ijMT5t for <cfrg@ietfa.amsl.com>; Thu, 12 Apr 2018 18:39:23 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE33012D82F for <cfrg@irtf.org>; Thu, 12 Apr 2018 18:38:52 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id 188-v6so7006682oih.8 for <cfrg@irtf.org>; Thu, 12 Apr 2018 18:38:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=leCykkl/KOJ2n4pyM5gclFriRE2nP+RjEM+Sn6bOv6c=; b=gABeezMCD+plQUwpLNpothQBtCOwQvuKXaq2Yqeg0H8p25BZRlx1UCgURp8nb8k79e eTvgkK8firIegqyIJ0GCq36mTg3v5x/dJOwKxjTHuYMUkIHbxt7QEBpqmmn99UZSd9+w rjMf0pyjLHKVYjn5FqiEqGKc4T7PuThHXXkWJ3CS1FH9gM1zrzVwXKiLGygfTU7piUCS w19SGsVLY5VZM2WgC5ajKMDPJ7xu7567I0hOAUCQwnrngYCnzhcE4q5oJXa1TrA2xawf 89iBhYe2K/JUxQMS2TtjVOitq9nulsLuuV7Ecu76j82FYi9fDieOHyo/l6HMnLleF7mr KTzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=leCykkl/KOJ2n4pyM5gclFriRE2nP+RjEM+Sn6bOv6c=; b=SU7KsLX7JcAb6oWdx8kO9jENiDlJ9aSm/z8bdhqDZG7JQn5Z1mgpP9RA1iFmAL0+dq ERLooMMe3KLEWg8OKkxVBcHX5Ma63HWGYHMo0fYjZymVvBoKsQtvfCTxydmkbKgq+v/W f0yrIYfnTUwXnyxV3UCt/9vo0FAhsr92k07oNMSm4gRj2eY3VdAtrRmBmWlWTF9zGf9/ tjEnbmSAeEhNla/T6Y6/wbdXdUIbk1vjLkqVAoyWD0Q9f9VmstatSJNFkFt9Yezrx+8h RhIq5pwdzv7CTZWYNhYHs1mSRc3ZjSaVf286/YIk+2d8LMm5pGUMfgz+9mKgAIgoVBDA quWA==
X-Gm-Message-State: ALQs6tD9+2qAQjBG9GX78E3iOUppq+PdID2SO5LlzN18zy8KOPebRrKa AidyAMzyDdTvrOcc4mWCgqe/vNT8UH9XYhWQLwtu+r+8
X-Google-Smtp-Source: AIpwx48MHfJzQylwUt+li9bMGMpfkQLy+3CZZzqKIJuoIGnkC5DqOrs/Xh9VaUrZoqiBse3hxytMGrZtFfc8C0AtLcE=
X-Received: by 2002:aca:30c6:: with SMTP id w189-v6mr6873185oiw.29.1523583532003; Thu, 12 Apr 2018 18:38:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.90.67 with HTTP; Thu, 12 Apr 2018 18:38:51 -0700 (PDT)
In-Reply-To: <e186b642-7282-3bfe-3da1-f68e4c3b687c@lounge.org>
References: <5ACA0006.4020809@isode.com> <810C31990B57ED40B2062BA10D43FBF501C515B8@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501C5168A@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501C51B18@XMB116CNC.rim.net> <16affdfc-df9a-a883-e0d6-dd52efee15e4@lounge.org> <CAL02cgT72J=cboruKiHnF4BP7ffaDfae=JeoYDJJfjenF4wC8Q@mail.gmail.com> <fe239e8a-0a64-4b8b-7dba-f38fcfcdc4fd@lounge.org> <CAL02cgRy7M8AjQySy=1njavj+cyxPvQe-n1f+N4xVc_GZFwdNA@mail.gmail.com> <90c10953-6550-09d0-642e-e84710b706cf@lounge.org> <CAL02cgTF6E697t+twXwbkrzZ7OHsFPh--W_NaT5-f0VJ=Jo7Tg@mail.gmail.com> <e186b642-7282-3bfe-3da1-f68e4c3b687c@lounge.org>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 12 Apr 2018 21:38:51 -0400
Message-ID: <CAL02cgQc2HJ0bOZzOc1Q9iqX0-E-PN5qYqW6=iWGE3iggdRQUA@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000360b230569b0efd1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/9tdvl-S4SsNjLtkHjERvKLGNeFk>
Subject: Re: [Cfrg] Adoption call for draft-harkins-pkex-05
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2018 01:39:26 -0000

On Thu, Apr 12, 2018 at 7:52 PM, Dan Harkins <dharkins@lounge.org> wrote:

>
>
> On 4/12/18 6:21 AM, Richard Barnes wrote:
> [snip]
>
>
> I guess what I don't understand here is the benefit of conjoining the
> primitives rather than composing them.  It seems like you would get the
> same effects here in the same number of RTTs with a straightforward
> combination of PAKE, sending identities, and a proof-of-possession protocol
> [1], all of which are already well-established.  Instead, you've mushed
> them all together.  That seems like it has some costs, e.g., the
> restriction to ECDSA when with a more composed design you could support
> arbitrary DH or signing keys.  What are the corresponding benefits?
>
>>
>>   I'm not sure where the mashup is. You have basically described PKEX. It
>> does
>> SPAKE2 and then it sends identities and a proof of possession protected
>> by the
>> PAKE shared secret.
>>
>
> What I mean is that in addition to just using the PAKE, you're also
> changing its internals:
>
> - Instead of using the password as input, PKEX hashes in the identities
>
>
>   So? The password is still used. Are you saying this is not SPAKE2
> anymore?
>
> - The key shares from SPAKE2 are re-used for the proof of possession
>
>
>   There needs to be some demonstration that the key is used "live" in the
> exchange
> otherwise you're not really proving possession. In your sketch below
> (which I
> admittedly don't understand 100%) you are introducing yet another
> Diffie-Hellman
> with Eph_A and Eph_B which I guess are used with the private analogs of
> Pub_B
> and Pub_A, respectively, to produce K_DH_B and K_DH_A, respectively.
>
>   I don't see the value of treating the PAKE a closed some black box.
>

The benefits are the typical "don't roll your own crypto" benefits --
generality, code re-use, and analysis re-use.  If you have a general
"insert proof of possession here" slot, you can address keys from any DH
group (even if it can't do SPAKE) or even signing keys.   You can take an
SPAKE implementation that has a "password in, key out" interface and re-use
it.  And when you're trying to prove the properties of the system, you can
treat the "black box" sub-units as things with known properties; you don't
have to worry about whether re-using a key share will undermine some
property.

It seems like you're trading off 1 DH key generation per side (the
incremental cost of the sketch below over PKEX) against a lot of work to
analyze this thing and more difficulty implementing.  I'm just saying that
trade-off doesn't seem like a good deal to me.  (If I were the chairs, I
might consider whether this merits the group's time, given that the can be
solved with existing primitives at not much cost.)  If others feel it is
worthwhile, though, I'm not going to stand in the way.

--Richard



> It already
> has a perfectly good ephemeral Diffie-Hellman share which I am putting to
> good use
> instead of ignoring which necessitates generation of yet another ephemeral
> Diffie-Hellman share.
>
> You're not treating the PAKE as a box that takes a password on one side
> and emits a key on the other side.
>
>
>
>> The limitations are that the two sides have to be exchanging
>> keys from the same group and since they've already agreed on a group for
>> their
>> identity keys then they have to use the same one for the PAKE. Those were
>> not
>> seen as serious issues because such a restriction may already be imposed
>> on the
>> subsequent key exchange protocol (e.g. MQV), and it obviates the need to
>> discuss
>> what it means to exchange, for instance, a p521 public key over a PAKE
>> that uses
>> brainpool256. It cuts down on problematic options. That's the same reason
>> that
>> the hash algorithm and SIV key length are determined by the prime
>> defining the
>> group, less options that might be used poorly means a more robust and
>> idiot-proof
>> protocol.
>>
>
> I'll grant that you do get more rigidity from the conjunction.  But I'm
> not sure that this is more effective than simply expressing the requirement
> in prose.
>
>
>
>>
>>   Also, there is no restriction on ECDSA.
>>
>
> Maybe you should revise this text then :)
>
> """
> Due to the nature of the exchange, only DSA ([DSS]) and ECDSA
>    ([X9.62]) keys can be exchanged with PKEX.
> """
>
>
>   Right, it expressly includes DSA keys.
>
> And maybe add a clearer explanation than "due to the nature of the
> exchange".
>
>
>   OK, good comment. That is overly vague.
>
>   Dan.
>
> --Richard
>
>
>
>> In fact, Appendix A.2 has the SPAKE2
>> role-specific elements for four standard DH groups and the Appendix talks
>> about
>> how to generate role-specific elements for other groups not enumerated.
>>
>> --Richard
>>
>> [1] Sketch:
>>
>> A->B: SPAKE-Kex
>> B->A: SPAKE-Kex, SPAKE-Confirm, {ID_B, Pub_B, Eph_B}K_spake_B
>> A->B: SPAKE-Confirm, {ID_A, Pub_A, Eph_A}K_spake_A, MAC(K_DH_A,
>> transcript}
>> B->A: MAC(K_DH_B, transcript)
>>
>> Note that at this point, it's starting to look simpler just to do TLS!
>>
>>
>>   It's not really. There is running code for this protocol (and not just
>> by
>> me) and it's much simpler than TLS.
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>
>