Opened 10 years ago

Closed 9 years ago

#8 closed defect (wontfix)

Direct mode for key agreement needs security analysis

Reported by: rbarnes@… Owned by: draft-ietf-jose-json-web-encryption@…
Priority: major Milestone:
Component: json-web-encryption Version:
Severity: Active WG Document Keywords:
Cc:

Description

JWE specifies a "direct encryption" method, in which the output of key agreement is used for content encryption instead of key wrapping. This scheme is not used in other IETF security protocols that use key agreement, e.g., CMS or IPsec. CMS uses the agreed key for wrapping. IPsec uses it to key the IKE SA, which covers further key agreement. The security considerations needs to justify why this scheme is secure, and any relevant constraints (e.g., lifetime of DH keys).

Change History (3)

comment:1 Changed 10 years ago by ietf@…

Personal Opinion -
I have no problems with using the key that is the output of a key agreement directly as the content encryption key. The rules here are going to be the standard ones such as you must make sure that the same key is not going to be generated each time and thus there is a requirement for a random value to be included from the senders side. However there is not going to be a significant difference between the case of using this output to wrap a key vs using this output to wrap a body.

I have no issues with this mode of encryption from a cryptography standpoint.

I think that a more significant question deals with the processing. Allowing this generates a new path for dealing with processing of messages which potentially complicates the analysis of the code. The requirement exists for doing the key wrap state in the event of multiple recipients and potentially should be a requirement for even the single recipient case.

comment:2 Changed 9 years ago by michael.jones@…

What existing security considerations on key lifetimes of encryption keys would it be appropriate for us to reference? These have to exist, albeit, perhaps in algorithm-specific contexts.

Given that JOSE is only defining a representation for the inputs and outputs of existing algorithms, not defining new algorithms, perhaps the right thing to do is also the simple thing to do: state that they key lifetime security considerations in the specifications that define those algorithms continue to apply when using those algorithms using JOSE data structures.

comment:3 Changed 9 years ago by ietf@…

  • Resolution set to wontfix
  • Status changed from new to closed

There is now a constrained device use case that appears to need this ability. There are no known additional security considerations that would need to be written. There are potentially some considerations that need to be made for longer term private keys, but they are different that for MAC keys.

Note: See TracTickets for help on using tickets.