Subject: [COSE] Some comments on draft-ietf-cose-countersign-04

From: John Mattsson <[email-masked]>
Date: Wed, 2 Jun 2021 12:25:00 +0000

Hi,

Some comments on draft-ietf-cose-countersign-04

- References:
OLD: [I-D.ietf-cbor-7049bis]
NEW: RFC8949

OLD: [I-D.ietf-core-groupcomm-bis]
NEW: [I-D.ietf-core-oscore-groupcomm]

- "In order to always regenerate the same byte string for the "to be
signed" value, the deterministic encoding rules defined in
Section 4.2 of [I-D.ietf-cbor-7049bis].  These rules match the ones
laid out in Section 11 of [I-D.ietf-cose-rfc8152bis-struct]."

Section 11 is now IANA. Should be section 9.

I made a PR to fix the above things
https://github.com/cose-wg/countersign/pull/7

- Just refering to section 4.2 of RFC8949 might not be enough as section 4.2  of RFC8949 specifies different deterministic encodings.

- "It should be noted that there is a big difference
between attesting to the encrypted data as opposed to attesting to
the unencrypted data.  If the latter is what is desired, then one
needs to apply a signature to the data and then encrypt that."

I think the draft should give some more security consideration here. At least point out the problems/properties of countersigning a COSE_Encrypt:

- It does not prove that the signer had any knowledge the plaintext. An attacker might remove a countersignature and resign a ciphertext.
- An attacker can link a countersignature to a specific public key and therefore also link different countersigned COSE_Encrypt with each other.

The paper from USENIX 2001 might be good reference:
https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html

- The order of COSE_Countersignature0 processing at the receiver seems undefined. The order should either be mandated or it should be stated that the receiving part can process things in any order.

Cheers,
John

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Jun 2021 15:54:21 -0400

Thanks John.

> https://github.com/cose-wg/countersign/pull/7 <https://github.com/cose-wg/countersign/pull/7>
I just merged this PR.

> - Just refering to section 4.2 of RFC8949 might not be enough as section 4.2  of RFC8949 specifies different deterministic encodings.

I am not sure what additional things to add.  Section 4.2 of RFC8949 says that applications can specify restrictions to ensure that a deterministic format is produced.  I think that means these restrictions are "above" COSE.

> - An attacker can link a countersignature to a specific public key and therefore also link different countersigned COSE_Encrypt with each other.

Does this resolve your concerns:

   ...  It should be noted that there is a big difference
   between attesting to the encrypted data as opposed to attesting to
   the plaintext data.  Usually, the signer wishes to countersign the
   plaintext data, and then encrypt the data along with the
   countersignature.  This approach prevents an attacker from stripping
   countersignatures.  In addition, this approach prevents an observer
   from linking the public keys needed to verify the countersignatures
   across different payloads.  It is always possible to construct cases
   where the use of two different keys will appear to result in a
   successful decryption (the tag check success), but which produce two
   completely different plaintexts.  This situation is not detectable by
   a countersignature on the encrypted data.

> - The order of COSE_Countersignature0 processing at the receiver seems undefined. The order should either be mandated or it should be stated that the receiving part can process things in any order.

I think that Jim intended the same set of steps to be used.  For example, Section 3.3, Step 3, says: "This field is omitted for the Countersignature0V2 attribute."

Russ

---

From: John Mattsson <[email-masked]>
Date: Wed, 23 Jun 2021 14:52:38 +0000

Hi Russ,

See inline

From: Russ Housley <[email-masked]>
Date: Wednesday, 2 June 2021 at 21:54
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [COSE] Some comments on draft-ietf-cose-countersign-04
Thanks John.

- References:

I made a PR to fix the above things
https://github.com/cose-wg/countersign/pull/7<https://protect2.fireeye.com/v1/url?k=d65df8c0-89c6c022-d65db85b-86073b36ea28-e78c77dfebf70d7f&q=1&e=08f606cc-fbb7-4eff-90f1-9462b5069998&u=https%3A%2F%2Fgithub.com%2Fcose-wg%2Fcountersign%2Fpull%2F7>

I just merged this PR.

John: Ok, I think the current text is fine. Section 4.2 of RFC8949 specifies two different orders for maps but that is probably not important for COSE.

John: Yes, the suggested text looks good.

John: I was thinking about the order of decryption (in the case of COSE_Encrypt) and signature verification.  If the receiver starts doing decryption or even using the plaintext before verifying the signature it could lead to security problems.

Russ

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Jun 2021 17:09:04 +0200

> John: Ok, I think the current text is fine. Section 4.2 of RFC8949 specifies two different orders for maps but that is probably not important for COSE.

If you do need to provide deterministic encoding for maps, please choose the "Core Deterministic Encoding Requirements” (Section 4.2.1), not the legacy "Length-First Map Key Ordering” (Section 4.2.3).

Grüße, Carsten

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2021 11:19:50 -0400

> On Jun 23, 2021, at 11:09 AM, Carsten Bormann <[email-masked]> wrote:
> 

I'll change it to:

   In order to always regenerate the same byte string for the "to be
   signed" value, the core deterministic encoding rules defined in
   Section 4.2.1 of [RFC8949].  These rules match the ones laid out in
   Section 9 of [I-D.ietf-cose-rfc8152bis-struct].

Russ

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Jun 2021 17:21:36 +0200

> On 2021-06-23, at 17:19, Russ Housley <[email-masked]> wrote:
> 
>   Section 4.2.1 of [RFC8949].  

This sentence no verb.

> These rules match the ones laid out in

+1 otherwise.
Thank you!

Grüße, Carsten

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2021 11:35:13 -0400

> On Jun 23, 2021, at 10:52 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
>  

John:

In the context of CMS, we have had this discussion many times, and for every set of rules that have been proposed over the decades, a counter example has been found.  So, I certainly agree with your goal, I am skeptical that there is a simple set of rules that we can include in the document.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2021 11:53:20 -0400

> On Jun 23, 2021, at 11:21 AM, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 

Fixed:

   In order to always regenerate the same byte string for the "to be
   signed" value, follow the core deterministic encoding rules defined
   in Section 4.2.1 of [RFC8949].  These rules match the ones laid out
   in Section 9 of [I-D.ietf-cose-rfc8152bis-struct].

Russ