Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 18 Dec 2010 12:32:09 -0600 (GMT-06:00)

Matt and all,

-----Original Message-----
>From: Matt McCutchen <[email-masked]>
>Sent: Dec 18, 2010 12:13 PM
>To: James Cloos <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>
>On Sat, 2010-12-18 at 12:54 -0500, James Cloos wrote:
>> >>>>> "MM" == Matt McCutchen <[email-masked]> writes:
>> 
>> >>> Unless the client previously noted that a given remote uses DANE,
>> >>> how can it tell that a non-secure DNS lookup is a MITM attack and
>> >>> not just a legacy site?
>> >> 
>> >> It can't.  According to Matt's suggested text:
>> 
>> Which of course was my point. ☺
>> 
>> MM> It can, because legacy sites have a NSEC for the DS record in the
>> MM> parent zone.  That was our point here:
>> 
>> MM> http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.html
>> 
>> Why do you think that a MITM would only munge a child zone and not also
>> its parents?
>
>By configuring a trust anchor for the root zone, you are telling the
>client to demand that the zone be signed with that key.  It will not
>allow the entire DNSSEC to be downgraded away.  For it to accept a site
>as legacy ("insecure"), there must be an NSEC for DS somewhere above the
>site that chains to the trust anchor.
>
>This is basic DNSSEC stuff explained in RFC 4033.  I would rather not
>keep rehashing it here.

  What RFC 4033 does say is in regards to this is the following:
"Even a security-oblivious stub resolver may benefit from DNSSEC if
   the recursive name servers it uses are security-aware, but for the
   stub resolver to place any real reliance on DNSSEC services, the stub
   resolver must trust both the recursive name servers in question and
   the communication channels between itself and those name servers.
   The first of these issues is a local policy issue: in essence, a
   security-oblivious stub resolver has no choice but to place itself at
   the mercy of the recursive name servers that it uses, as it does not
   perform DNSSEC validity checks on its own.  The second issue requires
   some kind of channel security mechanism; proper use of DNS
   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
   Particular implementations may have other choices available, such as
   operating system specific interprocess communication mechanisms.
   Confidentiality is not needed for this channel, but data integrity
   and message authentication are."

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

>
>-- 
>Matt
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 18 Dec 2010 15:09:11 -0500

>    and message authentication are."

That is a separate issue.  We assume the client does not enable DNSSEC
unless it performs the validation itself or has a secure connection to a
resolver it trusts, as is implicit in the definition of a
"Security-Aware Stub Resolver" in RFC 4033 section 2.

The relevant text is this:

   Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as
      insecure.

   Bogus: The validating resolver has a trust anchor and a secure
      delegation indicating that subsidiary data is signed, but the
      response fails to validate for some reason: missing signatures,
      expired signatures, signatures with unsupported algorithms, data
      missing that the relevant NSEC RR says should be present, and so
      forth.

If a query gives an "insecure" result, a DANE client can fall back to an
alternative method without risk of a downgrade attack.

-- 
Matt