Inline On Sun, Feb 11, 2024, 4:26 AM Ilari Liusvaara <[email protected]> wrote:
> On Sat, Feb 10, 2024 at 03:15:11PM -0600, Orie Steele wrote: > > This list feels like mostly complaints about JWE, and not about JOSE > HPKE. > > Sure, JWE has its problems, but that ship has sailed. Debating those > problems when working with JWE is not productive. One just has to live > with those. > > There is only one complaint about JWE, and that is then immediately > taken as something one needs to live with. Plenty of other complaints > just are not relevant here. > > > > With compatibility with ECDH-ES JWE shown, I feel pretty confident that > the > > design is on a good track. > > That was only a smoke test. Failing it would have been really bad, but > passing does not mean things are actually working. > > > > If there are problems in the design we have now... those problems are > > fundamental to JWE. > > I disagree. I think things can be vastly improved while modifying JWE > no more than what is currently done. > > > > We are adding HPKE support to JWE not making an incompatible alternative > to > > JWE, that only works with HPKE. > > The draft does currently have requirements incompatible with JWE. E.g., > > - Requirement to use JSON serialization for Key Encryption. > There is an open issue, before we had JSON Serialization working with backwords compatibility this was not possible, now that we have it, it's just matter of moving objects into the spaces between periods right? - Requirement to put "enc" in protected parameters for Key Encryption. > As is don't with Key Agreement with Key Wrapping? Not sure which enc you are talking about. - 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? > 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. > > > > As example of just what requirements like this can cause, I once wrote > support for extensible priorities in HTTP/2 in a reverse proxy. IIRC, I > explicitly ignored every single requirement that went against base > HTTP/2. Mostly, because code I was modifying was designed for as > specified by base HTTP/2. > Yep, that's why we added support for epk to transport encapsulated keys... To keep things as close as possible between key agreement with key wrapping and key encryption. > > > Adding the ability to upgrade to HPKE without major breaking interface > > changes is the objective, and greenfielding alternatives to JWE just > delays > > adoption of KEMs and resilience to harvest now decrypt later. > > Greenfielding alternatives to JWE is not an option. > > And even stuff that just goes against precedent can cause severe issues. > > E.g., Multi-recipient interface with similar design as I used in > COSE-HPKE test code would seem to work just fine now. But it would be > a major breaking change to add HPKE as currently specified to it. > But both are drafts... Expecting breaking changes in drafts is as it should be. 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. And we will still need to put protected headers in aads. > > > The guiding principle is this: > > > > Adding HPKE based single recipient and multiple recipient support, with > as > > few changes to JWE as possible. > > The guiding principles I have: > > - Keep things as simple as possible. > - Minimize disruption caused by JWE changes for single recipient. > Agreed - Zero HPKE-specific modifications to JWE. > So no new modes for integrated encryption and key encryption, and just use the same terms direct key agreement and key agreement with key wrapping? That seems more confusing to me. - Zero modifications to JWE for multiple recipient support. > I think we are close to solving for this, we only need to address compact mode for single recipient. > Note that first two are relative, while the last two are absolute. > And new header parameters, algorithms, etc. are not "modifications to > JWE". > Agreed. > The reason for requiring zero modifications for multiple recipients > is that the interaction between recipients is specified by JWE, and > trying to change those rules is asking for critical issues. > We have achieved zero modifications for multiple recipients, in tests. But we do use different language to support interop between key agreement with key wraps and key encryption. > 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? > And as example of disruption JWE changes could cause, consider > implementation that immediately parses JWE doing the first three steps > of JWE section 5.2. Maybe together with doing step 15. By time that is > done, original serialization is lost. That is very much code one does > not want to touch lightly. > > > > This constraint makes our job simple... What parameters go in headers? > How > > can we accomplish what is needed with as few HPKE specific changes as > > possible. > > For stuff relevant to HPKE, nothing except alg needs to go in headers. > This is in contrast to things like Key Agreement ephemeral key, that > does need to go into headers. > > I don't see any need for HPKE-specific changes. Even a new header for > KEM ciphertext (problematic for other reasons) could be usefully > repurposed for KEM Key Agreement. > I don't understand this. Are you saying that the header parameters we have registered for "key encryption" (we haven't registered any new ones) can be used for key agreement? > > > The current draft does the best at this so far, but it's possible in can > be > > further improved. > > > > I don't think your suggestion to concatenate strings values for enc and > ct > > is an improvement. > > What other way is there to satisfy: > > - Avoid requiring multi-shot HPKE for compact. > Why should single shot be used? - Both modes encode the output in the same way. > > ? > I'm not sure what you are talking about here. We don't need to take all of what HPKE defined, especially if it defined multiple ways to do things that are equivalent, we can pick the one way that makes sense for the JSON ecosystem. > 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. I do not see a strong enough reason to support single shot HPKE in JOSE, I don't think the performance improvement (???) Is worth the complexity. I don't think we should change JWE Protected headers to enable HPKE single shot. But perhaps let's create a new thread that is focused only in why single shot HPKE is essential for JWE / JWT. Let's make the case for single shot as clear as possible. > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
