Subject: [TLS] Fixing TLS Trust

From: Henry Story <[email-masked]>
Date: Mon, 30 Apr 2012 18:46:57 +0200

TLS currently helps one know that when opens a connection to a service (domain:port pair)
one is actually connected to the machine that officially owns that domain. It does not
give one the big picture of what kind of entity one is actually connected to:
ie. it does not answer the following questions:

 - is this a legal entity?
 - which country is it based in (or which legal framework is it responsible to)
 - who are the owners
 - what kind of organisation is it? (individual, bank, commerce, school, university, charity...)

In a recent talk I gave at the European Identity conference in Biel, Switzerland, I looked 
at how this extra information could be made available by using WebID and Linked Data, published
by official entities in ways that gave those documents legal weight. This would not be technically
very difficult to do, but would provide huge benefits to the web. It could increase trust 
in the way people use the web, and it could enable commerce in a much broader way that hitherto
found on the web.

  I put this presentation up on my blog with the title "WebID and Commerce" 
   http://bblfish.net/blog/2012/04/30/

WebID is just the art of tying TLS into the linked data world, which is the framework that
has been developed under the guidance of Tim Berners Lee. So it brings two worlds together,
which is why I am cross posting here. It seems like an idea with a lot of potential.

	Henry

Social Web Architect
http://bblfish.net/

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Apr 2012 19:16:46 +0200 (MEST)

Henry Story wrote:
> 
> TLS currently helps one know that when opens a connection to a service
> (domain:port pair) one is actually connected to the machine that
> officially owns that domain.

That sounds backwards from what it is.

A DNS domain owner can obtain TLS server certificates for hosts in
his domain.  So when a TLS server shows a cert with a DNS Name in it
that chains to one of the RootCAs known in the TLS X.509 PKI as known
by common web browsers, then one assumes that this cert was obtained
by someone who could demonstrate to the relevant CA to be an admin
for that DNS domain.

For domain validated (DV) certs, the ability to receive the DNS admins
EMail is all that is verified.  Nowadays, DV-certs seem not to contain
any other data in subject and subject alt name about the cert requestor
besides the DNS hostname for which the cert was requested.

>
> It does not give one the big picture of
> what kind of entity one is actually connected to:
>  - what kind of organisation is it?
>    (individual, bank, commerce, school, university, charity...)

That information is completely irrelavant to TLS and to the existing
server endpoint identification schemes on top of TLS (rfc2818,rfc6125).

The CABForum has defined schemes to verify additional attributes about
certificate requestors, which can be places as verified/vetted attributes
in "organzation verified" (OV) and "extended validation" (EV) certs,
but these come at a signficant extra cost, and that extra information is
only meaningful to human beings.

> 
> In a recent talk I gave at the European Identity conference in Biel,
> Switzerland, I looked at how this extra information could be made
> available by using WebID and Linked Data, published by official entities
> in ways that gave those documents legal weight. This would not be
> technically very difficult to do, but would provide huge benefits
> to the web.

While OV- and EV-certs may provide additional benefits to users who
actually verify these attributes, the information is irrelevant for "the web".

>
> It could increase trust in the way people use the web,
> and it could enable commerce in a much broader way that hitherto
> found on the web.

"The Web" is glued together with URLs, which distinguish places
_only_ by DNS Names, nothing else.  An URL does not distinguish
ACME bank from ACME fireworks, and there is no rule which of them
was first to register a particular DNS domain name.

So IMHO, the only way you could "increase (percieved) trust in the web"
would be to significantly deceive users about the underlying technology.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Apr 2012 12:31:24 -0500

>  - what kind of organisation is it? (individual, bank, commerce, school, university, charity...)

There are not things I've cared much about in the brick and mortar
world because those things are implied.  It's... difficult to put up a
fake bank, with fake tellers, advertisement, and so on.  Not so
difficult to put up or hack hole-in-the-wall ATMs, but then I don't
use hole-in-the-wall ATMs.  In the off-line world this approach
pervades.  Now, it is true that I care about track records (e.g., when
making investments), but I've never asked "who are the owners?",
except for small restaurants/shops that I like and where knowing the
owners is social benefit.  I've also not asked "is this a legal
entity".  Maybe I'm just naive?  When I see a doctor I see diplomas on
their office walls, but I don't go double checking them.  And so on.

