Subject: [perpass] Web-of-trust CAs

From: DataPacRat <[email-masked]>
Date: Mon, 21 Oct 2013 14:58:12 -0400

I've just posted a new version of a draft for an extension to the
current vCard format, "Signed vCards" [1]. The general idea is to use
existing encryption techniques to turn an existing format for
"identity description" into one for "identity authentication",
including non-email-based identifiers, change of identifiers over
time, publication and revocation of keys, and so forth.

The reason I'm putting all of this together is that, after finding out
just how brittle the current Certificate Authority system is, I wanted
to have a replacement that was much mushier and resistant to root-CA
hijacking, possibly based on some form of web-of-trust. I'm currently
trying to teach myself enough about webfist [2] to see if it can be
adapted for the purpose, likely by replacing its current DKIM-based
authentication system. My thought is that if that can be made to work,
then it may be feasible to try combining Signed vCards with CA-style
certificates.

There's also the possibility that I'm completely deluded about the
whole approach. I'm not an expert in the field; I'm just trying to
find a solution that's within my meager skills. So I'm hoping to evoke
as much feedback and constructive criticism as I can. Since swapping
out hierarchical CAs for a system more resistant to a subpoena attack
would seem to help reduce pervasive monitoring, this list seems a
worthwhile place to discuss it.

So: How can my ideas be improved?

[1] https://datatracker.ietf.org/doc/draft-boese-vcarddav-signedvcard/
[2] http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Oct 2013 15:20:34 -0400

> worthwhile place to discuss it.

I think you need to work out how to evaluate how trust in the Web of Trust
is evaluated:

http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00

You can accuse the CA system of being 'brittle' but so is Web of Trust once
you get past the keys that you signed directly yourself.

Putting the key in a vcard only addresses one part of the problem, you need
to know whether you have the right vcard. An attacker that can knock over a
CA will have no trouble knocking over a simple vcard scheme either.

To replace that system you have to show that what you propose as a
replacement is actually stronger and that it is not susceptible to
sovereign control by a single government (at minimum, some of us are not
going to be any more happy with a group of governments acting in concert
unless you can assure us that they will not collude).

Where vcard is supported, it makes a fine mechanism for converting a key
identifier to a key. It is a less good mechanism for establishing trust in
a key which is what most of us see as the hard part.

-- 
Website: http://hallambaker.com/

---

From: DataPacRat <[email-masked]>
Date: Mon, 21 Oct 2013 16:46:45 -0400

On Mon, Oct 21, 2013 at 3:20 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> replacement is actually stronger and that it is not susceptible to sovereign
> control by a single government (at minimum, some of us are not going to be
> any more happy with a group of governments acting in concert unless you can
> assure us that they will not collude).
>
>
> identifier to a key. It is a less good mechanism for establishing trust in a
> key which is what most of us see as the hard part.

The reasons you list are the ones behind why I included the
'Confidence' parameter in the Signed vCard spec. In fact, that
parameter is the key to the whole approach.

There is good reason to treat Bayesian analysis as a useful tool for
analyzing iffy data, such as a pool of keys that may include false
ones. Using existing terminology, any given vCard Authority can be
treated as an ad-hoc Certificate Authority. Using one's own
self-signed vCard as a baseline, web-of-trust techniques could then
determine the relative amount of trust to apply to any other Signed
vCard's data. Eg, if I trust my own vCard at a level of 100 decibans,
I trust Alice's card at 30, and Alice trusts Bob's card at 40, it's
easy to determine that Bob's card should be trusted at somewhere under
30 decibans. (Real situations would be much more complicated, such as
with multiple assertion paths; but this is still early days.)

If this approach is, in fact, workable, then once the details can be
hammered out (perhaps with Webfist-style exchanges, perhaps some
entirely different method), I'm hoping that those details can be
hidden from the end-user as well as the certificate negotiations for
https browsing are, for users who just want to get things done. Throw
in a collection of open-source key/vCard signing apps, which use
cellphone cameras and QR codes, and then, as you mention in your
PRISM-Proof trust model, even a thousand attendees at a conference
could potentially perform mutual key endorsements with just about
every other attendee. But that's still pie-in-the-sky - getting the
Signed vCard draft nailed down is the current step. Getting it nailed
down so it can, at least potentially, eventually support the
pie-in-the-sky, is why I've brought it up on this list.

