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

[Thierry Moreau]

Peter Koch 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
> 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).
> 
> 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.
> 
> -Peter
> 

This discussion angle is very interesting: bring up a new framework for 
"trust" dissemination in the net, and new usages are likely to appear.

I agree that Peter's observation are relevant and important. However, in 
practice, you have the following chain of digital signatories: root zone 
management, TLD management, DNS administration for the SLD zone 
including the CA administration, and the CA administration itself. Then 
look at "PKI Certification Practice Statements" (CPS) and "DNSSEC 
Practice Statements". The future TLD management may have the obligation 
to support DNSSEC and publish a "DNSSEC Practice Statement" (DPS), maybe 
even with minimal provisions ([1]). The DNS administration for the SLD 
might be viewed as bound by the CA CPS. Then the whole chain might be 
thought as being bound to xPS (x=C,D).

It's not that I believe it makes a difference (I am indeed very 
skeptical about the faith that can be put by anybody in xPS documents). 
The point is that xPS "applicability" in every link in the chain may be 
used to assert a greater semantic value as a justification for 
deployment. It's all a matter of semantic ... !

Regards,


- Thierry Moreau

[1] Look at the consultation document announced at 
http://www.icann.org/en/announcements/announcement-4-31may10-en.htm