Re: [TLS] Fixing TLS Trust

Martin Rex <mrex@sap.com> Mon, 30 April 2012 17:16 UTC

Return-Path: <mrex@sap.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 1C97A21F87FA for <tls@ietfa.amsl.com>; Mon, 30 Apr 2012 10:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.127
X-Spam-Level:
X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 xA7DLkLtLu8o for <tls@ietfa.amsl.com>; Mon, 30 Apr 2012 10:16:50 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB19E21F8802 for <tls@ietf.org>; Mon, 30 Apr 2012 10:16:49 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UHGl9f024199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 19:16:47 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201204301716.q3UHGkwW019079@fs4113.wdf.sap.corp>
To: henry.story@bblfish.net
Date: Mon, 30 Apr 2012 19:16:46 +0200
In-Reply-To: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> from "Henry Story" at Apr 30, 12 06:46:57 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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:16:51 -0000

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


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