Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-bis-updates-09.txt

From: [email-masked]
Date: Sat, 5 Sep 2009 14:30:04 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Clarifications and Implementation Notes for DNSSECbis
	Author(s)       : S. Weiler, D. Blacka
	Filename        : draft-ietf-dnsext-dnssec-bis-updates-09.txt
	Pages           : 12
	Date            : 2009-09-05

This document is a collection of technical clarifications to the
DNSSECbis document set.  It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 07 Sep 2009 10:13:45 +0200

> 	Filename        : draft-ietf-dnsext-dnssec-bis-updates-09.txt

There is still this text:
4.9. Nested Trust Anchors

   A DNSSEC validator may be configured such that, for a given response,
   more than one trust anchor could be used to validate the chain of
   trust to the response zone.  For example, imagine a validator
   configured with trust anchors for "example." and "zone.example."
   When the validator is asked to validate a response to
   "www.sub.zone.example.", either trust anchor could apply.

   When presented with this situation, DNSSEC validators SHOULD try all
   applicable trust anchors until one succeeds.

   There are some scenarios where different behaviors, such as choosing
   the trust anchor closest to the QNAME of the response, may be
   desired.  A DNSSEC validator MAY enable such behaviors as
   configurable overrides.

Proposed text by me:

   When presented with this situation, DNSSEC validators SHOULD try all
   applicable trust anchors until one succeeds.  If a higher trust
   anchor is used, the chain of trust MUST pass the name of the
   lowest trust anchor securely (or the answer becomes bogus).
   In the example, the name zone.example. must be signed even if
   the example. trust anchor is used.  So example. provides a signed
   DS towards zone.example. that makes the zone.example. keys
   validate securely. This defeats a downgrade attack by poisoning the
   zone.example. DNSKEY answer if example. has an unsigned delegation
   to zone.example.

The reason I want this is if everyone has a root trust anchor, but
many TLDs are not signed.  Then some people will configure lower
trust anchors, say for example.com.  If someone now poisons the
example.com DNSKEY record so it fails, then going back to the
root key and unsigned .com is a downgrade on the security of
example.com.  Therefore the 'try all trust anchors' is a security
problem.

This can be common if SLDs deploy DNSSEC before TLDs.

Of course this is the reason for the override discussion already
in the draft, since some people may not trust their parents with
security.  This concern is similar, but deals with unsigned TLDs.
Of course I could loosely interpret the existing text and by
default enable those configurable overrides ...

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Sep 2009 08:25:37 +1000

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkqkwLkACgkQkDLqNwOhpPizJQCeKm4ZI+8UpJUdKVBCT8AdMg6O
> H6QAn2eMJ2aadKra5AH8Q9iZFBInqrg3
> =rqXc
> -----END PGP SIGNATURE-----

	Neither text is right.  You want to choose any trust anchor
	at the deepest level and only move past a trust anchor if
	explicity configured to do so

	This is the only default secure policy that is possible.

	Even if you do move past you still need to remember that
	you got a bogus result from a deeper trust anchor and you
	can't accept insecure from the upper validation.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]