Add Security Considerations section on Versioning Cryptography Suites. #36
Conversation
There was a problem hiding this comment.
I would strongly prefer versioning / naming that identifies the algorithm in use and the core parameter set. second two that, I would consider versioning using semvar or similar.
I also would like to see pointers to NIST and eIDAS to encourage the developer to review based on their operating environment
index.html
Outdated
| identifier. The drawback to this scheme is that most of the population that uses | ||
| these sorts of identifiers are not well trained and thus will not understand | ||
| that the previously mentioned identifier is a cryptographic suite that is no | ||
| longer safe to use. |
There was a problem hiding this comment.
We can also just recommend that developers check current NIST / FIPS levels, safecurves, and IANA registries.
There was a problem hiding this comment.
Yes, I'll add a suggestion to check current NIST/FIPS levels, safecurves, and IANA registries.
We should also be realistic about doing so -- many developers don't do that and use whatever is available in their libraries after a quick search on stack overflow (which might be an answer from years ago, instead of a current one). All that to say, the standard advice given to date is to do the things above and that has been demonstrated to not be as effective as we need it to be -- a simple read through of monthly CVEs and Equifax-like breaches demonstrate this to be true. We have decades of data on how depending on developers to "read the docs" is not as effective as we need it to be.
index.html
Outdated
| upgrade might be appropriate. The drawback of this approach is that its not | ||
| clear if an upgrade is necessary, as software version number increases often | ||
| don't require an upgrade for the software to continue functioning. This can | ||
| lead to developers thinking their usage of a particular version is safe, when | ||
| it is not. |
There was a problem hiding this comment.
Since we are talking about cryptography, it is likely ok that we could establish and document a policy for versioning - e.g. breaking changes with major versions, minor versions when a security patch is pushed, and / or point to semvar or similar. with cryptography we don't want to encourage experimentation, unless it is clear that there is something new and experimental - e.g. 1.0.1-alpha and 1.0.1-pre-release
There was a problem hiding this comment.
A further note. Seems like we really should be wanting to encourage semvar or similar at the library and implementation layer.
There was a problem hiding this comment.
it is likely ok that we could establish and document a policy for versioning
You seem to be arguing for two different things -- parametric versioning and semver. We will need to come to ground on ONE way forward for Data Integrity, given that having two ways will just confuse things more.
Semver is more workable than parametric versioning, given that parametric versioning presumes that you get the implementation right the first time around. The proposed pattern is: CRYPTOSUITE-VERSION, so eddsa-2022 or eddsa-v1... the parametric version of that would be urdna2015-eddsa-ed25519 (but based on emails over the past several weeks, we already have a weak signal in CFRG that eddsa-ed25519 is going to have two variations already -- deterministic and random -- coupled with two canonicalization schemes -- which means that if we had gone with parametric to begin with, we'd have a backwards compatability problem on our hands already -- and that's not even counting all the parametric churn that's happened to RSA and ECDSA over the years).
At this point, I'd like to understand how serious you are about pushing for parametric versioning... because that's probably the worst option that's being contemplated (for at least the reasons outlined above -- there are others that we can get into if someone is going to argue for it).
Seems like we really should be wanting to encourage semvar or similar at the library and implementation layer.
Yes, we should have implementation guidance in the Data Integrity spec that promotes whatever mechanism we end up settling on. There should be a simple way to warn the developer: "Hey, you're using an outdated mechanism -- turn on unsafe mode if you want to keep using it".
There was a problem hiding this comment.
my personal preference is towards parametric for naming - with libraries that implement encouraged towards semvar for versioning
parametric naming is separate from versioning in my mind - versioning would be handled by the current WG level (likely with semvar or similar - e.g. urdna2015-eddsa-ed25519-r standardized along side the VC 2.0 TR
There was a problem hiding this comment.
my personal preference is towards parametric for naming
If you prefer parametric naming, how do you plan to address data format changes, like when we switched from jws to proofValue or if the encoded value of proofValue changes for a particular cryptographic suite? One of the drawbacks for parametric naming is when things outside of the parameters change that affect the cryptography (such as the data format for a particular parameter, or the omission of a hash function). If you prefer parametric naming, then do you oppose non-parametric names like "RS1" and "P256" and "RSA1_5"?
There was a problem hiding this comment.
do you oppose non-parametric names like "RS1" and "P256" and "RSA1_5"
definitely not - provided it is indicative of the scheme / format / or another key functional component to identify what is in use - but I typically like that kind of thing as a "mod" of sorts appended or pre-pended to the alg + params
This is one of those tough things as there is not a clear "right answer" and what we pick can and will have lasting effects.
There was a problem hiding this comment.
definitely not - provided it is indicative of the scheme / format / or another key functional component to identify what is in use
RS1 does not indicate that 1) it is an encryption scheme identifier, 2) it uses PKCS1-v1_5, 3) it uses SHA-1. In other words, it's not parametric at all, but you seem to indicate that you're not opposed to it.
P256 does not indicate that 1) it is a curve identifier, 2) is easily confused with PS256, which is a signing algorithm.
PS256 does not indicate that 1) it is a signing algorithm identifier, 2) is easily confused with P256, 3) uses the MGF1 mask generation function, 4) uses SHA-256 for BOTH the pre-hash and the MGF function
RSA1_5 does not indicate that 1) it is a CEK from 2003, 2) requires key sizes larger than 2048 bits.
So, if you are not opposed to those, you are not opposed to non-parametric approaches.
I'm trying to understand your mental model here and it's not clear to me. Why are you suggesting that we should do full parameterization, but then ok with items above that don't even come close to full parameterization?
index.html
Outdated
| It is highly encouraged that cryptographic suite identifiers are versioned | ||
| using a year designation. For example, the cryptographic suite identifier | ||
| `ecdsa-2022` implies that the suite is probably ok to use in the year 2025, | ||
| but might not be a safe choice in the year 2042. A date-based versioning | ||
| mechanism, however, is not enough by itself. All cryptographic suites that | ||
| follow this specification are intended to be registered | ||
| [[?VC-EXTENSION-REGISTRY]] in a way that clearly signal which cryptosuites | ||
| are deprecated, standardized, or experimental. |
There was a problem hiding this comment.
this whole approach seems to be implying that we want people to use "newer" as though that is better, and i am highly skeptical of this. I also do not want to be using cryptography or signatures selected by non-experts, or encourage non experts to make cryptographic selections.
There was a problem hiding this comment.
I also do not want to be using cryptography or signatures selected by non-experts, or encourage non experts to make cryptographic selections.
This happens today when people pick up and use kitchen sink cryptography libraries. Options are selected where the ramifications of those selections are not known to non-expert developers.
this whole approach seems to be implying that we want people to use "newer" as though that is better, and i am highly skeptical of this.
You might be thinking of the date in isolation. It is ONE tool in the tool chest, the other tools being vetted standards registries, sites like safecurves, and naming classes of cryptography suite. The suggestion isn't to name the cryptosuite 2022 and be done with it. The suggestion is to name the suite something like eddsa-2022 and eddsa-2029, where the latter has achieved some form of consensus as being "better" than the former.
There was a problem hiding this comment.
The suggestion is to name the suite something like eddsa-2022 and eddsa-2029, where the latter has achieved some form of consensus as being "better" than the former.
I would like to review the registry policy for handling this... If we can't agree to a registry process and confidence in the authority that maintains it, there is no reason to believe eddsa-2029 will be anything other than a very lucrative form of planned obsolescence.
Is the W3C the right place to maintain such a registry?
Will browsers implement all the registered suites, or only a single mandatory to implement one?
Why stop at eddsa why not non-repudiable-signature-2029?
There was a problem hiding this comment.
I would like to review the registry policy for handling this... If we can't agree to a registry process and confidence in the authority that maintains it, there is no reason to believe
eddsa-2029will be anything other than a very lucrative form of planned obsolescence.
This is being tracked in w3c/vc-data-model#909
There was a problem hiding this comment.
[[?VC-EXTENSION-REGISTRY]] in a way that clearly signal which cryptosuites
are deprecated, standardized, or experimental.
We should discuss the registry and its operational authorities and requirements, before adding language like this... who controls these status changes?
How do I deprecate a suite?
What counts as "standardized"?
Without more clarity on how the W3C will run the vc extensions registry I am concerned we are opening a large can of worms.
I'll note that this PR just refers to a registry that was created by the VCWG and already exists (and is in terrible shape): https://w3c-ccg.github.io/vc-extension-registry/
I agree that all of these are questions that the VCWG needs to answer. Would an issue marker noting that these questions need to be resolved track your concerns in a way that would unblock this PR, or do you require additional changes? |
An issue marker would work. |
I've raised an issue here: w3c/vc-data-model#909 That issue will be referenced in an issue marker in the current PR. |
There was a problem hiding this comment.
We should be relying on algorithm assessment by experts and not trying to do this ourselves. For instance, entries in the IANA JOSE Algorithms Registry https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms include not just a specification reference but an assessment of the status of the algorithm (Required, Recommended, Optional, Prohibited), etc. that can be relied on by us, rather than trying to reinvent this wheel.
Like @mprorock , I'm also highly skeptical that adding a year to an algorithm name adds actionable information. For one thing, you can determine the year anyway by following the registry pointer to the defining specification and looking at the spec date, if you care. Furthermore, you'll still have to consult the registry entry to determine whether the algorithm has been deprecated. A date isn't going to give you that. When something isn't useful, we should leave it out.
In this case it is even worse, as it may give the impression something is fine when it is not |
|
@msporny I'm fine approving this once the issue is merged into the spec text. |
|
@selfissued @mprorock your suggestion to only use the other registries won't work for all the data integrity cases... Since the "suites" that are being contemplated here are not limited to those registries... For JsonWebSignature2020, it would work to point directing to IANA... but that would not be exhaustive since IANA does not define URDNA2015 which JsonWebSignature2020 (and other suites) rely on... and I suspect the RCH WG at W3C will eventually define. What happens if we change the RDF Canonicalization in the future? JsonWebSignature2030 uses IANA registered JWS, but with a new URDNA2032 canonicalization algorithm. I don't see a way for folks to keep inventing new Data Integrity Suites without a registry that lets them talk about how they changed their canonicalization algorithm. If you aren't changing canonicalization, IANA in sufficient... assuming you are leveraging JSON or CBOR. |
None of this text asserts that we will be doing this ourselves. We will be looking to authorities like CFRG and NIST to define safe parameters for any given year.
Sure, and that's one input. Another input is the COSE Algorithms registry. Another input is the safecurves site (or updated versions of such a site). Yet another input is FIPS. None of these sources, however, discuss data transformation/canonicalization algorithms and thus we cannot purely rely on pre-existing identifiers because those do not encode additional things that this specification does. We will need new identifiers (that, at a minimum, will use existing approved crypto).
Are you asserting that most programmers go and read specifications or registries to determine if the cryptography that they're using is safe to use? Or do you think that they're more likely to copy-paste something off of stack overflow or a software library example? This specification is designing for the latter class of developers, not the former, because the former are not the ones that are responsible for most security vulnerabilities. Letting most developers choose cryptographic algorithmic parameters, or depending on them to educate themselves about the parameters is not as effective as ensuring that they cannot pick a wrong set of parameters in the first place. @OR13 wrote:
Yes that, AND what happens if we change the format or add parameters in the future? This isn't theoretical, in the past several years we've changed the signature value from using
A date will hint at whether or not what you're using might be out of date... a parameter does not do that in a universal way. A future PR to this specification will attempt to assert that libraries MUST throw an error if a deprecated suite is used. We may go as far to say that any suite older than X years should be automatically deprecated (as @ChristopherA has suggested multiple times)... but, again, that's for a future PR. The point here is that we are not going to depend on the date alone to accomplish the design goals of the Data Integrity spec -- we'll have multiple layers of protection to minimize the possibility of misuse of cryptographic suites. |
extremely helpful context - thanks |
| While this might be an inconvenience, it is one that results in safer | ||
| ecosystem behavior. |
There was a problem hiding this comment.
what about the case where they go find a newer one, that is similar, but not exactly the same and assume that newer means better when it may not in fact be better or might contain a flaw?
There was a problem hiding this comment.
I don't think any of the options here result in perfect outcomes. But we're looking for improvements over an existing system, not necessarily perfection. And it does seem like the case you're describing here is the least likely to occur and the most easily remedied, doesn't it?
I presume the cryptosuite you're describing is new, unrecommended, and non-standard. This is because the user in this scenario is only choosing based on the latest year. If it wasn't new, some other suite with a more recent year would be chosen avoiding the problem (or putting us into another case). If it was recommended, we could remove that recommendation status (or it wouldn't actually be a problem because it's properly recommended). If it was standard, we could update the standard and / or issue a newer cryptosuite that remedies the problem.
In other words, if the date-based scheme results in:
- Fewer people using crypto that's so old it is now unsafe.
- Fewer people combining crypto parameters in unsafe ways.
- Fewer implementation bugs because of less optionality.
- Fewer debates (in aggregate in the community) over which crypto params are safe / best to combine (do this only every few years when considering creating a new cryptosuite and ideally include in the spec the rationale behind the choices).
- More people becoming more aware that crypto has a shelf-life and requesting / performing more audits.
- More people using a new (and unrecommended / non-standard) cryptosuite that isn't as good as an older one (the case you describe, right?).
That seems to be, overall, a win vs. not doing it.
index.html
Outdated
| are deprecated, standardized, or experimental. Cryptosuite registration will | ||
| follow CFRG, IETF, NIST, FIPS, and safecurves guidance. Use of deprecated suites | ||
| are expected to throw errors in implementations unless a `useUnsafeCryptosuites` | ||
| option is used specifying exactly the unsafe cryptosuite to use. | ||
| Use of experimental suites are expected to throw errors in implementations | ||
| unless a `useExperimentalCryptosuites` option is used used specifying exactly | ||
| the experimental cryptosuite to use. |
There was a problem hiding this comment.
+1, but typo with repeated word: "used used".
There was a problem hiding this comment.
Typo fixed in latest PR.
|
@OR13 @mprorock @selfissued I have marked the type of versioning and extension registry governance items as issues in the spec text (instead of asserting them as conclusions). I have added text to note that other sources of cryptographic guidance should be cross-checked. AFAICT, there are now tracking issues for all of the items that each of you identified where there was an objection, which is where the debate can continue. I believe I have addressed as much as I can in this PR and am requesting a re-review now. |
| While this might be an inconvenience, it is one that results in safer | ||
| ecosystem behavior. | ||
| </p> | ||
| <p class="issue" data-number="38"> |
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
Co-authored-by: Mike Prorock <mprorock@users.noreply.github.com>
msporny
force-pushed
the
msporny-sc-versioning
branch
from
e617ce8 to
b1319da
Compare
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
This PR adds a security considerations section on versioning cryptographic suites and outlines some design rationale behind the date-identified suites that we currently have.
Preview | Diff