Re: [pkng] fyi: keyassure@ mailing list - aka tls@dnssec, certs/keys-in-DNS(sec), DKI
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 18 August 2010 23:31 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pkng@core3.amsl.com
Delivered-To: pkng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BD73A6875 for <pkng@core3.amsl.com>; Wed, 18 Aug 2010 16:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.758
X-Spam-Level:
X-Spam-Status: No, score=-102.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 hJqMFhPccqbv for <pkng@core3.amsl.com>; Wed, 18 Aug 2010 16:31:00 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 337F73A68DC for <pkng@irtf.org>; Wed, 18 Aug 2010 16:30:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7A133E4098; Thu, 19 Aug 2010 00:31:30 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1282174290; bh=O4bGyHenLrkj4G 09/munWShH4H3zAJR4XzhA5ZKxKYk=; b=0XRAEb3qn7XsRAKoGTZduBv224ZBPZ 8U0CZ0iiG3Q3q4WxgiNpUnFQZUKJIOiOG6s5O7GVeoBoYeANqIeIEVd1rAEA3B8X x2CVlTr8Dk/dWANxfb/U7yVC9QgqpzDHyqHSx9ITMkb9NPJpifkV0tVLQS8wU1W9 QWqH/4zB8Yc8qJlrGUWKJQ6E9lAFp/9CfJ5o9Tx6FPdNm7Voo12ZN93Ziqtvg3ST Y7g2plbz/9OX1QIE4WFatKzB1Jebs9hrI3d2DBE8MJY50KZv5vCXQD0NmMIBKRzB w7hxydeC5/8sbu9zLk5zBzE/1n5RLiOLEYGMqCZO+etW/EpbRON2jv/w==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fRfc+3kHZ916; Thu, 19 Aug 2010 00:31:30 +0100 (IST)
Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2CAF83E4096; Thu, 19 Aug 2010 00:31:29 +0100 (IST)
Message-ID: <4C6C6D4F.2020703@cs.tcd.ie>
Date: Thu, 19 Aug 2010 00:31:27 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4C6C6830.9040103@KingsMountain.com>
In-Reply-To: <4C6C6830.9040103@KingsMountain.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IRTF PKng WG <pkng@irtf.org>
Subject: Re: [pkng] fyi: keyassure@ mailing list - aka tls@dnssec, certs/keys-in-DNS(sec), DKI
X-BeenThere: pkng@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Public Key Next Generation \(PKNG\) Research Group" <pkng.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/pkng>, <mailto:pkng-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/pkng>
List-Post: <mailto:pkng@irtf.org>
List-Help: <mailto:pkng-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pkng>, <mailto:pkng-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2010 23:31:03 -0000
On 19/08/10 00:09, =JeffH wrote: > Of possible interest... Indeed. Seems like that list had more traffic in one day than this one in a year. (Well, I didn't actually count 'em up but it feels that way.) Personally, I reckon this means there is no point in this group at present, until the IETF BoF process plays out. I think that's a pity and maybe a missed opportunity (but of course, we'll never know, by definition;-) S. > > A new pre-BoF list (keyassure@ietf.org, see below) is discussing > certs/keys-in-DNS(sec) both as a way to augment present-day PKI, and as > a way to re-invent it. > > In addition to the various references helpfully listed below by Ondrej, > there's this recent preso by Dan Kaminsky, presented a couple weeks ago > at Black Hat... > > Black Ops of Fundamental Defense: > Introducing the Domain Key Infrastructure (DKI) > http://www.recursion.com/files/BlackOps-2010.pdf > > > =JeffH > ------ > Subject: [keyassure] You want to read this :) (Was: Welcome to the mailing > list, and possible charter.) > From: ondrej.sury@nic.cz > Date: Wed, 18 Aug 2010 09:50:29 +0200 > To: keyassure@ietf.org > > (text/plain) > Just to add some reading material to the mailing list archive... > > You may want to read: > > New I-D by Jakob, Paul, Warren and Adam: > http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt > > > Slightly older CERT RR (which we already have): > http://tools.ietf.org/html/rfc4398 > > And various older proposals which didn't make it: > > (Jakob's) > http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt > > (RR TYPE request I did) > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00421.html > > This is just to summarize the ideas which were floating around for some > time. The basis on our work will be in the most recent I-D. > > > On 17.8.2010 19:21, Warren Kumari wrote: >> Hello all, >> >> We are investigating starting a working group to leverage the DNSSEC >> trust anchor as a trust anchor for various other protocols. We are >> initially focusing on TLS, but are also interested in other >> protocols. >> >> Just so that we are all level set, here is our initial (draft) >> problem statement. >> >> Problem Statement: >> >> The DNS Security Extensions are a collection of resource records and >> protocol modifications that provide source authentication for the >> DNS. >> >> The DNSSEC signed root infrastructure provides a single, well >> published trust-anchor and a method to build a chain of trust from an >> individual resource record (RR) to that TA. By leveraging this >> infrastructure we can securely bind information (such as a public >> key, certificate identifier, etc) to a DNS name. >> >> Increasingly people would like to be able to take advantage of the >> confidentiality and identity validation provided by protocols such as >> TLS. There are numerous barriers to this, including cost, ease of >> use, complexity, certificate management, etc. By allowing users to >> securely publish public key information we can allow users to easily >> and securely make use of self-signed certificates. >> >> Currently, one of the issues limiting the use of self-signed >> certificates is the difficulty in key-distribution - it is infeasible >> to distribute a key binding at the web scale. By providing a means to >> publish (and securely validate) this information in the DNS, we allow >> for users to attest to the validity of keying information and >> establish trust in the published public key. >> >> The DNSSEC root trust anchor can also be used for additional >> validation during the current path validations. By validating that >> the certificate presented is the certificate identified by the DNS, >> we can provide additional confidence that the client is connecting to >> the intended server - this helps alleviate concerns that a valid >> certificate has been obtained by an attacker (for example from a CA >> not used by the victim). > >
- [pkng] fyi: keyassure@ mailing list - aka tls@dns… =JeffH
- Re: [pkng] fyi: keyassure@ mailing list - aka tls… Stephen Farrell
- Re: [pkng] fyi: keyassure@ mailing list - aka tls… Paul Hoffman
- Re: [pkng] fyi: keyassure@ mailing list - aka tls… Stephen Farrell
- Re: [pkng] fyi: keyassure@ mailing list - aka tls… Massimiliano Pala