Re: [Lurk] Issue with draft-mglt-lurk-tls12-01

Daniel Migault <daniel.migault@ericsson.com> Tue, 23 July 2019 02:31 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C58F120047 for <lurk@ietfa.amsl.com>; Mon, 22 Jul 2019 19:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.558
X-Spam-Level:
X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 ZP9GQZHBBNkM for <lurk@ietfa.amsl.com>; Mon, 22 Jul 2019 19:31:07 -0700 (PDT)
Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (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 A1109120091 for <lurk@ietf.org>; Mon, 22 Jul 2019 19:31:07 -0700 (PDT)
Received: by mail-ua1-f53.google.com with SMTP id j2so16292540uaq.5 for <lurk@ietf.org>; Mon, 22 Jul 2019 19:31:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OFFi7pjBrELl3NJdnM9YmdmXsepJIFjHHGIPLFxwcpk=; b=MUSJ/ZCcqTvA54g55FKGrda6Ni5KKBEW4FC4oTb+dxRnWKE7+N842x4ZWNQupexJ9h 6IyshEs9U2WOQCWEv0q0B4uSRlW1Jc0kGhiidDWqLEWymgUfdAgViGHp6V/wvfa4b8yn yq0on8lSREL9mCIdMTFsdmJwJIfpmvIApu06SAuyPn7K1SupgiWoYJPBaCdqibfzkluo UIi4tzNL+x4LUX57HNkM5LuMVU5PRStohmTflYTmlXGv9MwKWYWZurVILvDhW/smV+c7 9PhdbPuW915FyiNN+WeaQPDZyrbNnN1+qXA0MOrnG51qyB07hTo8g1tLcCLFUzGPYwql A9qA==
X-Gm-Message-State: APjAAAUxbmFp2KmxMy2m56AFJ1k/eucIGqzenb/9/Mzp72rAvyCISlnn RKiwFhzvb8WaefThfovlZxezJekELen4+vZV5No=
X-Google-Smtp-Source: APXvYqzXYYJDaPduvg+pNBvANMUCjvxwBCClUNiHJ1nete+IrM9lceAOYLg5OxeBeieeWJ6FzPW15B3vzpQ9aUbZBag=
X-Received: by 2002:a9f:2e0e:: with SMTP id t14mr28684713uaj.119.1563849066731; Mon, 22 Jul 2019 19:31:06 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB38718A55BB9A81A752A9CB77C1C40@MN2PR11MB3871.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB38718A55BB9A81A752A9CB77C1C40@MN2PR11MB3871.namprd11.prod.outlook.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Mon, 22 Jul 2019 22:30:55 -0400
Message-ID: <CADZyTknmz0Q2RjHviH7=GqXvayyzqV=tmJ4qQuOhyVfaMGDm9g@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: "lurk@ietf.org" <lurk@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001adbe1058e4ffcd9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/hoqy1fEKy-evMkkM9XDgIaeSK_o>
Subject: Re: [Lurk] Issue with draft-mglt-lurk-tls12-01
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 02:31:10 -0000

Thanks Scott for the feed back, that is very well appreciated.

I agree that having a proof that is actually a proof is definitively
better, especially when that seems feasible. We could however argue that bG
is an ephemeral secret and at that time is only know to the client and
server, but let's do not take that path.

The previous scheme was derived from a scheme where c is chosen by the
server. In our scheme, c was not derived by the server but simply out of
the control of the client for a given exchange (base). In fact, c is
derived from base that includes the TLS randoms, and so this was believed
to prevent the generation of a proof for bG that woudl not be a public key
for a given TLS exchange. In the scheme you propose, everything is derived
r which is completely under the control of the client. I just want to check
that this does not provide some facilities to the client to generate a
proof for bG that may not be a key. I am happy to change the proof scheme
to what you propose.

A second question I would have is how do we perform the check with X25519
X448.
* do we need to check bH(R)G + R as well as  bH(R)G - R and consider it
correct if one matches.
* I suppose that r is clamed, but I am wondering if that is sufficient.

Yours,
Daniel

On Mon, Jul 22, 2019 at 11:43 AM Scott Fluhrer (sfluhrer) <
sfluhrer@cisco.com>; wrote:

> It would appear that the Proof of Ownership listed in section 6.1 of the
> draft doesn’t work, in the sense that someone without knowledge of the
> value b can still generate a valid proof.
>
>
>
> Here is how he would do that:
>
>    - We assume that the putative client knows the value bG (the public
>    key), base and ecdhe_params; we assume that he does not know b.
>    - The client computes c = poo_prf ( base + ecdhe_params + "tls12 poo")
>    - The client picks an arbitrary elliptic curve point R, and computes
>    the point T = c(bG) + R.
>    - The client places R (as his supposed rG value) and T (as his
>    supposed tG value) in poo_params, and bG in the ecdhe_params.
>
>
>
> Then, the server computes c(bG) + rG; that is, c(bG) + R (for the
> client-provided R).  He then compares that to tG (that is, the
> client-provided T).  Of course, this will pass (the client picked T to make
> this happen), and so the server will believe that the prover knows b, when
> he doesn’t.
>
>
>
> Now, I don’t know lurk, and so I have no idea what sort of vulnerability
> this would allow.  However, if you have a ‘proof of possession’, it should
> be an actual proof…
>
>
>
> One way to fix this is to use a more normal Schnorr proof of knowledge:
>
>
>
>    - We assume a hash function h( X + base + ecdhe_params + “tls12 poo”
>    ), where X is an elliptic curve point and returns a value between 1 and
>    q-1, where q is the order of the curve; below, I’ll summarize this as h(X)
>    - The client selects a random value 1 (between 1 and q-1 – it must be
>    chosen uniformly), and computes:
>       - R = rG
>       - t = bh(R) + r mod q
>
> The client sends the point R and the value t in the poo_parameters, and
> the value bG in the ecdhe_params.
>
>    - The server computes the points tG and bH(R)G + R; and compares them
>    – it accepts the proof of ownership if they are the same point.
>
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>