Subject: [saag] Direct trust between users

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Apr 2019 13:56:40 -0400

Nico asked about the Mesh Trust model and I said that I was trying to avoid
imposing one. I do have metrics for measuring the quality of trust
established in terms of a work factor however:

http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html

This is not a computational work factor as we are used to. It is a social
work factor nominally denominated in currency (USD) and bounded in time.

Let us say that we did some key signing even open to IETF meeting attendees
only. It would cost an attacker $325 plus travel minimum to impersonate me.
Not an impossible sum if they really really want to impersonate me but
enough to stop a large number of attacks. Furthermore, there is a
significant risk of being caught if they attempt the impersonation on any
large scale. So the social work factor might be $1000.

Now lets enroll the assertion provided in a blockchain. We don't need proof
of work to do blockchain. All we need to do is to have multiple notaries
and cross certify between them so that the work factor of each notary
reaches the sum of the work factors of all the blockchains on the planet
within 24 hours. People can do proof of work if they like but nobody can
exceed the work factor of the metanotary because we will add their output
to the metanotary as an input.

I think we can assume the social work factor for metanotary.com is infinity.

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.

That seems like a useful building block to incorporate into a system of
trust. It is not going to be possible to use that approach in every
situation but we can almost certainly use it in many situations.

So why might we want to do key signing at IETFs?

Well we write code and some of that code ends up on GitHub and makes its
way into software used in the wild. So credentialling IETF-ers would be
pretty useful. Credentialling the Linux Plumbers etc. is probably even more
useful. Probably a good thing if we could do something at Black Hat or RSA.

We could probably deliver a real improvement in the robustness of the
Internet software development ecosystem if we produced a system serving
10,000 or so users and was never used by outside that community.

So how might it work?

I have done a few sketches but I haven't come to a firm conclusion on how
to realize the crypto yet.

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 24 Apr 2019 13:26:42 -0500

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

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.

> 10,000 or so users and was never used by outside that community.

I agree with this.

> to realize the crypto yet.

It's a PGP-alike with a blockchain and with keyservers that participate
in the blockchain, and a few very popular people (or conferences, or
even large corporations) who act as notable notaries.  Without a work
factor this is a like like a distributed Merkle hash tree.

> info to complete the key signing.

We're assuming trusted devices, but we practically have to anyways, so,
sure.

> government issued ID, hand over the badge and tell the system the ID

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?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Apr 2019 17:40:58 -0400

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

> anyways), but this may be very costly in time and money so you probably

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.

> We're assuming trusted devices, but we practically have to anyways, so,

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.

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 24 Apr 2019 18:33:39 -0500

> circumstances I must also expose you to the risk of coerced disclosure of

Indeed.

> user's security concerns are for them. My security concerns are not the

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.

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

> Given enough epicycles, I can save this appearance.

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

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

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

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Apr 2019 00:49:40 +0100

Just on this point:

On 25/04/2019 00:33, Nico Williams wrote:
> sure, users can go use onion routing, but good luck with that

Loading [1] (which is the local "newspaper of record") just
now:

- via FF with NoScript and other blockers: 5.12 seconds
- via Tor browser bundle (TBB), default settings: 10.24 seconds
- via Chromium with out of the box settings 12+ seconds
  (JS+ads kept it spinning 'till 15s in fact but that was
  just ads changing I think)

Timings are rough, just as shown by n/w debugger UI. But
this is consistent with other occasions on which I've
measured.

ISTM that onion routing is less bad, performance wise, than
accepting JS/advertising and tracking.

I've started encouraging my students to try TBB and consider
using it when doing e.g. health related searches or whatever
they'd prefer not be correlated with all the other horrendous
amounts of data on them slurped up by mega-providers.

Cheers,
S.

[1] https://irishtimes.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Apr 2019 20:15:59 -0400

> amounts of data on them slurped up by mega-providers.

Onion routing for Web content is tricky because it can be MB

Email is potentially easier as most messages are short unless they have
attachments. So if we restrict messages to 64KB in size and require
anything larger to be sent as an attachment, we can make quite a bit of
headway.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 Apr 2019 01:21:14 +0100

> Onion routing for Web content is tricky because it can be MB

Huh?

The out of the box browser (chromium in the above) is *slower*
and (far) less privacy friendly than Tor. It's only with a weirdly
configured browser (FF+NoScript) that you do much better, and
sadly that weird configuration is itself also a privacy leak.

Tor used be very very slow. The crap that ads have added to the
web means that Tor browser bundle now seems to be quicker.

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Apr 2019 11:48:11 -0400

Nico Williams <[email-masked]> wrote:
    > 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

Canada Post had a key in the browser list for a decade or so, and there was
some project with Entrust to do something, but I don't think it ever
happened.
I also don't understand why I have a scanned PDF from ic.gc.ca as a corporate
identity, and not a PKIX certificate. They've had all the software to the
PKIX key for 20+ years.

The post-office is unique in that it can get a letter to many people within
24h, rather cheaply, and I keep thinking that this is a better 2FA (or 3FA) for
account recovery.

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

Canada Post is among the most technologically incompetent organizations ever.
They are captive for big consulting companies, and I think that the big
consulting companies couldn't figure how to turn such an effort into a profit
center for *them*.  I figure that is the reason.

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

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

Maybe Amazon has the clout with the Post Office to make that happen :-)
[I say with only half tongue-in-cheek]
  "Alexa, please renew my certificates"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Apr 2019 16:44:15 -0400

> some project with Entrust to do something, but I don't think it ever

The US Post office had a series of proposed schemes as well. None of them
ever got anywhere because we poached their staff as fast as they could
train them.

Every 18 months some political appointee would attempt to start some
information superhighway effort. A team would be staffed up in the USPO and
learn about PKI. About twelve months in, they would be all nicely trained
up and we would show up and offer double their salary plus stock.

