Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Security Considerations section on Versioning Cryptography Suites. #36

Merged
merged 7 commits into from
Aug 27, 2022
Merged

Add Security Considerations section on Versioning Cryptography Suites. #36

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
21d37fb
Add section on versioning cryptographic suites.
msporny Aug 14, 2022
b01fb3c
Apply suggestions from @dlongley to suite versioning.
msporny Aug 17, 2022
410a290
Elaborate on parametric drawbacks.
msporny Aug 17, 2022
907d949
Note that cryptosuite version identifiers are under debate.
msporny Aug 18, 2022
aeec94d
Add issue about resolving VC Extension Registry Governance.
msporny Aug 18, 2022
d9a05f6
Fix language in crypto versioning issues.
msporny Aug 19, 2022
b1319da
Fix formatting for extension registry governance issue.
msporny Aug 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
111 changes: 111 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,6 +127,15 @@
],
status: "Internet-Draft",
publisher: "IETF"
},
"VC-EXTENSION-REGISTRY": {
title: "Verifiable Credentials Extension Registry",
href: "https://w3c-ccg.github.io/vc-extension-registry/",
authors: [
"Manu Sporny"
],
status: "CG-DRAFT",
publisher: "Credentials Community Group"
}
},
postProcess: [restrictRefs]
Expand Down Expand Up @@ -1768,6 +1777,108 @@ <h2>Security Considerations</h2>
<div class="issue">TODO: We need to add a complete list of security
considerations.</div>

<section>
<h3>Versioning Cryptography Suites</h3>

<p>
Cryptography secures information through the use of secrets. Knowledge of the
necessary secret makes it computationally easy to access certain information. The
same information can be accessed if a computationally-difficult, brute-force effort
successfully guesses the secret. All modern cryptography requires the
computationally difficult approach to remain difficult throughout time, which
does not always hold due to breakthroughs in science and mathematics. That is
to say that <em>Cryptography has a shelf life</em>.
</p>
<p>
This specification plans for the obsolescence of all cryptographic approaches by
asserting that whatever cryptography is in use today is highly likely to be
broken over time. Software systems have to be able to change the cryptography
in use over time in order to continue to secure information. Such changes might
involve increasing required secret sizes or modifications to the cryptographic
primitives used. However, some combinations of cryptographic parameters
might actually reduce security. Given these assumptions, systems need to be able to
distinguish different combinations of safe cryptographic parameters, also known
as cryptographic suites, from one another. When identifying or versioning
cryptographic suites, there are several approaches that can be taken which
include: parameters, numbers, and dates.
</p>
<p>
Parametric versioning specifies the particular cryptographic parameters that are
employed in a cryptographic suite. For example, one could use an identifier such
as `RSASSA-PKCS1-v1_5-SHA1`. The benefit to this scheme is that a well-trained
cryptographer will be able to determine all of the parameters in play by the
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. Additionally, this lack of knowledge might lead software
developers to generalize the parsing of cryptographic suite identifiers
such that any combination of cryptographic primitives becomes acceptable,
resulting in reduced security. Ideally, cryptographic suites are implemented
in software as specific, acceptable profiles of cryptographic parameters instead.
</p>
<p>
Numbered versioning might specify a major and minor version number such as
`1.0` or `2.1`. Numbered versioning conveys a specific order and suggests that
higher version numbers are more capable than lower version numbers. The benefit
of this approach is that it removes complex parameters that less expert
developers might not understand with a simpler model that conveys that an
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. Ideally, additional signals would be given to developers that use
cryptographic suites in their software that periodic reviews of those
suites for continued security are required.
</p>
<p>
Date-based versioning specifies a particular release date for a specific
cryptographic suite. The benefit of a date, such as a year, is that it is
immediately clear to a developer if the date is relatively old or new. Seeing
an old date might prompt the developer to go searching for a newer
cryptographic suite, where as a parametric or number-based versioning scheme
might not. The downside of a date-based version is that some cryptographic
suites might not expire for 5-10 years, prompting the developer to go
searching for a newer cryptographic suite only to not find one that is newer.
While this might be an inconvenience, it is one that results in safer
ecosystem behavior.
Comment on lines +1842 to +1843
Copy link
Contributor

@mprorock mprorock Aug 18, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

</p>
<p class="issue" data-number="38">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good enough for me.

The following text is currently under debate:<br><br>
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 an acceptable of ECDSA 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. 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 specifying exactly
the experimental cryptosuite to use.
</p>

<p class="issue" title="Resolve VC Extension Registry Governance">
The following text is debated due to the governance rules of the VC
Extension Registry not being finalized:<br><br>
Developers are urged to always refer to the [[?VC-EXTENSION-REGISTRY]] for
the latest standardized cryptography suites as well as cross-checking their
usage against, at least, the
<a href="https://www.iana.org/assignments/cose/cose.xhtml#algorithms">
COSE Algorithms Registry</a>, the
<a href="https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms">
JOSE Algorithms Registry</a>, and the latest
<a href="https://csrc.nist.gov/publications/detail/fips/186/4/final">
FIPS Digital Signature Standard
</a> guidance. Depending on your jurisdiction you may also need to consider
additional guidance from
<a href="https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.02.01_60/ts_119312v010201p.pdf">ETSI</a>
or other regional regulatory and standards bodies.
</p>
</section>

<section>
<h3>Verification Method Binding</h3>

Expand Down