[dnssec-deployment] Continued comments on DNSSEC plenary discussion paper

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

The paper is an interesting read, and the writing is good.  I want to
note that stub validators are entirely possible.  They can fetch the
required data and signatures from their upstream full recursive resolver
(whether that upstream full recursive resolver cache performs validation
or not).  (How? DNSKEY and DS queries to the upstream resolver).  I
should know, because unbound can do it.

Personally, I like the deployment where initially ISPs start validating
their caches, since protecting against cache poisoning drives them.  And
then stub validation can be deployed, securing the last mile and also
bringing more information closer to the end-user application, the
end-user may be driven by software update, dnssec-application features
or last-mile security.

In general, I think trust in upstream full recursors is incidental. Only
in corporations or places with centralised control anyways.  Otherwise,
it would be unwise to trust an upstream full recursor, even if the path
is secured by leap of faith.  The local cafe free internet you are using
may not be run by the local cafe and so on.  In corporations you have
the trust required to deploy TSIG or IPSEC keys and establish the last
mile that way.

The article talks at length about zone operator, registry, registrar
trust, but in the end the end-user that runs the validator has to trust
the TAR.  So, for example some giant RFC5011-operated publication TAR,
or the secspider initiative fall in that category.

About 'delegation centric', the term Top Level Domain (TLD) is much
easier here.

About parent-child DS communication.  Why cannot the parent have in that
web interface the checkbutton option 'track DS'.  The parent can then
pick up the SEP keys and create DS records on a regular schedule.
Having extra DS records does not hamper resolution.  For example by
deploying autotrust aimed at its child domains, and doing ldns-key2ds on
the keys.  The child operator can perform manual changes with the web
interface in emergencies.  In terms of registrar/registry, both could
provide this option.  (Oh, and pick up the NS records as well, and you
solve a lot of regular deployment trouble).

Best regards,
   Wouter

Paul Wouters wrote:
> On Tue, 6 Jan 2009, Edward Lewis wrote:
> 
>> What is in the paper is a discussion of TARs, some observations that manual
>> maintenance won't work (okay, scale), how all this plays with applications and
>> means to secure the stub resolver channel to the verifier.
>>
>> In general, I think the achilles heel of TARs is the trust model. Perhaps TARs
>> will be the PGP to the DNS hierarchy's X.509 for some time.  Section 5.3 seems
>> to me to describe the real nightmare scenario that will result from an
>> unsigned root.
> 
> The world will not end without a signed root. It just means some people need to
> maintain keys within operating system distributions until it is signed. There is
> already a trust model in use there (signed packages, trusted contributors, etc)
> Then there is RFC5011 (eg autotrust) to try doing updates even without an OS
> distributor taking care of proper maintenance.
> 
> The last mile AD bit problem is completely different from the TAR discussion.
> 
> Paul
> 
> #############################################################
> This message is sent to you because you are subscribed to
>   the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/>
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklka58ACgkQkDLqNwOhpPjPLgCeMRJ+snvqq/cQecgUFJa1xgMP
TKIAoIrdlHjTXlfteqURjAez+a0b9AvB
=7UFk
-----END PGP SIGNATURE-----