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

From: =JeffH <[email-masked]>
Date: Wed, 18 Aug 2010 16:09:36 -0700

Of possible interest...

A new pre-BoF list ([email-masked], 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: [email-masked]
Date: Wed, 18 Aug 2010 09:50:29 +0200
To: [email-masked]

	(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).

-- 
   Ondřej Surý
   vedoucí výzkumu/Head of R&D department
   -------------------------------------------
   CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
   Americka 23, 120 00 Praha 2, Czech Republic
   mailto:[email-masked]    http://nic.cz/
   tel:+420.222745110       fax:+420.222745112
   -------------------------------------------
_______________________________________________
keyassure mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyassure

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Aug 2010 00:31:27 +0100

> 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.

> 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...
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 16:36:57 -0700

>of course, we'll never know, by definition;-)

Not at all. PKNG's charter is to "look into alternate certificate formats, semantics, and PK services that could eventually replace PKIX if deployed".

The new mailing list is aimed at protocols that use PKIX certificates, and the draft that I co-authored is specifically about TLS, which requires a PKIX certificate to identify the server.

This list can still be useful within our charter if folks get get some creative juices flowing around the idea of alternate formats, semantics, and services.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Aug 2010 01:00:41 +0100

> Not at all. PKNG's charter is to "look into alternate certificate formats, semantics, and PK services that could eventually replace PKIX if deployed".

Right. Zero documents and a moribund list seem to imply the
charter was wishful thinking.

> This list can still be useful within our charter if folks get get some creative juices flowing around the idea of alternate formats, semantics, and services.

(Don't I recall you saying that new format work was exactly
what you didn't want to happen first?)

Look, if something does start to happen here, then that'd be great.
All I'm saying is that given the (lack of) history here and the
evident interest in websockets/keys-in-DNS et al I suspect the
relevant CPU cycles are going to be invested elsewhere for the
next while. I'd be delighted to be proven wrong.

S.

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 18 Aug 2010 23:58:24 -0400

Hi Stephen, all,

I would say that I am more with Paul on this. I do think that there's a real
need to re-invent the PKIs, especially in the way they are deployed. Indeed,
it is quite difficult to provide interoperability among different infrastructures
also when cross-certification is used.

I have been pushing back my contribution to this list because of the huge load
of work.. unfortunately it does not look better in the near future :) But, as
soon as I find some funds to work on my ideas (always the same problem, isn't
it?) I will try to write an initial document that the list could work on.

The current areas I am planning on working on are:
- trust infrastructure service discovery
- support for PKIX (and non-PKIX) trust infrastructures
- dynamic federation support
- scalability

My plan is to approach these problems by providing an underlying collaborative
infrastructure that will enable the deployment of a globally distributed trust
infrastructure for the Internet.

Work in Progress..

    -- Max

On 08/18/2010 08:00 PM, Stephen Farrell wrote:
>> Not at all. PKNG's charter is to "look into alternate certificate formats, semantics,
>> and PK services that could eventually replace PKIX if deployed".
>
> Right. Zero documents and a moribund list seem to imply the charter was wishful
> thinking.
>
>> The new mailing list is aimed at protocols that use PKIX certificates, and the draft
>> that I co-authored is specifically about TLS, which requires a PKIX certificate to
>> identify the server.
>>
>> This list can still be useful within our charter if folks get get some creative
>> juices flowing around the idea of alternate formats, semantics, and services.
>
> (Don't I recall you saying that new format work was exactly what you didn't want to
> happen first?)
>
> Look, if something does start to happen here, then that'd be great. All I'm saying is
> that given the (lack of) history here and the evident interest in
> websockets/keys-in-DNS et al I suspect the relevant CPU cycles are going to be invested
> elsewhere for the next while. I'd be delighted to be proven wrong.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov