Update description of aad and info. #54

dajiaji · 2024-02-25T11:32:59Z

@hannestschofenig @OR13 @laurencelundblade @ilari

Since I believe it will be easier to discuss based on a concrete proposal, I have updated the descriptions of COSE_KDF_Context, aad and info.

Could you please review it?

Closes #25 #53

OR13

JOSE has text about the related headers that says they MUST be understood, does COSE not have that text?

We might consider, listing the headers, and noting that while they are not used in the context, they can be relied on based on their being in the protected header, and the header being in aad.

draft-ietf-cose-hpke.md

OR13 · 2024-02-25T14:04:30Z

Consider, reviewing https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04 for context on how these the headers have been used in past.

draft-ietf-cose-hpke.md

Co-authored-by: Orie Steele <[email protected]>

hannestschofenig · 2024-02-25T17:29:03Z

draft-ietf-cose-hpke.md

-specification MAY populate the fields of the COSE_KDF_Context structure or MAY use
-a different structure as input to the "info" parameter. If no content for the
-"info" parameter is not supplied, it defaults to a zero-length byte string.
+Specifically, the KEM and KDF steps in HPKE supply sufficient context information


This is not correct.

The public keys are, of course, included in the computation. This is not what the context is about. The context is about the endpoint identifiers.

Indeed, it's not accurate. I think your point is valid.

Instead of claiming that information equivalent to COSE_KDF_Context is provided, it might be more appropriate to correctly refer SP800-53A and demonstrate that we have gained resistance to unknown key-share attacks, etc.

hannestschofenig · 2024-02-25T17:31:05Z

draft-ietf-cose-hpke.md

-{{RFC9053}} as a foundation for the info structure. This payload becomes the content
-of the info parameter for the HPKE functions, when utilized. For better readability of
-this specification the COSE_KDF_Context structure is repeated in {{cddl-cose-kdf}}.
+Therefore, there is no need to use the COSE_KDF_Context structure defined in {{RFC9053}}.


I disagree with this conclusion. If this is the case then why are there attacks like this https://datatracker.ietf.org/doc/rfc8844/ ?

I understand that it is annoying to provide this context information but unless we can proof that there are no problems we should be following the advice by cryptographers.

I'd like you to read the following message I posted previously to COSE WG mailinglist.

https://mailarchive.ietf.org/arch/msg/cose/XjOlXbTvMRqxhdXhovv5K3fYNnw/

First of all, COSE_KDF_Context is designed to be compliant with NIST SP800
56A#Section 5.8.2.1, but it's for One-step Key Derivation.

On the other hand, HPKE adopts Two-step Key Derivation internally (See
RFC9180#KeySchedule(), LabeledExtract(), LabeledExpand()
definitions), so we should refer not Section 5.8.2.1 but Section
5.8.2.2, Two-step Key
Derivation (Extraction-then-Expansion).
...

Co-authored-by: Orie Steele <[email protected]>

laurencelundblade

Would like to see us go the way of the discussion of the mailing list with no COSE_KDF_Context and a new structure for the aad input to Seal()

laurencelundblade · 2024-03-16T18:09:25Z

draft-ietf-cose-hpke.md

-the external_aad, while the "info" should be specified with an empty string.
+
+In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the protected headers.
+


Hoping aad input becomes a newly defined Recipient_Structure as discussed on mailing list.

draft-ietf-cose-hpke.md

OR13

The language around existing header parameters for COSE KDF context could probably be improved further.

The document needs to acknowledge these parameters can be present, and that they are ignored... But that because external AAD could be used consistently by sender and receiver and might make use of them, it's possible that they could be used if they are understood, but they are not required to be understood.

OR13 · 2024-03-16T20:23:04Z

draft-ietf-cose-hpke.md

+using this AAD as "aad" for HPKE is more compatible and natural with the COSE convention.
+
+
+In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the protected headers.


Suggested change

In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the protected headers.

