Thank you, for all your feedback. Inline:
On Sun, Feb 11, 2024 at 2:40 PM Ilari Liusvaara <[email protected]> wrote: > On Sun, Feb 11, 2024 at 12:13:22PM -0600, Orie Steele wrote: > > > > On Sun, Feb 11, 2024, 10:17 AM Ilari Liusvaara <[email protected] > > > > wrote: > > > > > On Sun, Feb 11, 2024 at 06:48:36AM -0600, Orie Steele wrote: > > > > > > > That says that the encryption algorithm may be specified in unprotected > > > recipient headers, as long as it is the same for every recipient. > > > > > > If you don't think that is great, I agree. > > > > > > > In Key Agreement with Key Wrapping: > > > > All recipients need to support the same content encryption algorithm, so > > they all need to support the same JWE Protected Header. > > > > Regarding unprotected headers: > > > > I'm not here to change that behavior, but if we were to do the RFC over I > > would probably say something similar, but with more precision regarding > > tampering with unprotected data. > > Right, except the main problem is not unprotected data but incorrect > scope. Maybe the BCP doc could say don't do that? Be conservative what > you send and all. > > > > > > - Requirement to put "alg" in per-recipient unprotected header for > Key > > > > > Encryption. > > > > > > > > > > > > > It's optional or it's mandatory, which do you think is correct? > > > > > > "alg" is mandatory for every recipient. From JWE decryption procedure: > > > > > > > ------------------------------------------------------------------------ > > > 6. Determine the Key Management Mode employed by the algorithm > > > specified by the "alg" (algorithm) Header Parameter. > > > > ------------------------------------------------------------------------ > > > > > > Which is one of the per-recipient steps, and the following steps make > > > absolutely no sense without knowing KMM. > > > > > > > With HPKE using Key Encryption, those steps are the same, and the > algorithm > > is present in the recipient header. > > If all recipients have the same alg, it can also be in global headers > (protected or unprotected). > That's an unfortunate "or" but I assume we must preserve it? I've added 2 placeholder tests for these cases, if we must preserve this behavior, we will at least provide examples. > > > > With HPKE using Integrated Encryption, the algorithm is in the protected > > header, and there is a single recipient, however, the rest of the steps > > regarding aad, and IV and tag do not apply. > > There should be explicit encryption and decryption procedures for the > Integrated Encryption mode. Because the procedures in sections 5.1. and > 5.2. no longer make sense. > > And there are number of steps in encryption procedure that are still > sensible. E.g., 9 through 14, 16 through 19. > > And decryption procedure also has some sensible steps. E.g., 1 through 3, > 14, 15, 17 and 18. > > And the steps regiarding aad, IV and tag do apply. IV and tag are just > empty (section 7.2.1. explicitly considers these cases). > Yes, I agree, although I'm not looking forward to this task : ) > > > > > > > And then arguably also requirement to use compact serialization for > > > > > Integrated Encryption. > > > > > > > > > > > > > Integrated encryption is a new mode, as is key encryption ,if you > mean > > > that > > > > neither is in JWE that is true. > > > > > > JWE has all serializations be interconvertable, without access to keys, > > > as long as JWE does not require something that target serialization can > > > not represent. > > > > > > This impiles: > > > > > > - Any JWE with one recipient can be converted to flattened JSON > > > Serialization. > > > - Any JWE can be converted to general JSON serialization. > > > > > > > > > This is kind of thing that can have profound impact on how an > > > implementation is internally structured, and breaking it could have > > > very disruptive consequences. > > > > > > > Agreed. > > > > The primary challenge here seems to be the missing IV, tag, and aad > values, > > when switching serialization between compact and json. > > > > In integrated encryption, you won't have those values. > > JWE already specifies what to do (omit empty ones). > I have added examples that cover this case, thank you. > > > > If you need those values you MUST use JSON Serialization... You have > always > > needed JSON for JWE aad. > > > > You have not previously been able to omit tag and IV, when doing key > > agreement with key wrapping. > > It is not specific to KAwKW. There just has not been any bulk encryption > algorithm that does not use IV nor tag. If there was such thing, it > would have the same behavior. > > > > > One could imagine JOSE equivalent would be roughly: > > > > > > impl MultiRecipientEncrypt > > > { > > > pub fn get_key(&self) -> &[u8] { &self.key } > > > pub fn add_recipient(&mut self, recipient_hdr: > &BTreeMap<String, > > > JSON>, ek: &[u8]) { /* ... */ } > > > /* ... */ > > > } > > > > > > I.e. method to export the CEK and method to add arbitrary recipient. > > > > > > Such API supports all current Key Wrap, Key Agreement with Key Wrap and > > > Key Encryption algorithms. And it would compose nicely with another API > > > that had methods for the various Key Wrap, Key Agreement with Key Wrap > > > and Key Encryption algorithms. > > > > > > But this will fail for HPKE algorithms. > > > > > > > Why? > > > > Seems like it should be possible to build an API, that given at least 1 > > private key for a recipient, can decrypt the CEK and, add a new recipient > > with an encrypted content encryption key. > > This API is for creating a new message encrypted to multiple recipients. > > And the reason this API does not work is that protected headers are not > available. There might be further calls to modify protected headers, or > those might not be specified until the last method call. > > And looking at JWE section 5.1., recipients come first, then the bulk > stuff. > I ended up moving the sections of code I use to generate examples around to reflect this: https://github.com/OR13/draft-jose-hpke-test-vectors/blob/main/src/KeyEncryption.ts > > > > > > I don't have good references to look at for COSE encrypt, so it > would be > > > > harder to make progress on it in the same way, but I do think it's > work > > > > adding COSE key support for encapsulated keys. > > > > > > COSE-HPKE is almost ready. However, it is easier problem because: > > > > > > - Unprotected headers are always available. > > > - There is no specified encryption mechanism. > > > - Aad is clearly per-layer. > > > - There is only one mode. > > > > > > Disagree that COSE encryption is easier in the general case. > > It is certainly far more elegant. > After reviewing all the different options for where things can go, I am starting to agree. > > > > In the context of HPKE I disagree that COSE HPKE should look > substantially > > different that COSE ECDH-ES. > > The initial throughly overcomplicated versions were actually like that. > It was quickly changed to be its own special type of thing (with it being > a bulk AEAD, this does not cause issues in COSE). > > > > I've shown that it's possible for ECDH-ES and HPKE to work in JOSE > > together, and too function nearly exactly the same way. > > The reason those work together is that from JWE standpoint, HPKE is Key > Encryption, and JWE specifies how KE, KW and KAwKW work together. > Agreed. > > > > > > And we will still need to put protected headers in aads. > > > > > > Those are cleanly separated in COSE. Complete with crossmode attack > > > protection. > > > > > > (Sadly no CBC/CTR oracle attack protection.) > > > > > > > I need to start with a multiple recipient ECDH-ES COSE implementation and > > convince myself of this. > > The crossmode attack protection is from the Enc_structure.context field. > > But there is no requirement for using AE or AEAD on top level, so it is > vulnerable to the attack in that LAMPS slidedeck/RFC. Hell, the > algorithms used in that attack are even registered! > > > > Key Encryption is already defined by JWE (RFC 7516). > > > > > > > And is our use of the term consistent? > > Yes. Except I think there are some instances of KAwKW should be KE. > I'm not sure how to address this, but it's possible it is better to wait for a new version on the datatracker to see if we cleared it up by then. > > > > > > > And some changes to JWE are required in order to add the Integrated > > > > > Encryption mode, I.e., this draft needs to update RFC 7516, but > those > > > > > changes must not preclude non-HPKE mechnisms later. > > > > > > > > > > > > > I am not sure what you mean, this draft invented the term integrated > > > > encryption, are you saying we should leave it open for others to use > it > > > > differently? > > > > > > Not differently, but in the same way, but with new algorithms. > > > > > > > I still don't follow, I think you are saying other drafts might use "Key > > Encryption" and "Integrated Encryption" like we did in JOSE-HPKE, I don't > > think our document prevents this. > > This is just matter of document layout, and not what ultimately ends up > happening. > > > > > The draft does not register header parameter for that, but a key type. > > > > > > > That's correct, because there exists a header parameter that carries keys > > called epk. > > However, encapsulated keys are not themselves keys. > In the case of DHKems, they are literally public keys (uncompressed) starting with the 04 prefix, then x component, then y component. Sure HPKE says it's "opaque bytes", are we building a key format that is only for HPKE? In that case kty: EK, ek: enc is as much a key as any other opaque symmetric key. > And what the heck should implementation do with JWK of such type? Key > types are primarily for JWK, it is just that those get reused for > ECDH-ES (which does indeed have ephemeral keys). > JWK supports many different keys, the only required parameter is "kty". > > > > > And then e.g., register OKP "crv" for X-wing. Or id-MLKEM768-ECDH-P256 > > > (a ML-KEM/P256 hybrid). > > > > > > And none of this would be change to JWE anyway, because it is just > > > algorithms and keys. > > > > > > > Agreed, although having multiple ways to do the same thing, seems less > good > > than having one way to do it... I suppose this will need to be said every > > time someone wants to do what HPKE does, without using it. > > > > As an aside, I am concerned about how this kind of behavior will interact > > with hybrids, but as you said, it is not something that can be stopped in > > the JOSE HPKE draft, and perhaps is is desirable to not use HPKE for some > > use cases. > > Heck, what does JOSE HPKE initally even add? Scanning the algorithm > list, I only see stronger KDFs. I don't think JWE is currently > bottlenecked on KDF. > > To get anything actually new, one would need something like ciphersuite > involving HPKE KEM 48 (X25519Kyber768Draft00). That one is PQC, where > no current JWE alg is. > > > And then I noticed HPKE-Base-P256-SHA256-AES128GCMKW... labeled as > Key Agreement with Key Wrap algorithm. Is the whole section just > mislabeled (along with previous section), or how the heck does that > even work? > Seems like a remnant... it's not in here: https://raw.githubusercontent.com/tireddy2/JOSE_HPKE/main/draft-rha-jose-hpke-encrypt.md We've made a lot of changes recently. I don't know if we need to define KW algorithms for all the HPKE suites... I don't think we should... I don't think COSE HPKE does either. > > And then I noticed that all ciphersuites have base mode, but there are > "psk_id" and "auth_kid" parameters, that only make sense for non-base > modes. Do those headers implicitly modify mode, or are there just no > ciphersuites available? > Yep, we added those in advance of actually being able to use them with any suites. We will need suites for them. > > (There is an attack if auth/auth_psk modes are used for key encryption). > What is the attack? > > > > > > > I don't think there are any. There is only one output field besides > > > > > headers for Key Encryption, and Integrated Encryption can not use > > > > > headers in compact without requiring multi-shot. > > > > > > > > > > > > > I think you are saying you prefer to have single shot and multi shot > > > > supported, over having JWE Protected headers be consistent. > > > > > > > > This is a good point. > > > > > > Single-shot can be supported with both modes consistent. But there is > > > only one way to do that (output concatenation). > > > > > > > I think you are correct here. > > > > The reason you are correct is that unprotected headers are not supported > in > > compact, and protected headers are required input to AAD. > > Well, there are also encrypted key and iv fields, but recipients either > do not have those, or are required for other purposes. > I think the new examples in https://github.com/tireddy2/JOSE_HPKE/pull/19 address this. > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
