Hi Ilari, Please see inline
On Sat, 22 Feb 2025 at 00:58, Ilari Liusvaara <[email protected]> wrote: > On Fri, Feb 21, 2025 at 03:50:40PM +0530, tirumal reddy wrote: > > > > On Tue, 18 Feb 2025 at 13:02, Ilari Liusvaara <[email protected]> > > wrote: > > > > > On Tue, Feb 11, 2025 at 12:05:30PM +0530, tirumal reddy wrote: > > > > Hi all, > > > > > > > > The revised draft > > > > https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ > addresses > > > > all WG comments and appears ready for WGLC. > > > > > > There appear to be several technical issues with the way Key Encryption > > > is done: > > > > > > 1) How is HPKE AAD input set? > > > > > > Furthermore, passing protected header as AAD causes issues: > > > > > > - This is likely to cause severe implementation difficulties with > > > existing JWE implementations, as no current algorithm works like > this. > > > > > > > Existing libraries can be adapted to support this mechanism, which > > leverages the protected header as HPKE AAD. The change introduces an > > additional step in the decryption process, but it is compatible with > > current JWE implementations. > > If the existing library has a conflicting assumption in external API, it > is NOT possible to adopt it to support this mechanism. > This is an implementation-specific limitation, not a specification issue. > > > > - It does not give cryptographic separation between modes. Preventing > > > the possible attacks from confusing modes is left to checks that are > > > not even specified. > > > > > > The prohibition on mixing modes is impossible to implement, as > > > endpoints lack the needed information. > > > > The modes can be easily distinguished (with 'enc' set to 'dir' for > > integrated encryption and 'enc' set to an AEAD algorithm for key > > encryption), ensuring that the modes don’t interfere with each other and > > keeping the decryption process clear. > > Key Encryption might not have 'enc'. Integrated Encryption does have > 'enc' set to 'dir', but this requires extra check. > How will the Key Encryption mode work without "enc" ? > > > > > - It does not cryptographically prevent LAMPS-style attacks, as "enc" > > > might be unbound. > > > > > > Checking "enc" as required by JWE prevents these attacks, but at > > > least one member thinks these attacks should be cryptoghraphically > > > prevented. > > > > > > > In this case, 'enc' is integrity-protected which protects against an > > attacker who manipulates the > > encryption algorithm in the 'enc' parameter. > > Enc is not integerity-protected. The only integerity-protected > parameter in RFC 7516 is 'zip'. > Enc is integrity-protected, please check the example in Key Encryption Section. > > > > > 3) Message-level requirements that conflict with JWE requirements: > > > > > > Section 6 contains number of requirements on the whole message. Such > > > requirements are not allowed by JWE. > > > > > > > I don't see any such restriction imposed in the JWE spec, for instance > see > > https://datatracker.ietf.org/doc/html/rfc7516#section-7.2.1 > > For interoperability, RFC 7516 could do whatever. But it also needed to > set limits on what algorithms are allowed to do. Those limits are set in > stone, changing those would be JWE2. > The rules in Section 6 define how HPKE-based key encryption should be applied within JWE while adhering to existing JWE formatting principles. They do not alter JWE’s fundamental processing model but ensure that HPKE is integrated in a consistent and interoperable manner. If any aspects appear to conflict with JWE’s design principles, please let us know. > > > > > > The protected header MUST contain an "enc" that is registered in both > > > > the IANA HPKE AEAD Identifiers Registry, and the IANA JSON Web > > > > Signature and Encryption Algorithms Registry. > > > > > > > I can rephrase the text as follows: > > > > The JWE Protected Header MUST include an "enc" value registered in both > the > > IANA HPKE AEAD Identifiers Registry and the IANA JSON Web Signature and > > Encryption Algorithms Registry to ensure consistency across recipients > (see > > Section 7.2.1 of [RFC7516]). > > I think that is even worse. It has all the problems of previous, plus > adds a false rationale. > > - How is overlap evaluated? The names are different. > - What if JOSE algorithm gets later added as HPKE AEAD algorithm > (this obviously can not lead to any status change)? > - What should JWE library do if you try to add JOSE-HPKE recipient to > multi-recipient message with some random "enc" (that it is happy with > otherwise)? > > The easiest way to fix this is to remove the whole thing. > > > > > > The "iv", "tag" JWE members MUST be present. > > > > I can rephrase the text as follows: > > If the selected AEAD algorithm requires an IV and authentication tag, the > > "iv" and "tag" parameters MUST be present, as specified in {{RFC7516}}. > > This is not the kind of requirement that is helpful to repeat, as it > concerns whole different part of the code. > > > > > > The "aad" JWE member MAY be present. > > > > What is the problem with the above line ? > > It is concern for totally different part of code. > > > > > > The "ciphertext" MUST be the base64url encoded ciphertext as > described > > > > in Step 19 in Section 5.1 of [RFC7516]. > > > > > > > Fixed, it is Step 16 in Section 5.1 of [RFC7516]. > > Again, recipient processing should not be doing anything with > ciphertext. > I will address the above comments with the following text: The processing of "enc", "iv", "tag", "aad", and "ciphertext" is already defined in RFC 7516. Implementations should follow the existing JWE specifications for handling these parameters, and no additional processing requirements are introduced by HPKE-based key encryption. And removed the 5 lines discussing "enc", "iv", "tag", "aad", and "ciphertext" in the Key Encryption Section. > > > > > 4) Unsafe stuff in requirements > > > > > > The requirements allow header parameter "auth_kid", which is unsafe. > > > > > > > The recipient unprotected header parameters "psk_id" and "auth_kid" > > > > MAY be present. > > > > > > This needs to be MUST NOT. See next item. > > > > > > > It is allowed but not recommended, see > > > https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-05.html#section-8.1 > > . > > It should not be allowed. > Please clarify why it should not be allowed ? > > > > > Then there is a subtle issue that might cause implementation > > > difficulties with existing libraries: All current Key Encryption > > > algorithms have complete JWE Encrypted Keys, which can be decrypted > > > without reference to any headers. However, JOSE-HPKE does not work > > > that way: The key is split between JWE Encypted Key and a header > > > parameter. > > > > > > The simplest way to make JWE Encrypted Key compete would be just > > > mash the ek and ct outputs from HPKE into JWE Encrypted Key. The > > > receiver can figure out how big ek is from alg (e.g., HPKE-0 always > > > has 65 byte ek), and the remaining part must be ct. > > > > > > > Combining ek (encapsulated key) and ct (ciphertext) into the JWE > Encrypted > > Key would change the intended semantics of JWE Encrypted Key. I > re-collect > > it as discussed previously and there is no consensus in the WG to > > concatenate the ek and ct. > > JWE specifies that for Key Encryption, JWE Encrypted Key is the result > of encrypting the CEK to the recipient. > I don't see a problem, existing libraries can be upgraded to support the proposed approach. If I recall correctly, this was discussed in the WG, and no consensus was reached to modify JWE to combine these values. -Tiru > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