So: What can I do to improve the current Signed vCard draft?

Thank you for your time,

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Oct 2013 10:19:28 -0400

DataPacRat,
> ...
A similar proposal, adding qualitative metrics to the basic web of trust 
model,
was the focus of a PhD thesis about 20 years ago, in France. It was not 
a great
idea; trust is not transitive and adding numbers to the mix doesn't 
change that,
although it can lead to considerable confusion for users.

Steve

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 11:06:14 -0400

On Tue, Oct 22, 2013 at 10:19 AM, Stephen Kent <[email-masked]> wrote:

> was the focus of a PhD thesis about 20 years ago, in France. It was not a
> great
> idea; trust is not transitive and adding numbers to the mix doesn't change
> that,

(I know that this isn't the idea you were trying to convey, but I find
the very fact that the idea I came up with was able to /be/ the topic
for a thesis very cheering. :) )

I am extremely aware that Bayesian numbers are extremely non-intuitive
for many people. Simply by rephrasing a basic Bayesian-style word
problem in different ways, from 15% to 46% of doctors get the right
answer [1]. This is why I spent so many paragraphs describing decibans
and their use in the draft, including a table. It's also why, once the
basics of the system are worked out, I'm hoping to offer the option of
hiding all the fiddly bits in the background for the end-user, as in
present-day https.

The key item I am gathering from your response is 'trust is not
transitive'. If that's the case, then wouldn't that also apply to
chains of 'official' CAs, as well? If all that is so, then is it
possible that ad-hoc / mesh-network / web-of-trust /
(insert-buzzword-here) CAs would fare no worse by that metric than the
current hierarchical CA system?

[1] http://yudkowsky.net/rational/bayes/

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 11:55:04 -0400

On Mon, Oct 21, 2013 at 4:46 PM, DataPacRat <[email-masked]> wrote:

> Eg, if I trust my own vCard at a level of 100 decibans,

I've just realized that not only might this problem be easier to solve
than I expected, it might already be solved. After waking from an
unusual dream, I've realized that it may be possible to analyze trust
networks with the same tools used to measure electrical networks;
specifically, by treating the user as a voltage source, any individual
as a node, and their level of trust in another individual/node as
conductivity (the inverse of resistance). There are plenty of existing
tools to perform analysis of bizarre electrical architectures, so if
this model has any validity, it should be reasonably trivial to apply
them to trust architectures, to work out how much current/trust
emanating from the source/user arrives at any given node/individual.

The question is whether this model /has/ any validity. I'm going to do
all the reading I can think of on trust modeling, but would also
appreciate any useful references anyone reading this might be able to
offer. (I have a limited budget, so free-to-read references are
preferred to paywalled ones.)

Thank you for your time,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Oct 2013 12:33:31 -0400

Trust is not transitive but cost measures are pretty stable

Producing a web of trust with a thousand bogus entries costs essentially nothing

Producing such a web with twenty links to verified parties is much
more expensive

Incidentally, I can't claim any originality for the extended work
factors I use as it happens. Although I came to them independently it
turns out that a co collaborator had gone so far as to organize an
event on the topic,

But what I had not appreciated earlier is just what a difference it
makes to cast the web of trust problem in terms of a work factor
metric and introduce a combination of peer and ttp trust providers.

Sent from my difference engine

> On Oct 22, 2013, at 10:19 AM, Stephen Kent <[email-masked]> wrote:
>
> DataPacRat,
>> ...
> A similar proposal, adding qualitative metrics to the basic web of trust model,
> was the focus of a PhD thesis about 20 years ago, in France. It was not a great
> idea; trust is not transitive and adding numbers to the mix doesn't change that,
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Oct 2013 08:32:54 +1300

>> with multiple assertion paths; but this is still early days.)

Excuse my ignorance, but while I have no difficulty understanding
Bayes' Theorem and know who invented decibans, I don't understand how
I can use a trust value that is different from 1 or 0, in practice.

