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

[Daniel Migault <[e-mail]>]

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) <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk
>