Re: [saag] Direct trust between users

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Apr 24, 2019 at 2:26 PM Nico Williams <[e-mail]> wrote:

> On Wed, Apr 24, 2019 at 01:56:40PM -0400, Phillip Hallam-Baker wrote:
> > So we have an assertion that my public key is MC23-... dated 2019-Jul-18.
> > It would have cost $1000 to forge that assertion before that date and
> > $infinity to forge afterwards.
>
> 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.

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.



> 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.

> 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.

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.



> > 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.

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.


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.

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.