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/
- Re: [keyassure] publishing the public key Henry Story
- [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Ilari Liusvaara
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Martin Rex
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Martin Rex
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Scott Schmit
- Re: [keyassure] Issue #14 - publishing the public… Warren Kumari
- Re: [keyassure] Issue #14 - publishing the public… Paul Hoffman
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Ilari Liusvaara
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Yaron Sheffer
- Re: [keyassure] publishing the public key Ilari Liusvaara
- Re: [keyassure] publishing the public key Yaron Sheffer
- Re: [keyassure] publishing the public key John Gilmore
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Phillip Hallam-Baker
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Phillip Hallam-Baker
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Phillip Hallam-Baker
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Paul Wouters
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Phillip Hallam-Baker
- Re: [keyassure] publishing the public key Peter Gutmann
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Stephen Kent
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Stephen Kent
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Paul Hoffman
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Henry Story
- Re: [keyassure] publishing the public key Stephen Kent
- Re: [keyassure] publishing the public key Henry Story