Subject: [COSE] Binding of sender's key in ECDH-ES.

From: Adam Langley <[email-masked]>
Date: Sat, 9 Jul 2016 14:48:33 -0700

I think from reading
https://tools.ietf.org/html/draft-ietf-cose-msg-14#section-12.4.1 that
ECDH-ES is supposed to authenticate the sender, i.e. that successfully
decrypting an ECDH-ES message also authenticates it. For example,
Table 19 lists a label for a sender's static key for use with ECDH-ES,
which would be meaningless if ECDH-ES was supposed to be anonymous.

Given that, I don't see how the sender's static key is included in the
key derivation. I would have expected something like the input keying
material to HKDF to be ECDH(sender-static, receiver-static) ++
ECDH(sender-ephemeral, receiver-static). That would give one-way
forward secrecy and would authenticate the message w.r.t the sender's
static key (*)

There are many words, so it's very possible that I missed something,
so I also looked at
https://github.com/cose-wg/cose-implementations/blob/master/csharp/COSE/EncryptMessage.cs#L1529
and I only see a single ECDH operation in there.

Is it that I misunderstood the aim and that ECDH-ES is
sender-anonymous? If not, how does the sender show possession of their
static key?

(* Modulo key-compromise impersonation.)

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Jim Schaad <[email-masked]>
Date: Sat, 9 Jul 2016 15:40:43 -0700

I need to find out where you went wrong, but that is not the intent.

Note that there is both an ECDH-ES and an ECDH-SS version in the table.  One
uses the ephemeral key and one uses the static key for doing the key
agreement.   The paragraph that discusses these options is the
"Ephemeral-static or static-static" bullet above the table.

There is a small number of common ECDH routines because, modulo how to find
the second key, the processing is the same.

If you can identify where you got confused, please let me know so I can look
at doing clarifications.  

Jim

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Adam Langley
> Sent: Saturday, July 09, 2016 2:49 PM
> To: [email-masked]
> Subject: [COSE] Binding of sender's key in ECDH-ES.
> 
> I think from reading
ECDH-ES
> is supposed to authenticate the sender, i.e. that successfully decrypting
an
> ECDH-ES message also authenticates it. For example, Table 19 lists a label
for a
> sender's static key for use with ECDH-ES, which would be meaningless if
ECDH-
> ES was supposed to be anonymous.
> 
> Given that, I don't see how the sender's static key is included in the key
> derivation. I would have expected something like the input keying material
to
> HKDF to be ECDH(sender-static, receiver-static) ++ ECDH(sender-ephemeral,
> receiver-static). That would give one-way forward secrecy and would
> authenticate the message w.r.t the sender's static key (*)
> 
> There are many words, so it's very possible that I missed something, so I
also
> looked at
> https://github.com/cose-wg/cose-
> implementations/blob/master/csharp/COSE/EncryptMessage.cs#L1529
> Is it that I misunderstood the aim and that ECDH-ES is sender-anonymous?
If
> not, how does the sender show possession of their static key?
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Adam Langley <[email-masked]>
Date: Sat, 9 Jul 2016 16:37:33 -0700

> If you can identify where you got confused, please let me know so I can look

Thank you for the clarification.

I came into the document expecting ECDH-ES to bind a sender's static
key (i.e. in the style of 6.2.1 of NIST SP 800-56A:
http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-56Arev1_3-8-07.pdf),
so the fault might well be entirely my own. There's much discussion of
a sender static key in that area of the document, which fed my
incorrect assumption, and there's the label -2 in table 19, which is
defined as the sender's static key for ECDH-ES. Should that be for
ECDH-SS, or is it a "return address" for the recipient in the case of
ECDH-ES?

I'm not sure that anything needs to change in the document, but would
the expected structure for a sender-authenticated, one-way
forward-secure message be an ECDH-ES message encrypted in an ECDH-SS
message?

Cheers

AGL

---

From: Jim Schaad <[email-masked]>
Date: Sat, 9 Jul 2016 17:12:04 -0700

> Sent: Saturday, July 09, 2016 4:38 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [COSE] Binding of sender's key in ECDH-ES.
> 
> > Note that there is both an ECDH-ES and an ECDH-SS version in the
> > table.  One uses the ephemeral key and one uses the static key for doing
the
> key
> > There is a small number of common ECDH routines because, modulo how to
> > find the second key, the processing is the same.
> >
> > If you can identify where you got confused, please let me know so I
> > can look at doing clarifications.
> 
> I came into the document expecting ECDH-ES to bind a sender's static key
(i.e. in
> the style of 6.2.1 of NIST SP 800-56A:
>
> so the fault might well be entirely my own. There's much discussion of a
sender
> static key in that area of the document, which fed my incorrect
assumption, and
> there's the label -2 in table 19, which is defined as the sender's static
key for
> ECDH-ES. Should that be for ECDH-SS, or is it a "return address" for the
recipient
> in the case of ECDH-ES?

Now I understand exactly where you got confused.  Using the NIST terminology

ECDH-ES --> C(1, 1)
ECDH-SS --> C(0, 2)

Thus ECDH-ES should NEVER have any of the sender static fields and only have
the ephemeral key field.  Likewise, ECDH-SS should ONLY have one of the
sender static fields and never have the ephemeral key field.

> 
> I'm not sure that anything needs to change in the document, but would the
> expected structure for a sender-authenticated, one-way forward-secure
> message be an ECDH-ES message encrypted in an ECDH-SS message?

It would be an ECDH-SS message.

I will cogitate and see if I can come up with some clarifications.

Jim

---

From: Adam Langley <[email-masked]>
Date: Sat, 9 Jul 2016 17:22:44 -0700

> sender static fields and never have the ephemeral key field.

Got it, thanks.

So should the "algorithm" cell in row two of table 19
(https://tools.ietf.org/html/draft-ietf-cose-msg-14#section-12.4.1)
read "ECDH-SS"? (Seeing as the sender's static key would only make
sense in ECDH-SS, as I now understand it?)

Cheers

AGL

---

From: Jim Schaad <[email-masked]>
Date: Sat, 9 Jul 2016 17:32:44 -0700

Yes it should.

Jim

> Sent: Saturday, July 09, 2016 5:23 PM
> > Thus ECDH-ES should NEVER have any of the sender static fields and
> > only have the ephemeral key field.  Likewise, ECDH-SS should ONLY have
> > one of the sender static fields and never have the ephemeral key field.
> 
> Got it, thanks.
> 
> read "ECDH-SS"? (Seeing as the sender's static key would only make sense
in
> ECDH-SS, as I now understand it?)
> 
> 
> Cheers
> 
> AGL
>

---

From: Adam Langley <[email-masked]>
Date: Sun, 10 Jul 2016 14:37:04 -0700

> Yes it should.

Thank you, that's clear to me now.

Cheers

AGL