Inline On Sun, Jul 2, 2023 at 10:49 PM AJITOMI Daisuke <[email protected]> wrote:
> I suspect developers will especially enjoy not needing to use >> COSE_KDF_Context. > > > I agree with you. At least, I don't want to use COSE_KDF_Context at all. > > >> Is the protected header binding always present in Enc_structure? > > > The protected header and the external AAD are always set in the > Enc_structure as follows: > > Enc_structure = [ > context : "Encrypt" / "Encrypt0" / "Enc_Recipient" / > "Mac_Recipient" / "Rec_Recipient", > protected : empty_or_serialized_map, > external_aad : bstr > ] > > > The serialized Enc_structure data is always used as AAD (Additional > Authenticated Data) for the AEAD function. > In this way, the protected header is always bound to (not the keying > material but) the AEAD encryption process as a part of transaction > information. > > Does it matter if the protected header excludes any algorithm details such >> as aead, mode, kem, or kdf? > > > Regarding the HPKE information, it does not matter. > The mode and suite_id(kem/kdf/aead) are bound to the keying material in > the internal HPKE KDF step. > > I agree regarding "pure HPKE" that it should not matter, but for COSE, I am not sure if there is really no preference, or if there are "better" or "worse" ways to do it. Can you expand the CDDL / example above, and provide a concrete example of using Enc_structure with both the "alg" and "hkc" approaches for comparison? The thing I am trying to focus on here is: What information from the protected header is applied to aead? Regardless of *how* that information is represented in the protected header. Does knowing that AES-128-gcm is "used" in the aead process change opinions on if it should or should not be in the header? What about the other components of "alg" ? For example, imagine a header that used the "alg": "DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256 + AES-128-GCM" My understanding is that these would all be bound to the aead encryption process. Imagine a different "alg" values: "DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256" ... does it matter that "AES-128-GCM" is left off? As you said, let's ignore the "alg" part of the keys for now, focusing only on "alg" in a protected header... To me, it seems odd that the protected header might not be "in agreement" with the aead process used, for example: I might learn that a recipient supports everything possible. I might encrypt to them using "DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256 + AES-128-GCM", but the envelope header only says "DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256" How does the recipient know which aead was used, and does the *sender* need to communicate that information in some tamper evident way? It seems like the answer should be yes, regardless of *how* that information is represented. But I am interested in if there are cases where we don't want this binding, cases where nothing regarding "alg" or "hkc" is in the protected header, are those cases worth supporting, or are they dangerous? OS Best, > Daisuke > > 2023年7月3日(月) 11:36 Orie Steele <[email protected]>: > >> I agree with what you wrote, and I suspect developers will especially >> enjoy not needing to use COSE_KDF_Context. >> >> I don't fully understand the details of how the binding to the protected >> header will be accomplished. >> >> Is the protected header binding always present in Enc_structure? >> >> Does it matter if the protected header excludes any algorithm details >> such as aead, mode, kem, or kdf? >> >> >> On Sun, Jul 2, 2023, 7:51 PM AJITOMI Daisuke <[email protected]> wrote: >> >>> I've finally read the NIST SP800 56A(revision.3)(*1) and 56C(*2). >>> >>> In conclusion, we should not use COSE_KDF_Context for COSE-HPKE. >>> >>> 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<Role>(), 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)*. >>> >>> In Section 5.8.2.2, a strict context structure that consists of >>> AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo is NOT >>> required. Instead, only a Label, Context and L (the length of the keying >>> material) are required. The explanation of the context information for >>> Two-step key derivation is as follows, and I believe it allows for flexible >>> definitions: >>> >>> ... >>>> Context is a binary string containing information relating to the >>>> derived keying material. Section 5.8.2 provides a list of context-specific >>>> information that *may be appropriate* for the inclusion in this >>>> string. >>>> ... >>> >>> Different orderings of the component data fields of FixedInfo may be >>>> used, and one or more of the data fields may be combined (or omitted under >>>> certain circumstances). >>> >>> >>> These three fields are clearly considered in the HPKE design. >>> Specifically, in HPKE, the KEM and KDF steps supply sufficient context >>> information (e.g., recipient and sender public keys, "HPKE-v1", mode, >>> specified ciphersuite (implicitly includes L info for the AEAD step), and >>> usage label) to the key derivation process. >>> >>> Even by limiting it to the context information supplied by the HPKE >>> layer, it covers the "Context-specific information that may be appropriate >>> for inclusion in FixedInfo" described in 56A#Section 5.8.2 to adequately. >>> Additionally, by using Enc_structure, it is possible to bind protected >>> header information to the context. If we consider not only the KEM/KDF >>> steps but also the AEAD step, the application-specific information can be >>> bound to the context using external_aad. I believe that the combination of >>> HPKE itself and the COSE Enc_Structure mechanism adequately binds >>> transaction information to the derived keying material. >>> >>> Next, regarding the compliance with RFC9052/9053. >>> >>> My proposal is to fully replace the Enc_structure with COSE_KDF_Context >>>> in COSE-HPKE. I am not proposing double protection. >>> >>> >>> As Ilari pointed out, it's impossible. >>> Enc_structure is a mandatory specification for the main structures, >>> COSE_Encrypt0 and COSE_Encrypt, and not using it would completely break >>> compatibility with RFC9052/9053. >>> On the other hand, COSE_KDF_Context is defined specifically for use with >>> the KDF defined within the RFC 9053 document and the "alg" values that >>> should be used with COSE_KDF_Context are also clearly defined. >>> Therefore, It is not necessary to use COSE_KDF_Context for COSE-HPKE, >>> and it is possible to exclude it without affecting the functionality. >>> >>> Based on the fact that we have to use Enc_structure, adopting >>> COSE_KDF_Context in COSE-HPKE seems to result only in unnecessary >>> duplication of the context binding. >>> >>> Best, >>> Daisuke >>> >>> *1: >>> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf >>> *2: >>> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf >>> >>> >>> >>> 2023年6月10日(土) 2:15 lgl island-resort.com <[email protected]>: >>> >>>> >>>> On Jun 7, 2023, at 9:40 AM, Ilari Liusvaara <[email protected]> >>>> wrote: >>>> >>>> To that end I’ve tried to see how all the items in COSE_KDF_Context >>>> apply to COSE-HPKE. I think those are the arguments that matter. >>>> >>>> >>>> I just did go through all the subfields. I think every one of those is >>>> either redundant, explicitly non-generic or trivially broken in generic >>>> context. >>>> >>>> >>>> Not sure non-generics can be dismissed just because they are >>>> non-generic. Part of the point is to have inputs so that non-generic cases >>>> can be property secured. >>>> >>>> LL >>>> >>>> _______________________________________________ >>>> COSE mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/cose >>>> >>> _______________________________________________ >>> COSE mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/cose >>> >> -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
