Re: [saag] Direct trust between users

[Nico Williams <[e-mail]>]

On Wed, Apr 24, 2019 at 05:40:58PM -0400, Phillip Hallam-Baker wrote:
> On Wed, Apr 24, 2019 at 2:26 PM Nico Williams <[e-mail]> wrote:
> > ISTM that it's $1000 (or whatever) the first and _every_ time.  That's
> > because the blockchain will have to support the "help, I've lost my one
> > and only device!" or "help, I've lost all my devices!" cases.
> 
> It would be if I had not designed the Mesh key management system to address
> precisely that type of issue.
> 
> There are some constraints I cannot escape. If I provide you with a
> guarantee that you will be able to recover your keys in all possible
> circumstances I must also expose you to the risk of coerced disclosure of
> your key.

Indeed.

> I cannot eliminate such choices but I can mitigate them and I can give the
> choice to the user rather than to me. It is not my place to decide what my
> user's security concerns are for them. My security concerns are not the
> same as most people's.

For most users recovery is more important than non-coercibility,
especially since non-coercibility can only be had in the all-devices-
lost-or-destroyed scenario.

> > E.g., you're on a plane that lands on the Hudson river and you have to
> > leave everything behind, including your laptop, tablet, and phone, and
> > you're thousands of miles away from your desktop device or backups.
> > Now, you could just cancel everything and fly home (after drying up
> > anyways), but this may be very costly in time and money so you probably
> > won't want to.
> 
> OK so there is the approach in the docs and there is the improved approach
> I am thinking about that uses key co-generation that I have not yet
> implemented.
> 
> Basically, the Mesh has always allowed users to escrow their long term
> master signature key. This is precisely because the cost of this type of
> loss is unacceptable. I do not used the disk encryption features on any of
> my machines at present because I do not trust the key recovery systems and
> the loss of my data is far more of a concern to me than disclosure.
> 
> So the revised version I am considering is that instead of escrowing the
> user's master signature key, I generate a new master key, escrow that. and
> sign it in the master profile. This means that I can regain control of the
> account if I lose my master signature key but the fact that I have done
> this will be visible because I will have to post a new Master profile.

It will be visible because you'll _use_ the new master key (you might
not elect to post a new new master key).

> > The simplest user experience to implement would be to have an app for
> > > mobile devices that can be used to scan a dynamic QR code presented on a
> > > screen near the registration desk. This would provide the necessary
> > crypto
> > > info to complete the key signing.
> >
> > We're assuming trusted devices, but we practically have to anyways, so,
> > sure.
> 
> Given enough epicycles, I can save this appearance.

It was just Security Considerations material, not an exhortation to do
better (you can't).

> As a matter of course, every interaction can be traced to an individual
> device by the owner of the profile. At present the interactions can be
> traced back to a device by everyone else as well and I am not sure that I
> like that. I have one scheme in mind that can mitigate that but I really
> need some crypto folk to advise.

Anonymity and pseudonymity can be version 2 features.  In fact,
pseudonymity can be had immediately by allowing the user to have
multiple distinct key sets, and even overlapping device sets.

Anonymity can then take the form of ephemeral pseudonyms, perhaps,
though since the whole point is to be able to securely communicate *more
than once*...  anonymity can't really be had!

We can't reduce the metadata footprint of communicating users, not
really (sure, users can go use onion routing, but good luck with that).
I'm not too concerned about traceability, though it is a Security
Consideratum.

> > > We could go further and make it so that scanning the QR code tells the
> > > attendee which line to join and causes the registration staff to be told
> > > which badges to find next. The registration staff could then check
> > > government issued ID, hand over the badge and tell the system the ID
> > > matched.
> >
> > The ID check is not going to be that good.  As with PGP, having
> > something of a key signing party where people who know you vouch for you
> > (and vice-versa) seems better.  This is where a notion of security level
> > starts creeping in: do I trust the IETF registrar more than I trust an
> > IETF participant I've known for decades?  If I do take the registrar's
> > say-so at face value and have N>100 interactions with you where I have
> > every reason to think it's you every time, does the security level go
> > up, and do I get to say that or does it happen automatically?
> >
> 
> What I sketched out is a validation process. Just as we have multiple
> validation processes for WebPKI certificates, we can have multiple
> validation processes for this as well. And the assertions produced can
> specify the validation process that was followed.

And validators get sloppy.  The point is that while you want a simple
UI, the moment you look into a range of trust, the UI gets more complex.
It may be that a boolean is all we can really hope to get.  Perhaps you
can hide a range (and details) behind the boolean indicator.

What's the right answer?  I don't know, but I do like the idea that
regardless of how you hopped onto the mesh, once we've had a bunch of
interactions I can then say I trust you more than I could have trusted
any ID validation you went through at enrolment time.

> Conference registration desk is one place we could validate. The reception
> is another. And if you think about it, going round bumping phones to
> exchange contacts sounds a bit like an ice-breaker activity.

Definitely.  For the tech community conferences as a incidental key
signing parties can be a tremendous facilitator; with network effects
you should be able to get a huge number of users very quickly.  It just
has to be trivial to install the app and enrol.

(Eventually this really needs to be a function of the device's OS, and
you'll need to be able to let third party apps use (but not see) the
keys.)

Conferences would be the obvious place to start advertising this.

> If we were going to apply this outside the tech community, the validation
> process is going to have to be run by someone who knows what they are
> doing. They will in effect be a cyber notary. And if someone was going to
> do this at an ABA meeting, they would want to charge them for it. Bigly.
> And if it provided value, the ABA would want to pay.

With an option for non-meatspace identity the cost goes to zero, but you
have to accept TOFU or WebPKI / DANE introducers.  E.g., if I send you
email signed with a key whose certificate is issued by my domain and
which is issued by a WebPKI CA and/or is published in a TLSA RR in
DNS(SEC) then you can be reasonably certain that the email came from a
device that is authorized to send email with that sender address.

Even in a TOFU case, if one peer is non-TOFU then a couple of round
trips should suffice to bind the device set keys to the TOFU peer's
address in an MITM-proof way.  The TOFU peer might be an impersonator,
but over a long period of time and after many interactions you can
conclude that they are not being impersonated.

> One of the reasons SSL/TLS took off and other Internet security protocols
> did not was that there was an industry that was invested in making it take
> off and marketing the use of crypto. They got greedy when it got to S/MIME
> but the WebPKI worked. If I train a hundred people to work as conference
> cybernotaries they would 1) provide some quality control and 2) spend time
> cold calling conference organizers offering to provide the service.

I'm a bit skeptical about notaries.

Long long ago I used to imagine the U.S. postal service selling what you
might call EV user certificates: after all, there are post offices
everywhere and their staff are trained in validating government-issued
IDs, often they're even notaries public!  I supposed one might even be
able to get attribute certs attesting that the holder of the key is,
e.g., a citizen, or over 18 years of age.

Another likely candidate, one that is perhaps easier to get involved,
though they are not as convenient for users, is the DMV...

But why did this not happen??  Did anyone even try?  Would you?  How
would one make it happen?  How much can be done without having to hire a
lobbyist to lobby Congress or 50 State legislatures?  Has this been done
outside the U.S.?  If so, was it a success?  If so, can that be used to
make it happen elsewhere?

For example, suppose you gave away to the postal service cheap devices
for use at post offices for the purpose of enrolling users, then let the
postal service charge a fee for providing the service, with you keeping
either a nominal portion or even none of the fee.  What would be the
legal barriers to making that happen?

Upside: you won't need to train their employees in how to validate IDs.

Downside: risks being more of a political than business relationship.

Nico
--