Re: [keyassure] publishing the public key

Henry Story <henry.story@bblfish.net> Mon, 14 February 2011 17:59 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 055B63A6D5C for <keyassure@core3.amsl.com>; Mon, 14 Feb 2011 09:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.649
X-Spam-Level:
X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, 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 cl6Lu0e9wP7Z for <keyassure@core3.amsl.com>; Mon, 14 Feb 2011 09:59:19 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 62AC93A6AB3 for <keyassure@ietf.org>; Mon, 14 Feb 2011 09:59:19 -0800 (PST)
Received: by bwz12 with SMTP id 12so6281624bwz.31 for <keyassure@ietf.org>; Mon, 14 Feb 2011 09:59:42 -0800 (PST)
Received: by 10.204.14.6 with SMTP id e6mr1052082bka.9.1297706381856; Mon, 14 Feb 2011 09:59:41 -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 w3sm1909873bkt.5.2011.02.14.09.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 09:59:37 -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: <201102141733.p1EHXFfR005827@fs4113.wdf.sap.corp>
Date: Mon, 14 Feb 2011 18:59:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5AD961D-5495-4B45-8B69-4FB96524A238@bblfish.net>
References: <201102141733.p1EHXFfR005827@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 17:59:21 -0000

On 14 Feb 2011, at 18:33, Martin Rex wrote:

> Paul Wouters wrote:
>> 
>> On Mon, 14 Feb 2011, Henry Story wrote:
>>> 
>>> Why not publish the only piece of the certificate that is important
>>> in public key cryptography: the public key.
>> 
>> Yes. This was asked by others including me as well. People thought it would
>> be no problem to add this to dane once a bare public key TLS method exists.
>> 
>>>  An important question is of course: how much bandwidth does one save?
>> 
>> Bandwidth does not really matter. What matters is latency
>> (less round trips) and a riddance of ASN.1 parsing.
> 
> 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.

From WebID's perspective we love keyassure, because it will make deployment of https 
so much easier, and so make it much easier to create the Secure Decentralised 
Social Web which we want to build.  In fact we have an issue open there to follow 
your work here

 http://www.w3.org/2005/Incubator/webid/track/issues/5

It also permits "Turning every Web Server into a CA"
http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html

which is pretty cool I think.

 So all of the above will work as keyassure is written out now, but I do 
think that if one can reduce the bandwidth used by DNSSEC as much as possible
as well as get the best value for the bits used - which I think the public key
does - all the better. That will reduce the talk of DNS as a Denial of Serice 
Attack amplifier.

	Henry

> 
> -Martin

Social Web Architect
http://bblfish.net/