Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

["W.C.A. Wijngaards" <[e-mail]>]

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

Hi dnsop,

The sentiment over the last week is that retired keys should not be
abused, and trust-history is then gone, with such opposition by WG.

I do have to renew the root anchor when it changes.  Let's look at the
'fetch from iana again' method in detail.  Obviously I assume the
machine is also performing 5011, but this has not been sufficient and
thus a refetch has become necessary.  But I do not like to make too many
assumptions, so I am going to try to call out all of the (hidden)
assumptions that 'fetch from a URL' means.  So that you can choose
explicitly the ones that are ok.

* The URL that iana published in their description is:
  https://data.iana.org/root-anchors/root-anchors.xml
* 'widely available trust certificates' to verify the https

Are you sure that we want to create a cross-dependency on the https
security for the DNS security?  This means the DNS and cert paths are no
longer different trust paths.  And we should look at the attack vectors
here.  If the root-key-prime fails, it is likely the machine will
initiate this update machinery right away.  Assume a full MitM; say on a
middlebox; it can make the root-key-prime fail and intercept traffic to
that URL.

If you know 5011 is on, you can have a 30-day delay.  (described in more
detail in that trust-history draft).  But then someone faking NTP might
subvert this mechanism if that makes the client reset its date.

Also, there is no trustworthy DNS resolver while this https fetch is
executed.  Should I hardcode the IP address?  (192.0.32.25?)  An
alternative is to resolve the (bogus) name and use that, but it means
having a special-purpose https implementation that has the ability to
call the resolver to lookup (bogus) names without DNSSEC validation
while the root anchor is updated.  (and that might also need to lookup
certificate revocation lists and so on).

The certificates, well we could use the current public key that IANA
uses, and hardcode that in the resolver.  It is currently signed until
8/29/2011.  Or insert root certificates, or use the
system-certificate-list (if such a thing exists).  I notice the one used
by IANA is valid until 2038.  Is 28 years sufficient?  What do I do when
the root certificate(s) have expired?  (or, when the local clock seems
to indicate they have; that clock may be off).

I could perform a blind leap of faith, and simply accept the new root
key, or fetch the root key using a http session to a bogus IP-address.
This would likely work and give users an experience.

The file is in XML.  It is described in
http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt
I would like to fix its format, as XML string operations are (in my
opinion) dangerous - especially for a file someone can force me to parse
by triggering a validation failure for the root.  It is also in UTF-8,
that needs unicode conversion?  I really have to have a full XML parser?
 I would assume the file uses the ascii set and no change in linebreaks
from today.

Also, if I make a special-purpose https. what version of http is
assumed?  I would assume plain GET, no http stuff, no sslv2.

Does the user have to be informed?  You can decide that automatic update
is forbidden and users must be active.  I would like automatic.
The PGP key route is nice if you get it; it precludes automation.

Is all this worth it, if compared with the trust-history proposal?

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkyTQsEACgkQkDLqNwOhpPg+OACeM8Mq6nALqXUPqYbZiKIDwUmd
LJgAnR3prLV6L48pRu1jEXtKdCz+vgSW
=9JLX
-----END PGP SIGNATURE-----