I won't trust somebody with half my PIN code because they rate 47 decibans.

    Brian

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 16:14:40 -0400

> I won't trust somebody with half my PIN code because they rate 47 decibans.

I could suggest that the values be interpreted in terms of LaPlace's
Sunrise formula - eg, "there's been 10 reports of the key being used
falsely and 500,000 that it's been used successfully: Do you wish to
continue?".

More usefully, though, I'd suggest that you already go through this
process today, with whatever security/privacy procedures you may use,
only qualitatively rather than quantitatively. Eg, if something like
this is used as a replacement for hierarchical CAs for https
transactions, then some practice and experiment would have been done
by then to figure out reasonable trust values for any given result.
Eg, "Below 0 decibans: Reject. 1-20 decibans: Warn user, show highest
trust paths, ask for confirmation. 20+ decibans: Proceed normally."

(Smart software would allow users to tweak their own thresholds, with
suitable warnings. Even smarter software would use more complicated
metrics involving calibrating the trust values reported by each
issuer, adding time-based factors, and so on.)

To you, as an end user, part of the goal of the infrastructure system
here is to fade into the background as much as possible, so that you
don't even realize it's there, and generally don't have to worry about
it, any more than you have to worry about what makes your browser give
a green-light to your bank's website today.

Thank you for your time,

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Oct 2013 13:37:59 -0700

> metric and introduce a combination of peer and ttp trust providers.

Dear Phillip,

Some hope to establish defenses for services that lack mandatory authentication.  Without authentication, any possible reaction would be based on unconfirmed suspicions as the only rational response.  Lack of authentication is often justified as a means to provide anonymity.  While enabling individual anonymity is fine, those managing a system that may initiate abuse must be authenticated and held accountable (to be responsive to reports of abuse).  Only those managing a system should be expected to attribute individual abuse based on internal accounts.  As such, this management can be done with anonymity as well.

Developing a group form of reputation for unauthenticated services as a means to avoid liabilities for errors made in identifying suspected abusive actors assumes dilution of these errors is a solution.  This approach can not be fair and represents a dangerous easily poisoned system.

Regards,
Douglas Otis

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Oct 2013 17:02:38 -0400

> falsely and 500,000 that it's been used successfully: Do you wish to

This is why I would not attempt to use Bayesian logic.

You have no way to measure probability reliably. An attacker can simulate
any behavior before they defect. The only measure that is useful is the
cost of simulating that behavior. If it is prohibitively high then we can
decide to trust them.

Remember that Bernie Madoff paid out 100% of every redemption request right
up to the point where the money ran out.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Oct 2013 17:24:02 -0400

DataPacRat,
> current hierarchical CA system?
That is a fair comment for some PKIs, but not all.

If a PKI represents an _authoritative_ set of CAs, vs. a "trusted"
set of CAs, then this issue does not arise. So for example in the
DANE context or the RPKI context, we're not dealing with transitive trust.

Steve

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 17:53:23 -0400

> any behavior before they defect. The only measure that is useful is the cost
> of simulating that behavior. If it is prohibitively high then we can decide
> to trust them.
>

One thing using Bayesian/LaPlacian numbers /can/ do is indicate how
much effort would need to have been exerted in order to simulate the
behaviour. If implemented correctly, then put simply, you can't get to
40 decibans of confidence without having had 10,000 successful tests
for every failed test.

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Tue, 22 Oct 2013 17:56:18 -0400

On Tue, Oct 22, 2013 at 5:24 PM, Stephen Kent <[email-masked]> wrote:
> If a PKI represents an authoritative set of CAs, vs. a "trusted"

I'm not familiar with many of the details of DANE and RPKI. Do either
of them provide any protection against a subpoena attack?

Thank you for your time,

---

From: SM <[email-masked]>
Date: Tue, 22 Oct 2013 22:56:26 -0700

>of them provide any protection against a subpoena attack?

DANE is specified in RFC 6698.  The DNSSEC Practice Statement for the 
Root Zone KSK Operator is at https://www.iana.org/dnssec/icann-dps.txt

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Oct 2013 09:19:53 +0200

