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

Anand Kumria akumria at acm.org
Mon Jul 19 09:45:39 EDT 2010


Hi Peter,

On Mon, Jul 19, 2010 at 1:29 PM, Peter Koch <pk at isoc.de> wrote:
> On Mon, Jul 19, 2010 at 11:03:47AM +0100, Anand Kumria wrote:
>
>> >        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.
>
> the issue is the semantics of a DNSSEC signature.  Since DNSSEC is about
> data origin authentication, the signature is merely an attestation of
> the signer that some RRSet originated from within the zone.  No statement
> is made about the correctness of the data. Therefore, the binding of

I guess I am missing your specific.

www.example.com A 127.0.0.1

And?

Or

www.example.com CERT <...>


> some key material to a domain (in the sense of 'node in the DNS hierarchy')
> is explicitly not achieved.  The zone maintainer says they put the
> RRSet into the zone, not that they verified any of its properties,
> which holds for an A RRSet the same way as for a CERT RR(Set).

Okay, so you see the fact that DNS is just a record store.

We now have a way to determine if tampering has occurred. Since we can
use it to be confident that the data that was in the zone is what we
received, why not use it?

> Now, this may be all 'better than nothing' or 'good enough' or 'opportunistic'
> (in some positive spirit) or even 'not worse than what today's certificate
> practices', but the difference remains.  Think liability.

I'm thinking about it. I am not seeing a problem.

Presumably you are talking about material funds -- in which case I'm
sure that Visa / Mastercard / etc (who came up with such schemes as
'VerifiedByVisa', etc.; which is a great security hole) which figure
out the best way to move the liability to either the supplier or
consumer.

Cheers,
Anand


More information about the Dnssec-deployment mailing list