In the on-line world some of these questions are more interesting, but
only because trust is harder to establish.  And anyways, we don't get
answers to these questions on-line, not most users anyways.  The trick
is to get domain names to reflect the same things that brick and
mortar sites do.

> in the way people use the web, and it could enable commerce in a much broader way that hitherto

No matter what we're still talking about how to establish trust.
That's the hard part.  How do I trust that such and such corporation
owns some website?  I have to know who is making that statement, and
for that I must authenticate them, and I've to decide if they can make
that statement authoritatively, and whether I trust them (even if I
can authenticate them).

Assuming the TLS server PKI works then you're right, this is simple to
add as a *protocol*.  Though you'd still need to get someone to do the
vouching: it won't be governments, since there are some many ones that
are authoritative at some level that users could not really authorize
them to make these statements, so it has to be some commercial
operation, or a national-level agency.  That sounds so difficult to
pull off, and likely to provide so little value that I don't think it
can happen.

But on a smaller scale it could happen, and, indeed, it does already.
What I have in mind is federations of like companies.  Sites like
Amazon, eBay, and Yahoo! already have, effectively, federations of
vendors.  I'd like to see a federation of banks.

Nico
--

---

From: Henry Story <[email-masked]>
Date: Mon, 30 Apr 2012 19:35:51 +0200

Martin, seeing the speed at which you responded I don't think
you took the time to look at the presentation. It may be worth
doing that, as it presents some technology that opens up many
new possibilities you may not be aware of. The proposal furthermore
works with TLS not against it: it builds on TLS directly to build
something that I think you will find very interesting. :-)

But let me answer your points below to hopefully answer misgivings.

> besides the DNS hostname for which the cert was requested.

Well TLS at that level still only guarantees that you connected to the 
machine. Not the context of who owns the machine and how it fits into 
the policitical/economic/legal context. Ie. it does not answer the 

> only meaningful to human beings.

The idea is not to put this information in the certificates at all, but
to place a URI in the SAN and IAN fields that allow that entity to be
tied into what for lack of a better word I called the institutional web.

> actually verify these attributes, the information is irrelevant for "the web".

I am not speaking of adding this information the way EV certs do it: into the
certificate.

> was first to register a particular DNS domain name.

yes, but the web can by basing itself on TLS and soon DNS-SEC and DANE
create a network of linked data that can be used to create the trust
that is missing at the TLS layer. In this scenario this is not a flaw
of TLS, but rather something that can be build on top and WITH TLS.
If this is correct it should help guide the future development of TLS 
and other IETF security protocols.

> would be to significantly deceive users about the underlying technology.

I sincerely believe this not to be the case. I think it is worth looking
at this proposal with an open mind. There are two worlds that I am trying
to get to work together: TLS and LinkedData. There is much that they can
do together, if we can get both communities to understand each other.

Hope this helps,

	Henry

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Mon, 30 Apr 2012 21:24:08 +0200

> their office walls, but I don't go double checking them.  And so on.

exactly. That may have been a better way to introduce the subject in the
presentation!

> is to get domain names to reflect the same things that brick and

yes, but a domain name can be reached by clicking a page that is not
behind https, and so a man in the middle attack could have changed
the originating link, even if it came from a trusted source. Also
with people typing in urls it is easy to make a spelling mistake that
a clever domain hacker could have bought. Finally there are many online
businesses that are perhaps very reliable - a small swiss watch maker 
for example - which don't have the marketing power to make us all remember
their name.

The linked data web could help here. Browsers could use the background 
"institution web" graph to help users identify the site they are on. If
browsers don't do that other companies could provide widgets or browser
plugins to fill the gap.

