[Dnssec-deployment] Root Zone DNSSEC Deployment Technical Status Update

Anand Kumria akumria at acm.org
Mon Jul 19 06:03:47 EDT 2010


Hi Bill,

On Mon, Jul 19, 2010 at 5:43 AM,  <bmanning at vacation.karoshi.com> wrote:
> On Sun, Jul 18, 2010 at 06:18:56PM -0400, Paul Wouters wrote:
>> On Sun, 18 Jul 2010, Tony Finch wrote:
>>
>> >>indeed.  and let's give credit where due -- because there are still no
>> >>external applications that add value in the face of this metadata, the
>> >>biggest reason we finally have a signed root and growing cadre of signed
>> >>tld's and sld's is because of... dan kaminsky's bug.
>> >
>> >Yes, but "no apps that add value" is an exaggeration - ssh is one
>> >counterexample.
>>
>> And the current thinking/revival of moving SSL certs out of the (broken)
>> CA infrastructure and into the DNSSEC infrastructure. Another example
>> could be the browers querying for the existence of an "SSL" cert in DNS, and
>> automatically starting out using https instead of http. (I wonder if that
>> could be done with a new edns option or additional data to reduce this to
>> one query)
>
>        thats a horiffic idea.  application level certs in the DNS
>        is right up there with HINFO ... with one minor (critical) error
>        that was not present for HINFO.  There is zero plausable denyability
>        for a node running an app.

You mean, like having a SRV record indicating where a protocol is best used?

Or an MX record indicating the best mail servers for a domain?

Could you elaborate some more.

>        last I checked Trust was NOT transitive.  Trust in the DNS heirarchy
>        does not equate to trust in the sysadmin of a node.  Your example
>        above presumes that such will be the case.  What am I missing here?


You are missing that for some sites, trust is transitive. And that,
really, DNSSEC + CERT records (with a signed DNS root) is a good way
to validate self-signed certificates.

We are already looking at tighter integration between application and
DNS (e.g. domainkey signed email), so why should this potential
application bother you?

>
>> And IPsec Opportunistic Encryption.
>>
>> People will come up with more new things. I personally hope to see
>> identity verification via DNSSEC zones associated with email addresses
>> or verification of OTR identities via DNSSEC protected records.
>
>
>        Scary stuff there Paul.

Indeed. Who wanted to protect their network, if they can.

Cheers,
Anand


More information about the Dnssec-deployment mailing list