Hi Hannes,
On Jun 18, 2024, at 4:07 AM, Tschofenig, Hannes <[email protected]>
wrote:
Hi Laurence,
I believe we are optimizing the wrong part of the spec. We should not optimize
a security feature that is not that complex in the first place.
We have to change something to address the lamps attack for multi-recipient
COSE-HPKE and also at some point for -29 (ECDH-ES + A128KW RFC 9053 section
6.4<https://www.rfc-editor.org/rfc/rfc9053.html#name-key-agreement-with-key-wrap>).
next_layer_alg in the proposed Recipients_structure is a very neat and clean
solution for both. The info struct doesn’t solve it.
Protocol designers in the IETF require diverse expertise, including
cryptographers. This is one of the examples. Luckily, we can reach out to those
experts. We do the heavy lifting so that others, particularly application
protocol designers, don’t have to do it.
Right. The heavy lift for us is to make it clear and easy for application
protocol designers to avoid the attacks described in Appendix B of NIST SP
800-56A. This did not get done in the publication of RFC 9053 (and maybe not
with JOSE either). The big problems are 1) t Appendix B is very vague and not
specific to COSE, 2) the description of how to use info struct is lacking and
3) info struct doesn’t solve the lamps attack.
Two possible paths:
1) new Recipients_structure
- https://github.com/cose-wg/HPKE/pull/58/files
- Perhaps explain/define how to include Sender/Receiver info if the use cases
wants to.
2) info struct
- Use info struct
- Clarify how the Enc_structure works
- Add a next_alg somewhere to address lamps attack
- Lots of writing to to explain how to use info struct
See attached email from a year ago analyzing all the fields. Pretty sure the
new Recipients_structure can support all of these by defining new COSE headers.
Also, I think COSE_KDF_Context is about three times as complicated as it needs
to be. It can just be some simple strings without all the arrays and such. This
is definitely unnecessary implementation (I’ve implemented it).
The attack shown in LAMPS demonstrate that we exactly have to involve
cryptographers with things where everything looks pretty simple.
No problem involving cryptographers, but I don’t think what you wrote about
your talk with Paul is specific enough to justify what you are asserting.
An analysis like the one in the attached email from a year ago from Paul would
be great.
Appendix B of NIST SP 800-56A points out what the problems are with the lack of
context information. We have several examples where this is a problem. Bad
random number generation is another problem, which is unrelated but also
important.
My understanding is that some of the stuff in Appendix B is there to mitigate
against poor random numbers. A big problem with Appendix B is that it is
written in an extremely general way. Some of the stuff in it is for really
degenerate situations like key re use, but you can’t tell what.
LL
Ciao
Hannes
PS: I am not sure what you are referring to with COSE -29.
From: lgl island-resort.com <[email protected]>
Sent: Monday, June 17, 2024 8:05 PM
To: Tschofenig, Hannes (T CST SEA-DE) <[email protected]>
Cc: cose <[email protected]>
Subject: Re: [COSE] Context Information Structure and COSE-HPKE
Hi Hannes,
1) Data structure design
I’d like to provide something that is much simpler than the info struct that
can do everything it can if needed. I think the way to do this is by allowing
COSE headers to get in the mix rather than the bunch of awkward fixed fields in
the info struct that are NULL most of the time.
2) Security
I think it’s terrible to require every protocol designer hire a cryptographer.
That is onerous and not normal for an IETF protocol.
You don’t need to hire a cryptographer to know if pure HPKE is safe, right? At
least there’s nothing like this mentioned in the HPKE doc. It doesn’t need all
the stuff from the info struct. We didn’t publish CMS or TLS this way either.
Despite having info struct, COSE -29 and multi-recipient COSE-HPKE weren’t safe
from the lamps attack. Info struct is no magic bullet, not even with every
field filled in.
I’d like to proceed with the better recipient structure and our best
recommendation for security, more or less what we came up with in San
Francisco. It will be much better than already-published CMS and COSE. Better
because we’ve done more thinking and because we’ve made fixes. We will also
provide all the facilities that info struct provides (in a different form) so
we’ll not be going backwards.
I’m not a cryptographer either, but I’m pretty confident by the circumstantial
evidence, by my own thinking and by the discussions we’ve had. The
circumstantial evidence is that we haven’t turned out any literature or on-line
discussion discussing how to use info struct. It’s been published many years.
JOSE has used it. The explanation for much of the text in NIST SP 800-56A
Appendix B is re-use of keys and bad RNGs. Paul is of course going to say what
he said by default. I think the question I’d ask him is this: “what’s the worst
attack assuming a good RNG and no key re-use”. Did he know about the lamps
attack?
I also find it interesting that no one is excited about the fact that COSE -29
is a published IETF standard with a known vulnerability. There’s no effort to
fix it. There’s no notification posted. It’s not in any vulnerability database.
I want to fix COSE -29 with the same fix I’m proposing here for
COSE-HPKE<https://github.com/cose-wg/HPKE/pull/58/files>.
LL
On Jun 17, 2024, at 7:27 AM, Tschofenig, Hannes
<[email protected]<mailto:[email protected]>>
wrote:
Hi all,
one of the big discussion points in the COSE-HPKE draft was the context
information structure. Lot of opinions have been shared on the mailing list and
I would like to provide my perspective about this topic.
Although I have been working on security protocol design for many years I do
not qualify as a cryptographer. For this reason, I have reached out to Paul van
Oorschot, seeVan Oorschot: Carleton
University<https://people.scs.carleton.ca/~paulv/>, to get his perspective on
this topic. Paul worked with Diffie and Wiener on the analysis of key exchange
protocols and on the attacks relevant to this discussion (reflection, and
relay/splicing attacks).
The guidance found in the academic papers has much later been incorporated into
NIST SP 800-56A (see Appendix B) demanding key exchange protocols to include
identifiers and other context-specific information in key derivation functions.
These recommendations have been followed up by standardization work in, for
example, COSE (see Section 5.2 of RFC 9053).
In the work on COSE-HPKE we thought it would be "too complex" to follow these
recommendations and discussed alternatives.
In my chat with Paul, he recommended to follow the advice unless we can
demonstrate that our design is not vulnerable to the attacks available in the
literature. He acknowledges that those attacks (such as the unknown key share
attack) are advanced, but they are not completely unrealistic either.
Since we are developing a generic building block, it will be difficult to
demonstrate that our designs will be free of problems when COSE-HPKE is used in
some application protocol scenario. We would essentially be pushing the problem
of figuring out whether a design is safe to use to application protocol
designers.
For this reason, I would like to re-use the RFC 9053 defined context
information structure and populate the structures with the relevant values,
which also includes the identities of the communication parties. Of course, we
do not know the structure of the identities used at the application layer since
COSE-HPKE is a building block that needs to be instantiated by a given
application (such as firmware updates or a messaging protocol) but we can
demand protocol designers to plug their identities into the respective fields.
For test vectors, potentially be included in the appendix of the draft, we
would use dummy values, such as [email protected]<mailto:[email protected]> and
[email protected]<mailto:[email protected]>.
I would like to know what you think about this suggestion for moving forward.
Hence, I would like to walk away from our self-designed structures.
If you agree, I am happy to create a PR.
Ciao
Hannes
_______________________________________________
COSE mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
--- Begin Message ---
I’m replying to my own email with a list of things in COSE_KDF_Context and
their purposes. I think we need to understand to decide what to do. I may not
have the purpose right for some, so please comment.
Algorithm ID
Binds the output key material of the HKDF to the algorithm that key material
will be used with. The purpose is explained fairly well in RFC 9053.
This binding doesn’t occur any other place in COSE so this is not optional.
The value of this comes algorithm IDs in other parts of the COSE protocol.
HPKE takes care of this internally for COSE-HPKE single recipient mode, but not
for multiple recipient mode.
This seems valuable even if there is no HKDF (e.g. plain AES Key Wrap), but
you’d have to do an explicit alg ID comparison rather than rely on KDF
perturbing the key.
Sender/Receiver Info (e.g. Party U)
Appendix B of NIST SP800-56A gives the rationale referencing some papers
describing attacks. This is fairly esoteric for me so far so I can't give a
plain explanation. I’m still kind of looking for good guidance on how / when to
use this. It seems like this is defense-in-depth rather than essential unless
your use case is poorly constructed in some way.
However, I think the bottom line is that is best practice nowadays, so for
example COSE libraries should really support it.
HPKE SealBase() doesn’t provide this.
Sender and Receiver Info Nonce
A means, among many, to bind to a particular individual message between the
sender and receiver.
This is very optional, but also not difficult to provide.
The same security effects can be obtained by using the salt (and the salt seems
simpler so I think it would be preferred).
HPKE doesn’t provide this.
SuppPubInfo.keyDataLength
The output of the KDF is a key used by some algorithm like AES-GCM or AES Key
Wrap. This is the number of bits in the key needed for that algorithm. RFC 9053
seems to say this is needed when the target algorithm allows multiple key
sizes, however we don’t seem to use such algorithms. I don’t see any symmetric
algorithms registered for COSE that have variable key size. The Algorithm ID
above is enough so far.
Never, the less, this is mandatory per RFC 9053 and thus must be implemented.
HPKE provides this internally for COSE-HPKE single recipient, but not for
COSE-HPKE multiple recipient.
(Rhetorical question — Why is this in SuppPubInfo and not a peer to AlgorithmID
in the CBOR encoding or why is AlgorithmID not in SuppPubInfo?)
SuppPubInfo.protected
This is the super-important part that protects the protected COSE header
parameters.
Absolutely not optional.
In COSE-HPKE draft-05, this is taken care of by using an Enc_structure with
context “Enc_Recipient”, but we could (should) change COSE-HPKE to line up
better with the rest of COSE.
For some COSE, like AES Key Wrap that has no AEAD or HKDF there is no
protection here.
Other — Hash of ciphertext
Hannes has proposed that a hash of the SUIT_Digest be included here. In
practice I think this is a hash of ciphertext in the COSE_Encrypt.
I’d like to call this into question because I don’t see this in the list in
NIST SP800-56A section 5.8.1.2. Implementing it adds complexity and
computational cost because it is a hash over something the size of the payload.
HPKE could have done this internally, but I don’t think it does.
The question is, what attack does this prevent? I would assume this is specific
to firmware encryption because if it were a general attack, then COSE, HPKE
and/or NIST SP800-56A would have addressed it.
(I confess to not reading NIST SP800-56A so much yet so maybe I’m missing
something).
Based on this, I conclude that COSE-HPKE must support most of the above.
Probably that is by using COSE_KDF_Context instead of Enc_structure with
context “Enc_Recipient”. Specifically, because:
Binding to the content encryption algorithm and its key length for multiple
recipient HPKE is not optional in COSE
Need to provide PartyU and PartyV like the rest of COSE and also like JOSE and
to support NIST SP800-56A which seems to be best practice
General consistency with COSE
All that said, this seems like defense-in-depth to me. If none of this were
implemented, most COSE-secured protocols still seem hard to break. This isn’t
like using a bad RNG or like using counter mode wrong. However, it’s best
practice so we should support most of it.
LL
> On May 31, 2023, at 10:13 AM, Laurence Lundblade <[email protected]>
> wrote:
>
> It seems to me that RFC 9052 section 5.3 defines an Enc_structure with
> context “Enc_Recipient”, but nothing in RFC 9052 or 9053 makes use of it. I’m
> 75% confident that Jim’s code does the same. This is confusing and seems a
> dark corner of COSE that needs illuminating.
>
> The purpose of Enc_structure with context “Enc_Recipient” would seem to be
> for COSE_Recipients that are used in COSE_Encrypt. It’s how the integrity
> protection of the protected headers is achieved, how the COSE_Recipient is
> bound into a COSE_Encrypt (so it can’t be cut/paste into a COSE_Mac) and how
> Externally Supplied Data is double-protected (previous HPKE-related
> discussion about this).
>
>
> BUT, all the ECDH + HKDF key agreement methods use RFC 9053 section 5.2
> COSE_KDF_Context (AKA Info struct) instead. COSE_KDF_Context definitely
> covers the protected headers. It also provided binding to sender/receiver and
> some other bindings.
>
> Look at all the encrypt key agreement methods in 9053 section 6 and see none
> use Enc_structure:
> - ECDH + HKDF — COSE_KDF_Context is always the input to the info parameter
> for HKDF
> - Key wrap — Not possible to protect the headers, so nothing, no use of
> Enc_structure or COSE_KDF_Context
> - Direct — Same as key wrap
>
> In HPKE we defined use of Enc_structure with context “Enc_Recipient” as the
> “info” parameter to SealBase. I now believe that was wrong and it should be
> COSE_KDF_Context instead. I don’t think the extensive context hashing in HPKE
> provides everything that COSE_KDF_Context does (maybe HPKE Auth mode does,
> but Base mode doesn’t bind to sender/receiver).
>
> I’m almost convinced that Enc_structure with context “Enc_Recipient” should
> never be used and that we should always use COSE_KDF_Context because it
> provides a lot more.
>
>
> OR THIS — Get rid of COSE_KDF_Context. Replace it with a bunch of protected
> header parameters to hold the similar values. Use Enc_structure with context
> “Enc_Recipient” and feed that into the info parameter of HKDF and SealBase.
> That would be much cleaner and in line with the rest of COSE. Implementations
> could just reuse parameter encoding/decoding code. Probably too incompatible
> with published RFCs for this change though.
>
>
> Basically, some of the key agreement methods have an “info” parameter that
> can protect additional data (HKDF and Seal) and some don’t (keywrap and
> direct) (some new-fangled key wrap could have this though). COSE_KDF_Context
> is too-specifically associated with HKDF when it probably should be general
> and/or turned into COSE header parameters (I believe COSE_KDF_Context is
> cloned from previous CMS-related work).
>
> LL
>
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
--- End Message ---
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
