[Dnssec-deployment] Root Zone DNSSEC Deployment Technical Status Update
thierry.moreau at connotech.com
Mon Jul 19 10:46:13 EDT 2010
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.
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 (). 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 ... !
- Thierry Moreau
 Look at the consultation document announced at
More information about the Dnssec-deployment