Re: [TLS] Fixing TLS Trust

Nico Williams <nico@cryptonector.com> Mon, 30 April 2012 19:57 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD87621F867B for <tls@ietfa.amsl.com>; Mon, 30 Apr 2012 12:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZBuOu-mB90M for <tls@ietfa.amsl.com>; Mon, 30 Apr 2012 12:57:54 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1351B21F867A for <tls@ietf.org>; Mon, 30 Apr 2012 12:57:54 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 93CAD10049 for <tls@ietf.org>; Mon, 30 Apr 2012 12:57:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=f+RgL6+84FIr7LesZxKziNlhVrYedwik3OxWo0XmfVe1 iWpaVDlBvQTS1P1XctH1gbZXaJFS6Fc2ddm/Wkw64LwRbhsKsDmnenVOlW8uTtGW WbkqXRmBnfNSPd0AXLFzgGmDNzOYa5nALAjPLQVmJPEe24wZJebuxOFPunEN8A8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=oMWY2HlVpqk4G4u75AWnYpRS25k=; b=aIaw9eQoRvP K9klWi8pdxbX7pOwmuAP3tIMz3M3RNsaIXw6yj+80/2QKwH2i8P7P+yaEHRI43a7 8/gHQzOHcckp2qM9FDi8b20ingBYKE5Y5wNzWkfpsdDWufFsRHZH5mPpVwj52Hsx ZpOUWtR+2pZAP8KoPqERR5n4bjMqNFkQ=
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 7B98310060 for <tls@ietf.org>; Mon, 30 Apr 2012 12:57:53 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so890960pbc.31 for <tls@ietf.org>; Mon, 30 Apr 2012 12:57:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.221.10 with SMTP id qa10mr50386393pbc.139.1335815873175; Mon, 30 Apr 2012 12:57:53 -0700 (PDT)
Received: by 10.68.28.6 with HTTP; Mon, 30 Apr 2012 12:57:52 -0700 (PDT)
In-Reply-To: <07B7828B-DF75-446E-AF6E-6A16BD9F9146@bblfish.net>
References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> <CAK3OfOjeruZmky1pwgSzodLt0uRNjpQc8GaC6=Qt_FLW6WkeBg@mail.gmail.com> <07B7828B-DF75-446E-AF6E-6A16BD9F9146@bblfish.net>
Date: Mon, 30 Apr 2012 14:57:52 -0500
Message-ID: <CAK3OfOj1amR5pcw+TB4rEXpeUUu9AyRkJBK7wWTkHtsyw0-_6w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Henry Story <henry.story@bblfish.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org List" <tls@ietf.org>, public-webid <public-webid@w3.org>
Subject: Re: [TLS] Fixing TLS Trust
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 19:57:54 -0000

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

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

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

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

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