> that statement authoritatively, and whether I trust them (even if I

yes. All businesses tend to be registered somewhere: be it either with the
local authority, or with some tax office, or with the stock exchange,...

> operation, or a national-level agency.

yes.

> That sounds so difficult to pull off, and likely to provide so little
> value that I don't think it can happen.

I think the value is quite big in fact, and it would not be that difficult
to do technically. Getting all of these institutions to coordinate would
be more difficult to do I agree, and one would have to start somewhere where
the value and the will is there: perhaps the stock exchanges or banks.
In my presentation I illustrate the idea with banks. How it gets going in
actual fact is of course wide open. It would be something one could run 
some fruitful test cases to see what is required.

> vendors.  I'd like to see a federation of banks.

Yes. That's the example I used. In Switzerland it was suggested that
companies such as Swatch that have a lot of resellers that are always
changing might also have a need for something like this. This is why 
I think that attacking this from both the social networking side and the
more formal institutional side is useful. The institutional side helps
people see how trust can work in a distributed manner - it always has.
It is just that we tend to think of governments as central agencies,
whereas in reality they are distributed: each state is a peer in the social
network of states.

I'd be happy to work with some organisations that are interested in trying
this out.

Henry

Social Web Architect
http://bblfish.net/

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Apr 2012 14:57:52 -0500

On Mon, Apr 30, 2012 at 2:24 PM, Henry Story <[email-masked]> wrote:
> [...]

That problem doesn't go away.  We can't just use HTTPS (no matter how
much some people insist that we should only use HTTPS).  DNSSEC
wouldn't help either since usign HTTP (no S) means that there can
always be an MITM in TCP.  The only solution here is to train users to
know when to insist on HTTPS, and the UIs really have to not suck (as
long as we allow HTTP_no_S for some things this will be a problem).

> local authority, or with some tax office, or with the stock exchange,...

I'm not sure that's true.  In the U.S. in some/many?/most? states it's
possible to start a sole proprietorship without having to first
register anywhere -- sure, these are going to be small businesses, and
they will eventually have to pay taxes and therefore register, but
even then, there's too many governments you'd have to go check to find
out about random companies, at least in the U.S.  Who's going to do
it?  I can't think of a random web customer caring to check the tax
records of a sole proprietorship or corporation, or caring to know
immediately that someone else has checked.

> the value and the will is there: perhaps the stock exchanges or banks.

Again, protocol-wise: trivial, but business-wise: very much
non-trivial.  "Not that difficult to do technically" is not enough,
and you do have to be careful what you mean by "technically", because
to me this is "technically" quite difficult when we include anything
other than "protocol details" in "technically".

> whereas in reality they are distributed: each state is a peer in the social

Governments are too distributed to help with this problem, unless we
could get all these governments (or at least the ones that matter, or
enough that the ones that do can be the ones that end up mattering) to
have all these databases online.  That's a political problem.
Political processes can be very slow -- much slower than IETF
processes.  Watch out.  My conception of federations sidesteps that
problem.  And as I said: it's already happening on some scale.

With respect to banks... the business model there looks significantly
different than Amazon's/eBay's/Yahoo!'s -- the latter act as a
directory/middleman to the vendors, while there should be no middleman
when it comes to banking, and people do not purchase banking
products/services from random banks as often as they do trinkets from
random vendors, which limits the usefulness of a directory of banks.
So I'm not sure what we can do there.

Basically I'm skeptical.  For my money the certificate transparency
proposal is our best bet in the short-term.  Longer-term, if there's
any way to bring user authentication mechanisms that can do mutual
authentication into the web, then that will help enormously when it
comes to banking, but I think there's a lot of barriers to improving
user authentication on the web.  We'll see.  (That reminds me, I
should write something up for HTTPbis.)

Nico
--

---

From: Geoffrey Keating <[email-masked]>
Date: 30 Apr 2012 20:03:14 -0700

Henry Story <[email-masked]> writes:

> TLS currently helps one know that when opens a connection to a
> service (domain:port pair) one is actually connected to the machine
> that officially owns that domain. It does not give one the big
> picture of what kind of entity one is actually connected to: ie. it
> does not answer the following questions:
> 

Isn't this mostly covered by EV certificates?

- The 'is this a legal entity' part is answered with 'yes'.

- The country/legal framework part is the
  jurisdictionOfIncorporationCountryName field and similar.

- It doesn't describe the owners, but of course that information could
  change between the time the connection is opened and the packets
  reach the other end; except in the case where a certificate is
  issued to a sole proprietor, in which case that individual is named
  in the certificate.  In the case of a company it does provide
  sufficient information to track down the company and find its owners
  if they are publicly available.

- The kind of organisation is covered by the businessCategory field.

The presentation seemed interesting.