Review of Security Considerations #36
Conversation
Remove several extremely contentious and void-for-vagueness paragraphs in order to improve the Security Considerations section. > Pay very close attention to the defense, cryptographic agility, > and political acceptability of any cryptography you rely on for > DID Method security. What is the defense of a cryptography? What is cryptographic agility? In which part of the world should I gauge political acceptability? Remove paragraph. > Competition, direct substitutability, interoperability, and mutual > feature support are key to reducing the barriers to adoption of, > and increasing confidence in, your DID Method. How does competition reduce the barriers to adoption of your DID Method? How does competition increase confidence in your DID Method? What is direct substitutability? How does direct substitutability reduce the barriers to adoption of your DID Method? How does direct substitutability increase confidence in your DID Method? What is interoperability? Does it mean that your DID Documents comply with the DID Core v1.0 spec? Does it mean that another app can get a DID Document when given a DID from your DID Method? That would mean someone included your library in their app, or they were able to read your DID Method spec and reimplement. And that could have been a well-known resolver, so that anyone can get the DID Document with a simple HTTP query. What is mutual feature support besides complying with the DID Core v1.0 spec in order to allow interoperability? There is already an entire section titled "Method Reuse is Encouraged". Remove paragraph, rename subsection. > Avoid hard coupling to specific networks, such as Bitcoin or > Hyperledger Fabric. Design your method such that it may be > adapted to support multiple ledger systems. The notion of "cross-chain" IDs is not compatible with updating and revocation. Supporting those - ahem, required features - would in turn require code (and storage) to actually follow transactions on every cross-chain VDR. If an app developer or browser maker had libraries for certain VDRs, then they might as well use the native DID Methods for those VDRs. As things exist now, minor DID Methods will see interoperability when supported via popular resolvers. Remove paragraph. > Avoid secp256k1, RSA, P-256, P-384 and P-521. No. Remove advisement. > Avoid relying on smart contracts for complex data management. If > you must use a smart contract, keep it simple and architect a > solution that supports data migration. What are smart contracts? Why should they not be relied on? What is data migration in a smart contract setting? What is a simple smart contract? Remove paragraph.
| <section class="informative"> | ||
| <h3>Vendor Lock In</h3> | ||
| <p> | ||
| Competition, direct substitutability, interoperability, and mutual |
There was a problem hiding this comment.
@rxgrant can you provide reasoning for removing this? its a specific concern voiced by many of our customers and I know other working group members care deeply about it.
There was a problem hiding this comment.
How does competition reduce the barriers to adoption of your DID Method?
How does competition increase confidence in your DID Method?
What is direct substitutability?
How does direct substitutability reduce the barriers to adoption of your DID Method?
How does direct substitutability increase confidence in your DID Method?
What is interoperability? Does it mean that your DID Documents comply with the DID Core v1.0 spec? Does it mean that another app can get a DID Document when given a DID from your DID Method? That would mean someone included your library in their app, or they were able to read your DID Method spec and reimplement. And that could have been a well-known resolver, so that anyone can get the DID Document with a simple HTTP query.
What is mutual feature support besides complying with the DID Core v1.0 spec in order to allow interoperability?
These questions are great! Answers to them would be better than removing this section.
There was a problem hiding this comment.
My conclusion is that it's a broken idea that shouldn't be used to recommend anything, so the paragraph should be removed.
There was a problem hiding this comment.
I don't agree, and I would guess @msporny @mprorock @peacekeeper and others would also agree with me, but certainly I am willing to be convinced by arguments.
There was a problem hiding this comment.
@OR13 I think it's back to you to defend why you think an idea with so many problems should be in the Guide. The Guide is not an open season opinion section that tries to add lines.
Everyone was warned earlier that "Festivus-like" editorial criteria ("include anything that anyone wrote, regardless of its technical merit") will act to the detriment of the working group.
| </p> | ||
|
|
||
| <p> | ||
| Avoid hard coupling to specific networks, such as Bitcoin or |
There was a problem hiding this comment.
This would seem to be sound engineering advice, build an architecture that is portable, and can gain the security / cost benefits of various registries it is anchored to... thats part of why Microsoft built ION on top of Sidetree and not as a standalone method.
There was a problem hiding this comment.
The notion of "cross-chain" IDs is not compatible with updating and revocation. Supporting those - ahem, required features - would in turn require code (and storage) to actually follow transactions on every cross-chain VDR. If an app developer or browser maker had libraries for certain VDRs, then they might as well use the native DID Methods for those VDRs. As things exist now, minor DID Methods will see interoperability when supported via popular resolvers.
This paragraph is not arguing what you think it is, but perhaps you can improve it by focusing on portable architectures instead of identifiers?
There was a problem hiding this comment.
I've improved the unclear writing with advice contradictory to actual interoperability by removing it.
There was a problem hiding this comment.
This would seem to be sound engineering advice, build an architecture that is portable, and can gain the security / cost benefits of various registries it is anchored to... thats part of why Microsoft built ION on top of Sidetree and not as a standalone method.
Nope. I explained in the comment to the pull request that you don't gain anything because you have to reimplement all the tip-folllowing of your VDR.
Further, you're confused about what ION is. Its Sidetree is not anchored on multiple VDRs, it's anchored only on Bitcoin's blockchain.
There was a problem hiding this comment.
It's impractical (as you noted, Orie) to leverage several substrates at once, so at minimum we should change the language to something like "Try to construct DID Method that can be migrated to different event record substrates to ensure forward network agility"
There was a problem hiding this comment.
Can we all agree to stop using the word "substrate" when the DID specification defines the term "verifiable data registry"... specifically folks should know the terms we define in the spec and use them consistently, and avoid promoting alternative terms that are not well defined and that lead to confusion.
There was a problem hiding this comment.
@rxgrant I wrote the sidetree spec with @csuwildcat , ION is just one method on it... its still sound advice to use interfaces with classes when you want portability... Sidetree is an interface, ION is a concrete method that implements it, that ION is built on sidetree is a positive, and that sidetree is not "blockchain specific" is a positive.
There was a problem hiding this comment.
@OR13 I understand that you are interested in DID Methods that do not depend on a VDR, but you don't have consensus for recommending that idea when the recommendation says that DID Methods not using the idea are worse. It is avant-garde and has downsides.
The first downside you replied to here:
This paragraph is not arguing what you think it is
...by saying that it's not a way to interpret the advice. However, SpruceID/did:did tried to do exactly that, and fits the described advice perfectly. It has exactly the problems I outlined.
A second downside is that whenever your DID Method might switch VDRs, then any security that is dependant on the VDR must be reevaluated. You have, for all practical purposes, a new DID Method that your users should reconsider.
A third downside is that some of the best key management can be natively tied to a financial asset recovery in a valuable blockchain, in a way that no centralized VDR can match. The value at risk makes the user more careful, and more willing to go through the steps that will result in a more secure DID.
A fourth downside is that (very rarely) there is a blockchain that makes a more stable VDR than any that the developers of a DID Method could fire up themselves. In that rare case, locking into the VDR increases the security of the DIDs.
A fifth downside is that "interfaces with classes" is a fuzzy analogy that does not apply.
Advocacy of avant garde design ideas belongs in Rubric reviews of DID Methods, where you sign your name on the review - without any sign of approval by the consensus of the group - and where I have ample opportunity to respond with pointers to this thread.
| SP 800-56A Rev 3</a> when evalutating curves for use. | ||
| </p> | ||
|
|
||
| <p class="advisement">Avoid secp256k1, RSA, P-256, P-384 and P-521.</p> |
There was a problem hiding this comment.
Are you aware of the problems with these curves?
I can see maybe trying to argue with one or the other, but removing the entire advisement is not helpful.
There was a problem hiding this comment.
SafeCurves, as I read it, is saying that some of these curves have chosen constants that make correct library implementation a tricky proposition for cryptography, which as far as I can tell they separate from signing security. If someone wants to pen a message that echos that complaint about various curves with certain constants as weaker library implementations might be affected, then they should take ownership of their own words.
However, it is completely wrong for the implementation guide to say, without giving any clear reason, "Don't use this curve."
There was a problem hiding this comment.
https://crypto.stackexchange.com/questions/68269/does-secp256k1-have-any-known-weaknesses/68316
Q: "Does secp256k1 have any known weaknesses?"
on | 2019-03-24
Matt
[...]
Edit: I have found this website
http://safecurves.cr.yp.to/index.html
which states that the curve does NOT satisfy all of the
safety requirements for that website - however I am unable
to understand the parameters under which it is considered
not safe, and explanation on this would be nice too thanks
:)
Mx. Squeamish Ossifrage
secp256k1 fails the following SafeCurves criteria, but it
doesn't matter for Bitcoin's use of secp256k1:
- CM field discriminant. secp256k1 is a Koblitz curve
that admits a fast endomorphism for speeding up scalar
multiplications. There is no particular vulnerability
here: the same speedup you get in computing with
secp256k1, an adversary gets in trying to break it, but
that won't, in itself, render an infeasible attack
feasible. (This is what the ‘few bits weaker security'
refers to.)
SafeCurves conservatively rejects this because it is an
additional structure that could be the foundation of
future breakthroughs in cryptanalysis, but nobody has
made that breakthrough and we have little reason to
suspect it's going to happen sooner than any other
unpredictable cryptanalytic breakthroughs.
- Ladders. secp256k1 does not admit the fast Montgomery
ladder to compute 𝑥-restricted scalar multiplication in
constant time; it does admit the much slower Brier–Joye
ladder.
[...]
This is relevant mainly for applications doing
Diffie–Hellman, but Bitcoin itself does not use
secp256k1 for Diffie–Hellman [...]
- Completeness. secp256k1 does not admit the fast
complete Edwards formulas to compute elliptic curve
addition in constant time; it does admit the much slower
complete Weierstrass formulas to compute elliptic curve
addition in constant time.
[...] So this poses more of a danger for the victims of
novice implementors in novel scams; as long as you use
libsecp256k1 and don't try to rewrite it at home, this
doesn't pose a security problem.
Greg Maxwell
[...] The safecurves "Completeness" and "ladders" criteria
both indirectly require the presence of a cofactor but it
never mentions [the presence of a cofactor as inherently
including a security trade-off that caused a total break in
one family of cryptocurrencies],
https://jonasnick.github.io/blog/2017/05/23/exploiting-low-order-generators-in-one-time-ring-signatures/
"Exploiting Low Order Generators in One-Time Ring
Signatures"
on | May 23rd, 2017
so I think this is the best example of how that resource is best
considered marketing copy rather than an earnest attempt at
scholarship.
Arguments that it's somewhat more complex to write constant
time code for secp256k1 than ed25519 seem pretty subjective
to me: many ed25519 implementations fail to be constant
time, and constant time code exists for secp256k1. At the
end of the day using naively written low level cryptographic
primitives is a bad idea regardless of the curve, and if
you're using well developed code this isn't an issue. [...]
There was a problem hiding this comment.
@rxgrant @csuwildcat instead of deleting this paragraph, why not add a recommendation to support secp256k1 and RSA based on the comments you have made here.
There was a problem hiding this comment.
I'm personally swayed by your arguments in favor of RSA, secp256k1, assuming they can be documented...
There was a problem hiding this comment.
I think Safecurves is marketing material at this point. Why do you think it's a good resource for saying anything about P-256, P-384 and P-521?
There was a problem hiding this comment.
complaints about them are pretty well known at this point... https://news.ycombinator.com/item?id=6393828
Prefer conventional discrete-log-based systems
over elliptic-curve systems; the latter have
constants that the NSA influences when they can.
If folks don't agree with this advice, they should explain why they think its not appropriate and let implementers choose... at least that was the intention behind the original text... I take it as a given that there are concerns with NIST curves at this point in my carrier, but I don't necessarily think those concerns are necessary absolute... I have worked with these curves a lot... I don't dislike them, but given the choice I tend to avoid them in favor of ed25519 / x25519.... also, this advice probably changes over time... there was a time when RSA was probably the only reasonable solution.
I guess I am trying to get round to, what kind of advice would you give, anything in IANA is fair game:
There was a problem hiding this comment.
Looking at this section of the document:
https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve
The relevant list of curves is: P-256 Curve, P-384 Curve, P-521 Curve, Ed25519 signature algorithm key pairs, Ed448 signature algorithm key pairs, X25519 function key pairs, X448 function key pairs, and SECG secp256k1 curve.
I take it as a given that there are concerns with NIST curves at this point
There are definitely legit concerns with how some curve constants were chosen. However, we can't say anything about all ECC curves, because some of them (secp256k1 being particularly notable to this discussion), were chosen with NUMS.
Safecurves is quite possibly right about some curves given some implementations, but the resource has the problems cited above (restating what I can read in the reviews of others: it is not wrong to care about what it points out as issues, but it is wrong to be biased about concerns to include; and fails to consider leading implementations).
I have no evidence to disrecommend ed25519 for its intended uses or to recommend curves P-256, P-384, and P-521. I think it's back to the authors of this section to parse out what to say about P-256, P-384, and P-521, speaking to the caveats of relying on Safecurves. I do think that any mention of Safecurves should point out loud and clear that it's just plain wrong about the leading software implementation of secp256k1.
As for advice to prefer ed25519, I think it is more robust for submissions in the Guide to bias towards citing resources rather than appearing as crypto experts. What curve to use depends on many things, including available hardware implementations. I don't think that the resources cited so far are sufficient to boil things down to an advisory box.
Quoting Safecurves and Schneier in their specific concerns would be less unfounded, but even then we should point out where we know their advice not to apply. If an advisory box stated that Safecurves has some concerns to consider, that Safecurve is a partially-discredited resource, and that its advice on secp256k1 is particularly bad, then the reader could be left to figure out what to do about P-256, P-384, and P-521.
| <p class="advisement">Avoid secp256k1, RSA, P-256, P-384 and P-521.</p> | ||
|
|
||
| <p> | ||
| Avoid relying on smart contracts for complex data management. If you |
There was a problem hiding this comment.
@rxgrant please justify why you think this guidance should be removed.
There was a problem hiding this comment.
No.
Remove advisement.
This comment is unhelpful.
There was a problem hiding this comment.
What are smart contracts?
Why should they not be relied on?
What is data migration in a smart contract setting?
What is a simple smart contract?
I suggest you focus on reducing ambiguity not removing text you / others might not fully understand.
There was a problem hiding this comment.
Secp256k1 is a fine curve that is built into many devices. It was chosen for specific security reasons that apply in circumstances where it is needed. It does not use pairing crypto, which is considered unproven in many cryptographic communities.
RSA is tried and true, and is built into many devices. I stopped there. Why is this document advising against them? The burden of proof is on the document to explain itself.
There was a problem hiding this comment.
Secp256k1 is arguably the most battle tested cryptographic formulation in human history, so I certainly would not advice against its use - if anything, you could argue more strongly that it should be considered for use.
There was a problem hiding this comment.
<p>
Avoid relying on smart contracts for complex data management. If you
must use a smart contract, keep it simple and architect a solution
that supports data migration.
</p>
I don't see anything wrong with this advice... smart contracts and the blockchain version of "identity tokens signed by major IDPs".... the more you use them, the more you are owned by that IDP / blockchain.... using them less is sound advice.
Let's imagine offering the alternative: "Use as many features of ethereum as possible so that your DID method is only portable to EVM based blockchains"... see why thats a less desirable implementation state to be in?
There was a problem hiding this comment.
@OR13 Thanks for redirecting to the rest of the highlighed text. Please try to make highlights about one topic in the future.
The thing wrong with this advice is that you are again assuming that blockchains are bad VDRs, that should be abstracted away. They are good VDRs to design closely to, as well. It depends on the goals of the DID Method.
Another thing wrong with the advice is that it does not actually say that it applies only to using Ethereum features. It applies to native features on any blockchain, all of which (unless they made effort to remove the idea) inherited scripting languages built in. Every Bitcoin transaction is a smart contract, by some definitions.
You do not have consensus to say that the original idea for a blockchain DID Method is a bad idea to be avoided. It is a good idea.
There was a problem hiding this comment.
You do not have consensus to say that the original idea for a blockchain DID Method is a bad idea to be avoided. It is a good idea.
Do you think you could formulate this an opposing view, like "blockchain based did methods are a good thing"... we have many cases of this in the implementation guide already... I would not object to a counter argument that strongly supported your view.
There was a problem hiding this comment.
I think in this case presenting both sides of the argument is a fine exercise that could educate readers. But I wonder if the thread could be developed more fully as a rubric criteria, and then its wisdom applied to all DID Methods. The task would be to narrow down the harms and benefits of both design philosophies into specific nameable parts that can be judged.
I'm willing to keep working on naming the issues in any thread, including here.
Can you give me a specific list of harms that smart contracts bring?
Does this all boil down to your philosophy on VDR migration while maintaining the same DID? I see signing a VC saying, "Hey I have a new DID" as the solution if a VDR fails. Along with, of course, not chosing a bad VDR in the first place!
There was a problem hiding this comment.
Can you give me a specific list of harms that smart contracts bring?
These come to mind:
- Increased difficulty when auditing DLT source code.
- Increased attack surface as a result of arbitrary code execution.
- Increased attack surface due to smart contract language design bugs.
- Increased attack surface due to badly implemented/reviewed smart contracts.
- Increased attack surface due to potential interaction (voluntary or involuntary) between more than one smart contract.
I'm sure there are more, but those popped into my mind while I was responding here.
|
interesting behavior on branch rename. restoring. |
Thanks to Orie for pointers to discussion on this.
Yes. |
mprorock
left a comment
mprorock
left a comment
There was a problem hiding this comment.
I would like this PR broken up section by section so each item can be dealt with individually. I am strongly opposed to removing guidance around selection of strong hash or crypto mechanisms
|
I agree with the previous comment that it would be helpful to split this up into multiple PRs. There are several different topics that seem unrelated, e.g. smart contracts, vendor lock-in, etc. I agree with some of @rxgrant 's comments, e.g. it feels strange that there is a statement "Avoid secp256k1, RSA, P-256, P-384 and P-521." without further explanation. I also agree with @OR13 's comments that it would be preferable to add additional explanation, or alternate viewpoints, rather than simply removing things. |
|
"Avoid the most battle tested curve in the history of cryptography that has withstood a multi-hundred billion dollar bug bounty for the better part of a decade" - my reaction:
|
6 participants
Remove several extremely contentious and void-for-vagueness paragraphs in order to improve the Security Considerations section.
What is the defense of a cryptography?
What is cryptographic agility?
In which part of the world should I gauge political acceptability?
Remove paragraph.
How does competition reduce the barriers to adoption of your DID Method?
How does competition increase confidence in your DID Method?
What is direct substitutability?
How does direct substitutability reduce the barriers to adoption of your DID Method?
How does direct substitutability increase confidence in your DID Method?
What is interoperability? Does it mean that your DID Documents comply with the DID Core v1.0 spec? Does it mean that another app can get a DID Document when given a DID from your DID Method? That would mean someone included your library in their app, or they were able to read your DID Method spec and reimplement. And that could have been a well-known resolver, so that anyone can get the DID Document with a simple HTTP query.
What is mutual feature support besides complying with the DID Core v1.0 spec in order to allow interoperability?
There is already an entire section titled "Method Reuse is Encouraged".
Remove paragraph, rename subsection.
The notion of "cross-chain" IDs is not compatible with updating and revocation. Supporting those - ahem, required features - would in turn require code (and storage) to actually follow transactions on every cross-chain VDR. If an app developer or browser maker had libraries for certain VDRs, then they might as well use the native DID Methods for those VDRs. As things exist now, minor DID Methods will see interoperability when supported via popular resolvers.
Remove paragraph.
No.
Remove advisement.
What are smart contracts?
Why should they not be relied on?
What is data migration in a smart contract setting?
What is a simple smart contract?
Remove paragraph.
Preview | Diff