At 14:56 22-10-2013, DataPacRat wrote:
> Do either of them provide any protection against a subpoena attack?

Could you explain the 'subpoena attack' in more detail?

Ciao
Hannes

PS: I know what a subpoena is.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Oct 2013 08:10:21 +0000

> PS: I know what a subpoena is.

So do I, and AFAIK it can compel you to come and testify, or to hand over some documents. I don't think it can be used to force a CA to sign a certificate request or for whoever to register bad keys in the DNS.

Not saying a national government can't do either of these things, but not with a subpoena.

Yoav

---

From: DataPacRat <[email-masked]>
Date: Wed, 23 Oct 2013 10:56:02 -0400

> PS: I know what a subpoena is.

An exemplar could be the attack against Lavabit's customers, which was
only prevented by Lavabit shutting down entirely. More generally, it's
a government issuing some sort of demand, often secret, to an online
service provider, requiring at least that they hand over various keys,
occasionally much more. 'Subpoena' is a placeholder for any similar
document, such as court orders, search warrants, and the American
"National Security Letters". A tad sillily, it's the official
bureaucratic version of lead pipe cryptoanalysis, with lots more
paperwork, and with the claim that the group making the threats have
legitimacy in doing so because they're the government.

My general thought, as of the start of this thread, is that such
attacks could be made much harder to implement and much less effective
by massively increasing the number of CAs (essentially, by turning
everyone into a CA). Sending a lone piece of paper to a single
middle-manager would no longer force sufficient compliance to track
the online behaviour of thousands-to-millions of individuals. Should
measurable effort be required in order to spy on any one individual,
then it seems at least possible that simple budgetary concerns would
reduce the amount of spying done on ordinary citizens. (Of course, my
current .sig quote might apply.)

Thank you for your time,

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Oct 2013 11:04:42 -0400

DataPacRat,
> of them provide any protection against a subpoena attack?
I'll let other folks comment on DANE, right Warren?

As for the RPKI, first note that it is a PKI that provides
authenticated info about who holds which blocks of IP address
space, and thus encryption is not an issue. I recently published
an I-D (draft-kent-sidr-suspenders-00) that tries to address concerns
that have been raised by some folks about possible law enforcement
influence on the CAs in the hierarchy. The focus here is at influence
that might be effected across national boundaries.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Oct 2013 11:22:40 -0400 (EDT)

> occasionally much more.

> everyone into a CA).

That's basically what DANE does. Everyone becomes their own CA within
their own domain, by securely (DNSSEC) publishing TLS public keys.

You still need to run these TLS servers yourself to protect against the
"subpoena attack". So it won't help you with ISPs offering TLS.

But if I run a TLS server in my own infrastructure and publish my TLS
key using DANE as I do:

  dig +short tlsa _443._tcp.nohats.ca
3 0 1 6327233AE15A460A4AD9875C547FE83208924387E09F3A18E6594D4A CCDF5D87

Then no "subpoena attack" could be launched. They could force a
registrar or TLD to change the delegation of my domain by modifying the
DS and NS records at the parent (.ca) and point to their own TLS server
using a modified TLSA record, but this would be clearly visible to the
entire world (and hopefully me, as my server would not be getting any
traffic anymore)

The only defense against a "subpoena attack" is not outsourcing your
end to end encryption. That's what we need to facilitate. Where we do
need to depend on others for delegation, it should be public and we
should have notaries/transparency/logs. Any such change should be
visibly globally and to everyone to avoid targeted attacks.

Paul

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 23 Oct 2013 11:42:46 -0400

A subpoena in this context is one of the
multiple instantiations of "lawful authorization."
The exact form varies in different jurisdictions
pursuant to the statutory or administrative law
being employed.

The force and effect derives from the fact
that the entity receiving the lawful authorization
and refuses will befall one of the following
adverse effects: loss of business authorization,
loss of equipment/software approval, fine, or
imprisonment.

The global requirements that are implemented
with minor modifications in essentially every
nation can be found here.  Those implementations
have multiple sub-categories depending on whether
the handovers are real-time or not, and whether
content or metainformation/signalling is being
provided.