I also don't understand why I have a scanned PDF from ic.gc.ca as a
> corporate

Yeah, sorry 'bout that.

> 24h, rather cheaply, and I keep thinking that this is a better 2FA (or

There is a classical problem called the innovator's dilemma that actually
mitigates against realizing such efficiencies.

>   "Alexa, please renew my certificates"

It could be made to happen. But the way to make it happen would be to
design a system that is capable of

1) Solving a very small stand alone problem by itself
2) Application to problems of arbitrary size.

I am just writing my submission to the deployment workshop (which I wont be
able to attend but thought I would submit to anyway). The paper describes
the approaches we took in the Web.

People think we just sat in our offices at CERN and waited for the Web to
take off. We didn't we were busy pushing it as hard as we could long after
the Web was a success. One of my big fears was that the press that had been
building us up for so long would decide it was time to try and take us
down. They did - see the Time-Warner 'Cyberporn' article.

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Apr 2019 16:28:40 -0500

On Thu, Apr 25, 2019 at 04:44:15PM -0400, Phillip Hallam-Baker wrote:
> >  > 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.
> >
> > Canada Post had a key in the browser list for a decade or so, and
> > there was some project with Entrust to do something, but I don't
> > think it ever happened.
> 
> The US Post office had a series of proposed schemes as well. None of
> them ever got anywhere because we poached their staff as fast as they
> could train them.
> 
> information superhighway effort. A team would be staffed up in the
> USPO and learn about PKI. About twelve months in, they would be all
> nicely trained up and we would show up and offer double their salary
> plus stock.

Oh.  That's the reason?  This is the sort of thing that should be setup
via a contract with an external party, then this sort of "sabotage" (no
offense intended) is much less likely (the external party won't want to
be in breach).

> > The post-office is unique in that it can get a letter to many people
> > within 24h, rather cheaply, and I keep thinking that this is a
> > better 2FA (or 3FA) for account recovery.

You don't need them to do anything special for that.

And note well that the post service generally doesn't know how to
contact people -- it depends on the sender to furnish the recipient's
address.  I.e., the postal service is like a network layer 3, and there
is no DNS for it.  If the postal service were to sell certificates and
also use postal delivery for 2FA, they'd have to know where you live --
"know" in very different sense from "they seem all the letters go by, so
they could know where everyone lives".

> There is a classical problem called the innovator's dilemma that
> actually mitigates against realizing such efficiencies.

That and the fact that postal services are generally publicly owned and
operated, so there's very little incentive for them to innovate.

> 2) Application to problems of arbitrary size.

Hmm, because these certificates couldn't be short-lived... the issuer
would have to support revocation, and probably record all issued
certificate serial numbers and names.  Not trivial, though still not
very difficult.  OTOH, if such certificates are strongly bound to
_devices_, then you can push the revocation burden to that layer, and
make the issuer O(1) -- that being key to (2).  (1) is already met, I
think.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Apr 2019 18:16:32 -0400

> offense intended) is much less likely (the external party won't want to

It wasn't on purpose.

It was only after going into the account for the third time that I suddenly
realized it was very unlikely we would make the sale as long as our
headhunters were head hunting.

Yes, a different structure was needed.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Apr 2019 09:42:10 +0100

On Wed, 24 Apr 2019 at 18:57, Phillip Hallam-Baker <[email-masked]>
wrote:

> Nico asked about the Mesh Trust model and I said that I was trying to
> avoid imposing one. I do have metrics for measuring the quality of trust
> Let us say that we did some key signing even open to IETF meeting
> attendees only. It would cost an attacker $325 plus travel minimum to
> impersonate me. Not an impossible sum if they really really want to
> impersonate me but enough to stop a large number of attacks. Furthermore,
> there is a significant risk of being caught if they attempt the
> impersonation on any large scale. So the social work factor might be $1000.
>

Presumably $1,000 buys more than one impersonation, and of anyone you want
(there's no list of who was actually at IETF, AFAIK).

-- 
I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

*https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22
<https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22>*

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Apr 2019 09:44:23 +0100

> and only device!" or "help, I've lost all my devices!" cases.

No, after the first time it costs $infinity. Better not lose your key.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Apr 2019 10:17:15 -0400

> (there's no list of who was actually at IETF, AFAIK).

The design of VeriSign Class 3 was intended to mitigate the risk of
impersonation by making it unprofitable for the attacker. In particular it
was intended to make crime impractical for repeat offenders.

So the first step in the chain was to make it so that a party has to commit
a crime to obtain a fraudulent certificate. The next was to limit the
validity so that they had a narrow window of opportunity to make a return.
So if they paid $300 for the cert, they would have to make that back in
five days to turn a profit. Not impossible but requires them to make some
effort and that adds cost.

But even if they get away with a profit of $5K per time, that isn't going
to last them long. So they have to do it again and register/impersonate
another company etc. etc. And they will probably go about it the same way
so that they begin to establish a pattern of behavior. And each time they
do it, they are committing more crimes in the registration process. So they
are either repeat offenders in one jurisdiction increasing the probability
of being investigated or they are offending in multiple jurisdictions
increasing the probability of being investigated.

So yes, the work factor isn't insurmountable but it isn't zero either. Carl
Ellison's point about ceremony may be relevant here.

Lets say that the attacker attempts to register themselves multiple times.
We could defeat that by binding the assertion to their conference
registration number. Perhaps we print the QR code or a part of it on their
badge and it can only be used once. Perhaps we also require validation to
the email address they registered for the conference.

At the end of the day, the data is dumped into a blockchain and so we have
a tool that allows us to roll back attacks after the event. Which is why I
did not suggest taking pictures of the person registering.