In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the HPKE_Recipient_Enc_Structure.

HPKE_Recipient_Enc_Structure = CBOR ([

"HPKE_1_layer", layer1ProtectedHeaderBytes,

external_hpke_aad || empty buffer

])

Pretty sure this should align with COSE and be an Enc_Structure at the layer 1.

That's probably true.

draft-ietf-cose-hpke.md

OR13 · 2024-03-16T20:32:38Z

draft-ietf-cose-hpke.md

+This mode MUST NOT be used with COSE_Encrypt0 (tag 16).
+This mode MUST be used with COSE_Encrypt (tag 96).
+
+The `aad` provided to HPKE Seal and HPKE Open MUST be the protected bytes of the COSE_Recipient, as defined in {{Section 5.1 of RFC9052 }}.


Suggested change

The `aad` provided to HPKE Seal and HPKE Open MUST be the protected bytes of the COSE_Recipient, as defined in {{Section 5.1 of RFC9052 }}.

The `aad` provided to HPKE Seal and HPKE Open MUST be the HPKE_Recipient_Enc_Structure.

HPKE_Recipient_Enc_Structure = CBOR ([

"HPKE_2_layer", layer1ProtectedHeaderBytes, layer2RecipientProtectedHeaderBytes,

external_hpke_aad || empty buffer

])

I strongly favor just using the algorithm ID from layer1, rather than all the headers. If it's all the headers, you have to pass arbitrarily large amounts of data between layers, rather than just an algorithm ID. (Specifically, passing the algorithm ID was easy in t_cose. Passing all the headers would require restructuring and forcing a size limit on headers that is not there now).

I would like to not make this specific to HPKE. I think it should be used for the COSE -29 replacement too. So name it differently and use a different context string.

This is for a COSE_Recipient, so there's no external data as there is in layer 0 or in an Enc_Structure.

I think there should be optional private context data to replace the private data in COSE_KDF_Context that we are eliminating. It should be a bstr, empty if there is none.

I don't understand how the recipient protected header is secured in the case that algorithm is the only parameter passed from recipient protected header... And layer 1 protected header is already variable length.

Treating both protected headers as bytes, seems simplest and safest.

Ilari did make a comment that protected headers don't always have alg.

That is a good argument to include alg, but I would still want to make sure that headers were committed too.

I think a spanning set of cases and a new enc structure would help land this.

Hmm, I agree that a simple alternative to COSE_KDF_Context is necessary as a measure against the lamps attack, but in COSE-HPKE, wouldn't it be better to prohibit the use of non-AEAD algorithms for key wrapping (such as -29)?

I believe that a countermeasure against the lamps attack should be addressed in a separate draft, mainly targeting legacy key derivation algorithms (such as -25) before HPKE.

draft-ietf-cose-hpke.md

Co-authored-by: Orie Steele <[email protected]>

dajiaji · 2024-04-03T23:41:05Z

@OR13 @hannestschofenig the updates around COSE_KDF_Conxt will be done by #58, so could you merge this PR?

OR13

I would suggest we merge #58, close this PR and open a follow up PR to address remaining issues.

It's not clear to me that the discussion on this PR was resolved and I believe it's easier to simply merge 58 first and then raise a new PR to cover anything in this PR we need to.

dajiaji · 2024-04-03T23:57:40Z

I would suggest we merge #58, close this PR and open a follow up PR to address remaining issues.

Okay. I agree it's a simpler way. After merging #58, then I'll make a new PR to address the remaining issues.

dajiaji · 2024-04-03T23:58:57Z

Following Orie's suggestion, I close the PR.

Update description of aad and info.

0d7365b

OR13 approved these changes Feb 25, 2024

View reviewed changes

OR13 reviewed Feb 25, 2024

View reviewed changes

draft-ietf-cose-hpke.md Outdated Show resolved Hide resolved

OR13 reviewed Feb 25, 2024

