Re: [pkng] fyi: keyassure@ mailing list - aka tls@dnssec, certs/keys-in-DNS(sec), DKI

[Stephen Farrell <[e-mail]>]

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 ([e-mail], 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: [e-mail]
> Date: Wed, 18 Aug 2010 09:50:29 +0200
> To: [e-mail]
> 
>     (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).
> 
>