Add a Threat Model section
Closed this issue · 10 comments
Add a threat model section to the use cases document, including @ChristopherA's list of threats to think about.
Transcription of the whiteboard from TPAC discussion:
Coercion/consent threats may need to be added to the "traveler focal use case"
Points of consent in the use case:
- Rajesh consents for Anand to travel with Malathi
- Malathi consents to upgrade
- Agent consents to accept upgrade coupon and the credential from Rajesh
- Airline consents to accept agent's purchase of tickets in Malathi's behalf, and to accept upgrade request.
- Anand consents to travel with Malathi (as an 8 month old)
- TSA accepts presentation of ticket, passport, birth certificate, and permission
- All issuers consent to continued use of credentials
- Airport consents to allow plane to take off (accepts the aggregation of claims presented by all of the travelers).
Also discussed was the possible threat of systemic failure:
- DDOS/Hurricane
- systemic key compromise
- implementation failure (bugs and maliciousness)
- fraudulent verifiers
- MITM
- front-running of mile redemption to get upgrade (by airline, or by travel agent)
Below is a start at creating text to be inserted into the document. I've also attached the file. @msporny @brentzundel @David-Chadwick comments welcome.
I think this vulnerability review is far too wide. We clearly cannot do anything about anyone cutting the wire. I think a better approach is to say
These are the threats we are addressing
A
A
A
These are the threats we are not addressing
B
B
(preferably with a rationale for each)
Under B I would list things like chip failure, cutting the wire, hurricanes, faulty crypto etc. Everything that is beyond our control.
Under A I would list Doley Yao attacker, DDOS, untrustworthy verifier, untrustworthy holder, untrustworthy issuer, untrustworthy repository, untrustworthy id repository. That's about it.
I think that's a bit dismissive.
The fact is that for use cases that we advocate, there are threats for which the best answer is outside the technology. If we say VCs work in a particular use, we should illustrate the best response to the threats people will care about most. Many of those responses are in the human systems, NOT in the technology.
Anyone who adopts VCs without understanding the proper human systems that must be in play to realize the goals of the tech are stepping into a land mine. It doesn't help if we just say "There are land mines. We don't solve them". Rather, we should say "For these land mines, this is the best practice. In may not be sufficient for your needs, but you can make that decision based on the best known options at the time of writing this spec." The fact is, they may be able to improve on the best practice or they may agree that the best is the best, but it isn't good enough for their situation.
I would recommend putting these in the Threat Model section for the associated Focal Use Case, as and add the possible responses to that particular threat.
My post above from 9 days ago was not complete. The document attachment is complete, but the cut and paste text was not complete. Below is the complete cut and past, note the mention of an implementation guide.
Repost, with all of the text:
As @jandrieu noted above, we need to document best practices or guidelines for dealing with "land mines." This could be provided in a future implementation guide, or we can roll up our sleeves and provide more content now.
I understand @David-Chadwick when he states the scope is too broad. However, the goal of a threat model is to consider potential threats. How do we arbitrarily draw the line, and state the we will not consider some threats? Another benefit of threat models is to give implementators a reason to go deeper with security-by-design.
A reason to be complete and comprehensive with our threat model is to provide insight that might be meaningful for future threats, or combinations of threats that we can't predict today.
@jandrieu "I think that's a bit dismissive"
Not if you delve a bit deeper into what I wrote. For example, untrustworthy respository would cover every threat to the repository that meant it was not available to the user 24/24 and was not secure enough or privacy protecting enough. So it would cover threats such as: access to the repository is lost, repository (or its contents) are stolen, repository provider goes out of business etc.
So I re-iterate that we should only consider threats arising from or to components of our system: the subject, holder, issuer, wallet, verifier, registry; and we should not cover threats that are completely outside the control of every stakeholder (such as a JCB digging up the optical cable connecting us to the Internet). The components list covers both technology and human threats e.g. verifier is dishonest is a human trait, the software could be working 100% as intended.
@CipherQueen "the goal of a threat model is to consider potential threats." Not really. Furthermore it is impossible to be "complete and comprehensive". A threat with probability of occurrence of 0.0001% is a potential threat and might make our model complete, but we should not consider it (such as an asteroid might hit our issuer). I would rather say "the goal of a threat model is to consider realistic threats". Risk management is the balance between cost of protection and likelihood of loss arising. Spend too much on protection and you go out of business, spend too little and you go out of business.
So we cannot spend too much time on listing the complete and comprehensive set of threats as it would be a never ending task. We have to draw a line at what is realistic and reasonable.
@David-Chadwick my goal was to consider "categories" of potential threats. It is an ongoing process to consider all potential threats. You make a good point to consider "realistic" threats, but that is a difficult task, and open to subjectivity. We can do better by guiding implementers to cast a wide net.
I see the list follows the OSI Layers. For me 8. 9. and 10. should be on top like this:
10. 9. 8. then 1. and following OSI Layers.
This feedback was folded into the Focal Use Case section, where we did a deeper dive on three specific uses, addressing the threat model of each, without presuming to present a complete threat model (neither of a given use case nor of VCs in general)