Ilari,
> Is there even a guarantee that corresponding dedicated key wrap
> algorithm exists? Currently all the registered algorithms have a
> corresponding dedicated key wrap, but could one register an algorithm
> that does not?
Right. AES Key Wrap algorithms are happily registered but there is no
guarantee into the future.
That's why I want to update section 5.2 of RFC 9053 like
"This is the algorithm identifier of *just the upper (or next) layer*,
normally a content encryption algorithm identifier or a key wrap algorithm
identifier."
For example, when a COSE message have { layer0.alg : A128GCM, layer1.alg :
ECDH-ES+A128KW},
a content encryption algorithm identifier A128GCM should be the value of
COSE_KDF_Context.AlgorithmID for ECDH-ES+A128KW.
For triple-layer example in RFC 9052 <
https://datatracker.ietf.org/doc/html/rfc9052#name-two-layers-of-recipient-inf
>,
which has { layer0.alg : A128GCM, layer1.alg : A128KW, layer2.alg :
ECDH-ES+HKDF-256 },
a key wrap algorithm identifier A128KW should be the value of
COSE_KDF_Context.AlgorithmID for ECDH-ES+HKDF-256.
However, the latter case doesn't prevent the lamps attack because the same
CEK will be derived also for { layer0.alg : A128CBC, layer1.alg : A128KW,
layer2.alg : ECDH-ES+HKDF-256 } .
I think we have several options:
a) Hannes's approach that surely derives the final CEK using a content
encryption algorithm identifier
b) Laurence's approach that feeds new structure, Recipient_structure, to
both ContextR.open() and HKDF() functions, with updating section 5.2 of RFC
9053
c) Updating section 5.2 of RFC 9053 with "This is the algorithm identifier
of *the top layer*, normally a content encryption algorithm identifier."
Option b and c may not be the perfect mitigation for lamps attack, because
they don't care about key distribution methods without KDF, Direct and
AES-KW.
Even though, I think that we are in the same thought that section 5.2 of
RFC 9053 is not good for security nor interoperability, and that it is
better for us to clarify it.
> However, I noticed that the diagram is missing RSA-OEAP, which is key
> transport mode. That one has no facility to bind the next algorithm.
Indeed... But forgive me, the diagram is going to exceed the limit of the
width of I-D, 72 characters.
OAEP itself actually doesn't have an identifier, but RSA-OAEP seems not to
take COSE_KDF_Context as a parameter, right?
Best,
Ken
2024年7月23日(火) 16:08 Ilari Liusvaara <[email protected]>:
> On Mon, Jul 22, 2024 at 07:02:26PM +0000, lgl island-resort.com wrote:
> >
> > On Jul 22, 2024, at 5:35 AM, Ken Takayama <[email protected]>
> wrote:
> >
> > Also, in some ways Recipient_structure is not that different from
> > Context Info Structure. They both have an algorithm ID and cover the
> > protected headers. They are both input into the processing at the same
> > place. The main difference is that all the extra stuff to address weak
> > keys, bind to context and such goes in COSE headers in
> > Recipient_structure rather than an arcane inherited structure half of
> > which doesn’t make sense, is ill-defined and such.
>
> Yeah, Context Information Structure is pretty full of arcane stuff
> that is nontrivial to use securely. And then it is also missing some
> important stuff.
>
>
> One issue with Recipient_structure is that it is not completely clear
> when it is used as opposed to Enc_structure. I presume if COSE-HPKE
> is at layer 1+, then use Recipient_structure, else use Enc_structure.
>
> I think it would be simpler to have Enc_structure2 that extends
> Enc_structure to bind the algorithm information (with a way to indicate
> that there is no next algorithm for layer0).
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
