[Cryptography] Making models + scenarios realistic

[Phillip Hallam-Baker]

On Mon, Apr 15, 2019 at 4:31 PM Ralf Senderek <crypto at senderek.ie> wrote:

> On Sun, 14 Apr 2019, John Denker via cryptography wrote:
>
> > Again:  The scenarios are absolutely necessary but they are
> > not the only hard part, or even the hardest part.  One must
> > also have a sharable understanding of what the security
> > model is /supposed/ to do.  Scenarios can be used to test
> > understanding, but they do not create understanding.
>
> And that's why I've asked for a threat model for the MESH.
>

The Mesh is infrastructure. The threat model for infrastructure is not the
same as the threat model for applications. It is not even clear to me that
there should be a threat model for infrastructure. It is probably better to
think in terms of security considerations because requirements inevitably
conflict.

The risk of generalizing scenarios is that the details may be the important
part. The reason I specified Alice was 4'11" was because I wanted to point
out that she was physically very much smaller than Bob and that is likely
to be very significant for a scenario in which they are attempting to have
casual sex without anyone else finding out without the risk of either rape
or an axe murder.

It is very tempting to look for the 80/20 rule and try to find the middle
path. But the problem is that none of us is normal. Attempts to find a
family that matches the 'average' on more than a handful of counts (average
income, average number of children, etc) quickly results in nobody
matching. Human populations are diverse and so are their security
requirements.

Whenever I make a protocol suggestion, the counter-arguments that are
invariably made have to do with limited access in rural African communities
using obsolete equipment from the 1970s. This despite the fact that there
is probably not a single Vax 11/780 in operation on the entire continent
that is not kept as a collector's piece. Obsolete infrastructure
accumulates in the places where the infrastructure was first deployed. More
recent deployments leapfrog to the newest technology.


So I think it important that infrastructure be neutral with respect to the
assumptions it makes about security tradeoffs. We all face the same CIA
triad but the concerns are very different depending on who you are.

Confidentiality is almost invariably over-prioritized. Unless you happen to
be a field agent engaged in espionage, Integrity trumps Confidentiality and
Availability trumps both. And if you are a field agent, your need for
confidentiality is so great that you require steganography as well as
encryption.

The main reason I don't use data encryption as much as I might is because I
do not trust the recovery systems. The risk that someone might view
confidential material is a lot less important to me most of the time than
the risk I might lose the data. So personal escrow has to be a tool that is
available in an infrastructure to manage key pairs for personal use.

The chief concern in the escrow department is coercion. If I set up a key
escrow scheme for my use, I can be coerced into revealing the data. Is that
something I want to risk or not? That is my decision and mine alone and my
user's decision and their's alone. It is not for me to presume to
understand their security concerns so fully as to decide them for them. I
can help them make an informed decision and I can establish infrastructure
which ensure that third parties that they may decide to rely on are held
accountable for their actions. But it isn't my place to live their lives
for them any more than it is my place to suggest to Alice and Bob that
their affair is a really poor choice on both their part but especially on
Bob's part because Alice is a psycho with an axe under her bed for Odin's
sake.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190416/9b6bee81/attachment.html>