View reviewed changes

draft-ietf-cose-hpke.md Outdated Show resolved Hide resolved

OR13 reviewed Feb 25, 2024

View reviewed changes

draft-ietf-cose-hpke.md Outdated Show resolved Hide resolved

hannestschofenig and others added 2 commits February 25, 2024 17:58

Update draft-ietf-cose-hpke.md

4820000

Co-authored-by: Orie Steele <[email protected]>

Update draft-ietf-cose-hpke.md

a9de35a

Co-authored-by: Orie Steele <[email protected]>

hannestschofenig reviewed Feb 25, 2024

View reviewed changes

Update draft-ietf-cose-hpke.md

62e0781

Co-authored-by: Orie Steele <[email protected]>

laurencelundblade suggested changes Mar 16, 2024

View reviewed changes

OR13 requested changes Mar 16, 2024

View reviewed changes

dajiaji and others added 6 commits March 17, 2024 09:48

Update draft-ietf-cose-hpke.md

29acd8c

Co-authored-by: Orie Steele <[email protected]>

Update draft-ietf-cose-hpke.md

c9920c9

Co-authored-by: Orie Steele <[email protected]>

Update draft-ietf-cose-hpke.md

289f544

Co-authored-by: Orie Steele <[email protected]>

Update draft-ietf-cose-hpke.md

e9c0fa3

Co-authored-by: Orie Steele <[email protected]>

Update draft-ietf-cose-hpke.md

a8143ed

Co-authored-by: Orie Steele <[email protected]>

Fix typo.

f50f741

OR13 self-requested a review April 3, 2024 23:43

OR13 requested changes Apr 3, 2024

View reviewed changes

dajiaji closed this Apr 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update description of aad and info. #54

Update description of aad and info. #54

dajiaji commented Feb 25, 2024

OR13 left a comment

OR13 commented Feb 25, 2024 •

edited

Loading

hannestschofenig Feb 25, 2024

dajiaji Feb 25, 2024

hannestschofenig Feb 25, 2024

dajiaji Feb 25, 2024

laurencelundblade left a comment

laurencelundblade Mar 16, 2024

OR13 left a comment

OR13 Mar 16, 2024

laurencelundblade Mar 16, 2024

OR13 Mar 17, 2024

OR13 Mar 16, 2024

laurencelundblade Mar 16, 2024

OR13 Mar 17, 2024 •

edited

Loading

OR13 Mar 17, 2024

dajiaji Mar 17, 2024 •

edited

Loading

dajiaji commented Apr 3, 2024

OR13 left a comment

dajiaji commented Apr 3, 2024

dajiaji commented Apr 3, 2024

		the external_aad, while the "info" should be specified with an empty string.

		In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the protected headers.

		using this AAD as "aad" for HPKE is more compatible and natural with the COSE convention.


		In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the protected headers.

-In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the protected headers.
+In both "HPKE direct encryption" and "HPKE key encryption", the aad provided to the Seal and Open operations MUST be the HPKE_Recipient_Enc_Structure.
+HPKE_Recipient_Enc_Structure = CBOR ([
+"HPKE_1_layer", layer1ProtectedHeaderBytes,
+external_hpke_aad || empty buffer
+])

Update description of aad and info. #54

Update description of aad and info. #54

Conversation

dajiaji commented Feb 25, 2024

OR13 left a comment

Choose a reason for hiding this comment

OR13 commented Feb 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

laurencelundblade left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 Mar 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dajiaji Mar 17, 2024 • edited Loading

Choose a reason for hiding this comment

dajiaji commented Apr 3, 2024

OR13 left a comment

Choose a reason for hiding this comment

dajiaji commented Apr 3, 2024

dajiaji commented Apr 3, 2024

OR13 commented Feb 25, 2024 •

edited

Loading

OR13 Mar 17, 2024 •

edited

Loading

dajiaji Mar 17, 2024 •

edited

Loading