Re: [TLS] Fixing TLS Trust

On 30 Apr 2012, at 21:57, Nico Williams wrote:

> On Mon, Apr 30, 2012 at 2:24 PM, Henry Story <henry.story@bblfish.net> wrote:
>> On 30 Apr 2012, at 19:31, Nico Williams wrote:
>>> 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.
>> 
>> 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
>> [...]
> 
> 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).

I agree that http won't go away (easily). What is possible though is that 
browsers be enhanced by the vendors or plugin writers or even with
external applications to fetch metadata about a web site and its
owners and its position in a legal framework from the linked data web.

So imagine a non-internet-technical-person, Alice, is somehow reading a very 
good blog served with http about some excellent Swiss watchmaker, who 
has a little shop up in the mountains in calm isolation from the hectic 
hustle and bustle of most mortal men's lives, the calm giving him the serenity 
to make the most amazing devices. This reader could click on the link
and two things could happen

 1. the page was man-in-the-middled first to send him to some fake
 site. The browser takes that domain name and tries to from a
 number of linked data trust points to find the official metadata about
 that site. Perhaps it finds very little information about it, which 
 should be a warning sign. Perhaps it finds that the company owners are
 incorporated in some other country. Alice finds this suspect, and calls
 her techy friend to help her verify what is going on.

 2. the page was not man-in-the-middled and Alice ends up on the swiss
 watch makers https protected site (the swiss are very good at security)
 That site is server with a certificate placed in DNS-SEC using DANE with
 a WebID in the SAN. That WebID also confirms the public key of the watch
 maker and points to the local Swiss Watch Maker's authority page and to the
 local canton's business registry which each points back to the swiss
 watch makers WebID (and so indirectly to his profile). Both of those are 
 linked to by the swiss Identity registry, which itself is pointed to 
 by the equivalent US registry.
 The browser plugin uses this web of data to give our non-technical-user 
 an interface that she can inspect, and that she can drill down into to 
 find exactly which registry said what if she wanted to.

 Ok it is true that this still leaves open the possibility that the man
in the middle not just change the URL to the watch maker, but also changes
the text and the description. But if this is not going to be obvious through
inconsistencies - one part of the text describing switzerland, the other
part describing some hot country in south america - then the text will need
very careful man-in-the-middleing. Perhaps the man in the middle is another
Swiss watch maker in a nearby canton, whose linked data network also resolves
well. But then in any case Alice would get a watch, and she would know 
which watch maker had man-in-the-middled her if she had a complaint later.

Furthermore one can imagine consumer associations emerging that would 
be able to create services to enhance the metadata for a site with
other satisfaction reports, these consumer associations forming a network
themselves covering the globe (so as to always be close to the businesses
that they were reporting on, and so able to take local context into account)

I think this very clearly shows a big improvement over the current 
situation.

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

I did not know that. Thanks for pointing this out.

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

This is an organisational issue that is not something that I can solve
here. For everything but "sole proprietorship" companies the institutions
already exist. It should be possible to have something that helps those smaller
companies too. In my presentation I start with banks, as those are heavily
regulated and as they have the finance to put things in motion. Perhaps
they could provide the service for those smaller businesses....

> 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 important thing is that the data be available so that User Interfaces
tuned to the particular software in use can be built. I would expect some 
lightweight signalling to be made visible to the user, which he/she can go
into more detail when required. This is user interface design work, and 
experts like Aza Raskin are the people to employ for this task

https://blogs.oracle.com/bblfish/entry/identity_in_the_browser_firefox

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

Completely agree. The work here is one of convention and standardisation,
which is as much a social project as a technical one. A lot of the
standards are already in place though:

  - HTTP, HTML
  - TLS/SSL
  - DNS-SEC + DANE
  - RDF and serialisations (RDFa, turtle, rdf/xml, json/ld)
  - ontologies and basic object reasoning 
  - linked data http://linkeddata.org/ 
    with a standardisation process being started at the W3 with the 
    Linked Data profiles submission by IBM, Oracle, Red Hat, and others
      http://www.w3.org/Submission/2012/02/
  - tools in every programming language to do most of the above

So it is not as if everything has to be invented. One would need to
choose some interesting and feasible use case and interested parties, 
get some running code, get it to interoperate, and produce and publish
ontologies and how to guides. That IS a lot of work. But it is not
at all in the realm of pure speculation. Building a prototype with fake
banks should be something that is very feasible, and then trying it out
in some real use cases is not that far off. 

  In any case I think it is quite clear that this is where the Trust 
story has to go. It is decentralised enough to make every state and
player happy, and it is flexible enough to be able to extended to even
the most unusual use cases.

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

I agree there. The reason in my presentation I mention governments and
institutions is that this helps anchor people's understanding of trust.
But of course to get going smaller projects will be needed. Having the
bigger picture in mind can nevertheless help co-ordinate projects 
developing in parallel.

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

There are not that many banks in the world, so it would be easy
to start with a single list of co-operating banks to get things
going. The registry of banks would just help vendors of any size
do purchases directly with the banks.

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

Thanks for your feedback. I was hoping just to open up a new space
of possibilities. A lot of the pieces are already in place. Trying
it out in vitro would be the next step. :-)

>  (That reminds me, I
> should write something up for HTTPbis.)
> 
> Nico
> --

Social Web Architect
http://bblfish.net/

Received on Tuesday, 1 May 2012 09:55:54 UTC