On Thu, Jun 29, 2023 at 04:00:09PM +0000, Jeremy O'Donoghue wrote:
> The short version is that I *strongly* prefer a single “alg” integer
> to further parameterise the key usage space. The use of a construction
> like “hkc” is almost certain to complicate interoperability and
> testing. Large-scale systems may be able to support many options, but
> constrained systems rarely have that luxury. While configuration or
> profile documents can help, there is generally a risk over time of
> there being a large enough number of configurations that they no
> longer help very much as everyone chooses his/her favourite.
There has *never* been "single alg parameter" in COSE. Even in stock
RFC 8152, Message recipients can involve *three* different alg
parameters (+ fourth thing).
And "hkc" is not meant for highly constrained cases. For example,
if application does ciphersuite-per-key-type, then "hkc" is
completely unnecressary.
And having explicit list would do absolutely nothing to help interop in
constrained environments. The list would probably cover every KEM, KDF
and AEAD in HPKE at least once. Which would require the same effort as
dealing with everything. Except with *additional* complexity of dealing
with coupling.
As an example, it is much easier to deal with TLS 1.3 crypto negotiation
compared to TLS 1.2 crypto negotiation. Not because there are less
choices, but because there is much less coupling.
> I would also like to note that I don’t recommend Carsten’s
> “combinatorial bitmap” approach for the same reason – it won’t scale.
> I have experience in this from the GlobalPlatform TEE Internal Core
> APIs where we attempted to encode information in such a bitmap and ran
> out of bits over time. New algorithms *will* be added, and reserved
> bitfields are never wide enough.
While I don't recommend it due to hackyness, in this case the fields
would be wide enough: alg is 64 bits, and HPKEv1 can be packed in 50
bits.
> While crypto-agility is of definite and growing importance, it is not
> unreasonable to restrict the space within which agility is permitted
> to a subset of the large set of possible options in the name of
> interoperability, providing options that provide meaningfully different
> levels of security and/or differently constructed algorithms (hence,
> presumably, resistant to different classes of attack)
This does not actually help interoperability.
Then, COSE has always been frameworky. For such specifications,
restrictions for interop are inapporiate. Instead, the specs are
intended to be profiled down or specialized for applications, and in
that process, appriate restrictions are defined for interoperability.
The programming saying is "mechanism, not policy".
Any list of ciphersuites one could design would make some application
sad. Because it has unnecressary ciphersuites (e.g., anything except
P256/SHA256/AES128). Or because it does not have a required ciphersuite
(e.g., P384/SHA384/AES256). Or because it has two different ciphersuites
with the same KEM (e.g., KEM48/SHA256/AES256 and KEM48/SHA256/CHACHA20).
> If the time to generate new informational RFCs to define new cipher-
> suites for COSE “alg” is too long, we should address this rather than
> adopting “hkc” as a workaround.
It is not just one RFC (and that is surprising amount of effort), but
essentially endless stream of those, every time HPKE adds something,
and those costs add up.
> Compliance with existing standards: This is the COSE list, and I’m
> only tangentially interested in JOSE, so answering for COSE. It has
> been stated, and I agree that you need the key + alg to determine
> what to do. I believe this remains unchanged with the single integer
> “alg” solution. The “hkc” solution definitely represents a change,
> and does overload some concepts that are described be existing COSE
> parameters – which implies even more testing for consistency of all
> of the information in a COSE structure before starting to use it.
Best to ignore JOSE here, because it is *impossible* to integrate
HPKE to JOSE using the same strategies as used by COSE-HPKE.
"Single integer alg" *would* be a change, as I explained above.
And "hkc" is not so much a change, than a *new* capability, with no
parallel currently.
> Compatibility with design policy of other HPKE application standards:
> I am more interested in maintaining COSE as a reasonably clean,
> consistent and comprehensible standard. Compatibility with standards
> developed elsewhere falls into the “nice to have” category for me,
> and is definitely secondary to the goal of a clean COSE.
The only part that I think even *could* be cleaner is where the KEM info
is stored for dedicated HPKE keys.
> Variety of supportable use-cases: This is exactly the same with both
> proposals, as far as I can tell. The difference is in the mechanism to
> define new variations. I regard restricting the default set of
> operations as a feature and not a bug.
No, it is not the same. More work for extra complexity, for likely no
gain.
> >From my, possibly selfish, vendor and interoperability perspective,
> >HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM and
> >HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM do exactly
> >the same thing, with near-indistinguishable levels of security, so
> >it is not really clear why I would need both.
As note, og TLS 1.3 supports both, P256 and X25519, even after they
did delete all the "unnecressary" stuff (the duiplicate entries are
from adding back one deleted thingy).
> HPKE also allows me, if I understand correctly, to select
> HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA384-AES256GCM – while legal,
> I doubt that this represents a sensible choice for most users.
Yeah, that is essentially HPKE problem. Here is acutally one place it
is not the best designed.
(The problem with that is that it needs both SHA256 and SHA384.)
> In short, this is exactly the area where I *like* to see expert
> review.
That review is going to be less "expert" than what you would like...
> Ease of coding: I don’t see this as a strong argument for “alg” over
> “hkc”. It is probably true that “alg” is smaller and simpler for
> constrained environments as it simplifies checking in cases (common)
> where layering of operations is not as clean as might be possible in
> a larger implementation, but this is not really a strong justification
> for the approach.
>
> In the counter-direction, the argument in favour of “hkc” as simpler
> from an ease of coding perspective only applies if there is a clean
> separation between the COSE and HPKE layers. For me, the essential
> separation is between the description of the encoding and cryptographic
> libraries – it is not a given that there needs to be a separate
> HPKE layer, so I don’t see it as proven that this approach is superior.
It is not just separation in code, it is also separation in
specification.
If specification is left ad-hoc, there is risk that someone gets some
"smart" idea, and ends up paving the road to hell with it.
> In any case, for systems like these, the coding time for a new
> algorithm is far exceeded by the time needed to complete validation
> to a satisfactory level.
Especially if code is rats nest of coupled stuff. In contrast, if code
is highly modular, one can concentrate effort on very small parts of the
system.
> Facilitating Algorithm Choice: I’ve worked for many years with people
> who develop Trusted Applications on GlobalPlatform TEE where the
> cryptographic APIs allow a great deal of flexibility. I have seen far
> more security errors resulting from people choosing inappropriate
> cryptography than I have seen benefit from that flexibility. There
> is a huge benefit in having expert scrutiny to select a relatively
> small set of options that cover common use-cases over letting people
> do bad things.
I don't think there would be any benefit from expert scrutiny:
- COSE-HPKE supports exactly *one* kind of cryptography, so it is not
possible to choose wrong one.
- As for bad algorithms, COSE WG is in no position to do expert
scrutiny on that.
> This means that I strongly favour simplification of usage for the 99%
> of users who just want to do something secure. The 1% who have special
> use-cases must certainly not be prevented from doing so, but I don’t
> really care if they must deal with a slightly more inconvenient
> representation. In short, optimize and guide towards for the correct
> usage of the common use-cases while not actively preventing other
> options.
It is not just "slightly more inconvenient representation". Using
"single alg" inherently prevents other options. And for some
applications, that is a dealbreaker.
> This also helps hugely with interoperability as it provides a
> tractable combination of options to test (this is not a trivial factor
> for product vendors).
As I explained above, it does not help with interoperability. And
with regards to testing, it would *increase* the effort required.
> Ease of Adding a new HPKE KEM: I don’t agree on the assumption that
> HPKE will be provided as a separate layer. This will doubtless often
> be the case, but it will not always be true. We certainly don’t
> “need” to do it.
HPKE is certainly *specified* as a separate layer. While yeeting the
parts of HPKE that are never used gets good simplifications, I think
it is doubtful that mixng in the HPKE implementation will buy much,
as most of that is irreducable crypto code.
> Adding any new algorithm to a system implies change somewhere, and
> for the same reason that I don’t regard “ease of coding” as an
> argument in favour of “alg”, I don’t regard “ease of adding a new
> HPKE KEM” as an argument in favour of “hkc”.
That change can be just updating the HPKE library. Something that is
required anyway.
> In particular, I expect to see increasing numbers of systems for
> which the layers defined in CBOR are at least partially auto-
> generated from CDDL, and in this case I think the effort would be
> the same.
CDDL might autogenerate a parser, but it definitely will not
autogenerate a decoder.
> Also important to consider that many embedded systems are essentially
> statically linked and run from a single system image, so making any
> change implies creating a complete new image.
That does not mean it is irrelevant how many components need to be
modified: Builds are automated, modifying components is not.
> Incidentally, solutions like dependabot do not address the problem of
> creating adequate validation suites for cryptographic systems, and
> more algorithm combinations creates a combinational explosion in the
> testing requirements.
How testing requirements scale depends on coupling.
That combinatorial explosion *only* happens in presence of coupling.
> Examples
>
>
> Ø > AwesomeHPKEApp.new(suite={kem: DHKEM_X25519_HKDFSHA256(0x20), kdf:
>
> Ø > HKDF_SHA256(0x01), aead: AES128GCM(0x01)})
>
> Ø
>
> Ø
> AwesomeHPKEApp.new(suite="HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM")
>
> Assuming we had a value of 1762 for “alg” representing
> “HPKEv1-Base-DKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM”, I offer
> you:
>
> AwesomeHPKEApp.new(alg=1762)
>
> …which seems shorter still. I’m aware this example is facetious,
> but in reality libraries would pre-define constants that an IDE
> would likely auto-complete for you (even emacs does such things
> these days).
Well, there are some issues with that API, starting from the fact that
KEM is constrained by the key...
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