http://www.etsi.org/deliver/etsi_ts/101300_101399/101331/01.03.01_60/ts_101331v010301p.pdf

Vendors and service providers build
and operate devices and services to
be compliant.  The encryption controls
can be found at Sec. 4.3.

The underlying international law supporting
these requirements has a long and extensive
history dating back to 1850.

Hope this helps.

-t

---

From: DataPacRat <[email-masked]>
Date: Wed, 23 Oct 2013 12:51:07 -0400

> end to end encryption. That's what we need to facilitate.

I think I see a differing assumption between DANE and RPKI, and the
model I'm using. Both of those security systems seem to be aimed at
provably linking a domain name with a particular server, so that when
you go to 'gmail.com' you're not secretly being redirected to some
other server which decrypts your private email. But if no domain name
is involved, neither of those systems applies.

I'm thinking of a different layer of security: the end-user, rather
than their ISP. While many companies and some people run their own
domain names, an increasing number of people don't even bother having
email addresses anymore - they have accounts at an ever-shifting
collection of social media sites, each of which has different
capabilities, each of which uses different security procedures.
Proving that the tweets sent by @DataPacRat are from the same person
as the posts of facebook.com/DataPacRat, and both are sent by someone
posting to an otherwise-anonymized Tor-based bulletin board, seems, to
me, to be a related but slightly different problem than securing
twitter.com and facebook.com themselves.

Put another way - I'm trying to find a security solution that includes
sites with URIs resembling randomstring.onion , as well as whatever
random pseudo-URIs will have been invented in five to ten years. With
luck, such a solution will be broad enough to cover more ordinary
internet usage, as well. As .onion addresses don't use the DNS system,
DNS-based security systems aren't quite general enough for what I'm
hoping to aim for. A highly distributed CA-like system /might/ be
broad enough to do the trick (not to mention many other tricks); it's
possible I'll have to look somewhere else, or even that it's not a
soluble problem.

There don't seem to be many people thinking in this direction, so I'm
doing what I can to figure out as much as I can, in case I manage to
collect enough ideas to assemble into a useful new pattern. Signed
vCards seem as if they'd be a handy tool to build any such solution
on, as they allow for keys to be asserted as being linked to arbitrary
ID strings (including any given URI or pseudo-URI). Working out a
system for easy use, exchange, and storage of Signed vCards is...
still an open problem. Since enduser-to-enduser security would help
reduce pervasive passive monitoring, and I've started getting a better
handle on IETF mailing lists and working groups, I've brought up the
idea here, in hopes of evoking as many potentially useful ideas as I
can.

I'm all too aware that this logic chain may have fallen off the rails
at just about any point in the above-described thought processes, so
I'm also trying to keep an eye out for any alternative approaches that
can handle non-DNS-based identifiers.

We now return you to your regularly scheduled mailing list.

Thank you for your time,

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Oct 2013 13:21:09 -0400

DataPacRat,
> is involved, neither of those systems applies.
This is not true of the RPKI. The RPKI was developed to support
routing security, not binding public keys to DNS names.

Steve

---

From: DataPacRat <[email-masked]>
Date: Wed, 23 Oct 2013 14:25:37 -0400

> routing security, not binding public keys to DNS names.

My mistake; my apologies.

Thank you for your time,

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Oct 2013 17:41:59 +0200

Hi Paul,

> end to end encryption. That's what we need to facilitate.
This overstates the case.  Unless you know the individual or site, you
must trust others.

On your other points, Hannes has written an excellent entré that starts
as an overview and will continue as an analysis.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Oct 2013 20:36:07 -0400

On Tue, Oct 22, 2013 at 5:53 PM, DataPacRat <[email-masked]> wrote:

> cost

 Like many powerful theory tools, Bayesian inference is perfect in theory
but useless for many of the purposes people try to use it for.

The problem with any analysis based on probability is that the confidence
can only diminish as the distance between the nodes increases. The problem
with Web of trust is that the generation loss between keysignings limits
the diameter of the trust graph and the amount of effort users will bear
limits the degree.

Taken together these give a maximum size to given by the Moore bound on the
number of nodes in the graph.