Re: [keyassure] publishing the public key

Henry Story <henry.story@bblfish.net> Mon, 14 February 2011 19:06 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6085F3A6D9B for <keyassure@core3.amsl.com>; Mon, 14 Feb 2011 11:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level:
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BSB8XBnmrbO for <keyassure@core3.amsl.com>; Mon, 14 Feb 2011 11:06:46 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 313573A6D9A for <keyassure@ietf.org>; Mon, 14 Feb 2011 11:06:45 -0800 (PST)
Received: by fxm9 with SMTP id 9so6054335fxm.31 for <keyassure@ietf.org>; Mon, 14 Feb 2011 11:07:09 -0800 (PST)
Received: by 10.223.100.2 with SMTP id w2mr5048588fan.115.1297710428813; Mon, 14 Feb 2011 11:07:08 -0800 (PST)
Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id a6sm1091486fak.1.2011.02.14.11.07.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 11:07:07 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <201102141829.p1EITKHc009151@fs4113.wdf.sap.corp>
Date: Mon, 14 Feb 2011 20:07:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4487480D-900D-4416-8437-583693908163@bblfish.net>
References: <201102141829.p1EITKHc009151@fs4113.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
Subject: Re: [keyassure] publishing the public key
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Feb 2011 19:06:48 -0000

On 14 Feb 2011, at 19:29, Martin Rex wrote:

> Henry Story wrote:
>> 
>>> The current approach of admins to run a TLS server with a bare public
>>> key is to generate themselves a self-signed (X.509v1) Certificate.
>>> That is probably what many folks are doing when protecting Web access to
>>> their HomeNAS, Home DSL-router, Home DVB-s receiver, etc.
>>> 
>>> This works with the installed base, in particular with the installed
>>> base of servers.  Though it doesn't work that well with Web Browsers
>>> as clients.  In particular, many recent browers are pretty badly broken
>>> when it comes to a sensible UI for servers using a self-signed cert.
>> 
>> Indeed, and this is why keyassure is going to be so useful for those people. 
>> They must just be itching to pop their public keys in DNSSEC as soon as the 
>> first browser vendors implement it. So you are guaranteed a large community
>> to spread the word and give you feedback. And I think Browser Vendors will
>> be very keen to implement this, as well as DNSSEC of course, given the
>> terrible state of DNS.


I was thinking of the issue brought up by the EFF SSL Observatory project, 
that they presented at the Choas Communication Congress in Berlin right
after Christmas 2010 in a talk entitled "Is the SSLiverse a safe place?"

    https://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html

And you can get video on youtube. In particular if you look at slide 10 (of 56)
 
    http://www.youtube.com/watch?v=VUKCDm04AqI&feature=player_detailpage#t=631s

They point out that of the 16.2 Million servers listening to port 443 , only 11.3 Million
started an SSL handshake, and only 4.3 Million had a valid cert chain. So that means that
there are immediately 7 Million servers which could be helped if getting an SSL certificate
could be made a lot easier. And this is not counting how many others would start deploying
SSL if it was easier to do.

   I can't remember if in their presentation they tell us how many valid self
signed certs they found out there... One couls download the DB you query it locally...



> Not at all.  The average Home user (private home DSL subscriber) is
> not a DNS admin, let alone a DNSSEC admin.  So for accessing the Web-UIs
> Home devices/equipment/gadgets, DANE will be mostly irrelevant.

Ah you mean for accessing the SSL protected internal servers....

> 
> But maybe some of the Browser maintainers fix their UIs and start
> to distinguish direct access to local resources on private networks
> (such as 192.169.x.x and 10.x.x.x and hostnames without domains attached)
> from access to resources on the internet.  And stop behaving like nagware
> for commercial CAs.

I see what you are getting at...

Interesting thought. It's tricky as to how one should do that correctly without there
being a danger in large organisations of people putting up evil SSL proxies.

Perhaps the following could work. Imagine that these devices come shipping with DNSSEC servers that work internally  to resolve those addresses, and which use keyassure to publish the public key... Perhaps  there is something at the DNSSEC level that can be done there...? 

Henry

> 
> -Martin

Social Web Architect
http://bblfish.net/