Re: [TLS] Fixing TLS Trust

Henry Story <henry.story@bblfish.net> Mon, 30 April 2012 17:36 UTC

Return-Path: <henry.story@bblfish.net>
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 EE52D21E8047 for <tls@ietfa.amsl.com>; Mon, 30 Apr 2012 10:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 01yyaDOhtlbd for <tls@ietfa.amsl.com>; Mon, 30 Apr 2012 10:36:00 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9929A21E8048 for <tls@ietf.org>; Mon, 30 Apr 2012 10:35:57 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2447048bku.31 for <tls@ietf.org>; Mon, 30 Apr 2012 10:35:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QL+NhSLmGYIGv8rSjN/PWlosYXDKxjTGzI/u2iCEXlc=; b=RAXSPrRYJkQXOGC6PBgskphjUU6zbBzKIJnI7+IrtO+dFCqswfc0Dk/pQchqOeeH2f xOm6rYv9N3hQW2W/5gTRYGZ/vcECcfnWqwfdKiQTacgn9C3Zawggrrt5RqwpzTI0cDhw YC/Oy1URXpUj3rZT+ARAqnOr+IvegJrpDH4ReLWw2m4WlzQ/ovA+Wtspb0YqjgiDdKb7 CgBBnn1rmNGHsBoNn8skE0me0WCqC59C18u5r6Sm8AAPX7g3KxWJGqFcF8VLTNDabaub E2s+8zP5pv9zsSzdpub/YTZj4CJw16HxMNbc1LHUUeTOFGMRq8wQYsCI/cTBXDTqdWn4 pTiQ==
Received: by 10.204.155.147 with SMTP id s19mr1401828bkw.140.1335807356462; Mon, 30 Apr 2012 10:35:56 -0700 (PDT)
Received: from [172.23.42.56] (p5DDBB8B5.dip.t-dialin.net. [93.219.184.181]) by mx.google.com with ESMTPS id z14sm28146059bky.15.2012.04.30.10.35.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 10:35:55 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <201204301716.q3UHGkwW019079@fs4113.wdf.sap.corp>
Date: Mon, 30 Apr 2012 19:35:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <451221D8-4087-4687-9954-7FE78A6100F4@bblfish.net>
References: <201204301716.q3UHGkwW019079@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmkqiktY/oQayVooywGN7sYloLZUEWnTKbDpaU4eOlYPWlM6JT0B7qv3izpedSj3fTaXPSO
Cc: tls@ietf.org, 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 17:36:01 -0000

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.

On 30 Apr 2012, at 19:16, Martin Rex wrote:

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

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 
questions I put below:

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

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.

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

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

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

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.

> 
> So IMHO, the only way you could "increase (percieved) trust in the web"
> 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

> 
> -Martin
> 

Social Web Architect
http://bblfish.net/