Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

From: Samuel Weiler <[email-masked]>
Date: Mon, 12 Mar 2012 15:08:42 -0400 (EDT)

Most of the WGLC comments in this thread were addressed in Andrew's 
"issues" thread and are addressed, in some form, in the forthcoming 
-17.  I'm trying to catch any others.

On Fri, 20 Jan 2012, Edward Lewis wrote:

> In 2005 it was too soon to publish, now it is not.  And at this point there 
> may be more and more wrinkles in the DNSSEC specs, but we need to get out at 
> least this (first) update.

Thank you.

> Pressence has a presence in the document.  It shouldn't (the spelling, I 
> mean).

Fixed (and thanks to the others who also caught this).

> 5.9's title is misleading.  The content is good, it's about answering from 
> cache in the face of a CD query.  But "always doing CD" only applies to 
> elements that will do their own validation.

Doesn't it also apply to a non-validating box in the middle?  That box 
may still need to return +CD data if something downstream wants it.

The only place I see it not applying is stub resolvers.  Rather than 
alter the title (since I couldn't think of a good way to do it), I 
propose adding a paragraph saying "this doesn't apply to stub 
resolvers".

> 5.4 could optionally make the point that a validator that expects all 
> signatures to be good and/or all chains to work is vulnerable to malicious 
> insertions of gibberish-based signatures.  It's harder to construct a good 
> chain than a false chain.

Added a line.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 12 Mar 2012 15:20:37 -0400 (EDT)

On Wed, 25 Jan 2012, W.C.A. Wijngaards wrote:

> The section and appendix on CD bits are long.  Not wrong, but long.
> With the root trust anchor deployed, not having a covering trust anchor
> is unlikely.

I know.  As Andrew said in the summary thread, he insisted.

> Section 6.2 is correct.  But its tone is loose.  It is about lenient
> acceptance of the SEP flag.  Please say that, or say that the proper
> setting of the SEP flag is defined in its RFC.

There are actually two things in here: one is about the SEP bit, the 
other is about using DNSKEYs in odd ways.  I think both need to stay, 
but your point about loose language is well taken.  I propose to 
reword the first two paragraphs to clean that up.

Thank you for your review.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 12 Mar 2012 15:55:31 -0400 (EDT)

On Wed, 1 Feb 2012, Matthijs Mekking wrote:

> 1a. Nit
> The second paragraph raises concerns when a resolver adopts a more
> restrictive security policy. On the first read, it is not immediately
> obvious why there can be unnecessary validation failures. Perhaps a
> small explanation is needed, that the restrictive policy is requiring
> all signatures to validate?

Perhaps.  I decided not to change anything on this pass.

> 2b.
> The section states that a signed zone MUST include a DNSKEY for each
> algorithm present in the zone's DS RRset and expected trust anchors for
> the zone. I argue if MUST is too strong, and would vote for SHOULD, for
> the reason that the expected trust anchors and DS RRset are being
> maintained outside the administrative boundaries of the zone owner.

The MUST should stay.  (The MUST must stay?)  You're right about 
administrative boundaries, but things break if these rules aren't 
followed.  They really are a MUST.

> 3. Section 6.4. Erros in RFC 5155
>
> I would like to see some clarifying or guiding text about the
> contradiction in this RFC on the Flags field I posted earlier to this list:
>
> Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs
> with a Flag fields value other than zero or one. But in the IANA
> Considerations section, bits 0-6 are available for assignment.
>
> However, assigning a meaning to one of the bits 0-6 would break NSEC3
> conformance because that would allow for Flag fields value larger than
> one and that conflicts with the rule in Section 8.2 . As a result,
> assigning a meaning to one of the bits 0-6 in the NSEC3 Flag fields
> would require an update at the resolver side to ignore the bits it does
> not implement, regardless of the total outcome value of the Flag fields.
> Such a requirement allows for a more flexible approach for future
> updates of the NSEC3 Flag fields, with a nice backwards compatibility
> property.

I understand the reasoning, but I'm not entirely sure what you're 
proposing.  And it does sound like a real change.  And one that may 
not match current code.  I'm not sure this is a great idea.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 12 Mar 2012 15:41:58 -0400 (EDT)

On Fri, 27 Jan 2012, Mohan Parthasarathy wrote:

> - Section 4.4 Insecure Delegation proofs last sentence is very
> confusing. An example as to what attack this is describing would be
> helpful to the implementer.

Here's an example of the attack we're trying to avoid.  Consider a 
signed zone that contains the names:
   alfa.example.com.
and
   bravo.alfa.example.com.

alfa.example.com is NOT a delegation.  Instead, it has this NSEC 
record:

 	alfa.example.com. 86400 IN NSEC host.example.com. (
 		A MX RRSIG NSEC TYPE1234 )

The quesion is: could an attacker use this NSEC record in reply to a 
query for bravo.alfa.example.com, replying with either a spoofed 
bravo.alfa.example.com or even claiming the name doesn't exist?  Under 
the old rules, read literally, that attack would work: the NSEC does 
not have a DS or SOA bit.  It also does not have an NS bit, but the 
rules did not say to check for that.

The forthcoming -17 has that section somewhat reworked.  There still 
is no example in.  Let us know if you really want that.

(note: the error is also broken, since bravo.alfa.example.com sorts 
before host.example.com.  maybe there are multiple ways to catch this 
attack.)

> - The "Security Considerations" section says:
>
>     This document adds two cryptographic features to the core DNSSEC protocol.
>
>    Is this referring to the algorithms mentioned in section 2.2 (
> which actually lists three)  or something else ?

clarified.

-- Sam

---

From: "Blacka, David" <[email-masked]>
Date: Mon, 12 Mar 2012 20:36:42 +0000

On Mar 12, 2012, at 3:41 PM, Samuel Weiler wrote:

> Here's an example of the attack we're trying to avoid.  Consider a signed zone that contains the names:
>  alfa.example.com.
> and
>  bravo.alfa.example.com.
> 
> alfa.example.com is NOT a delegation.  Instead, it has this NSEC record:
> 
> The quesion is: could an attacker use this NSEC record in reply to a query for bravo.alfa.example.com, replying with either a spoofed bravo.alfa.example.com or even claiming the name doesn't exist?  Under the old rules, read literally, that attack would work: the NSEC does not have a DS or SOA bit.  It also does not have an NS bit, but the rules did not say to check for that.

Actually, the question is: could an attacker use this NSEC record to spoof away actual signed records for alfa.example.com.  The attacker could return:

  ANSWER:
  AUTHORITY:
     alfa.example.com IN NS my.bad.server.
     alfa.example.com IN NS my.other.bad.server.
     alfa.example.com IN NSEC bravo.alfa.example.com A MX RRSIG NSEC TYPE1234
     alfa.example.com IN RRSIG NSEC …
  ADDITIONAL:
     ...

This looks superficially like a normal insecure delegation.  The NSEC record verifies and proves that there is no DS RRset.  The attacker then, on my.bad.server, can return whatever it likes for alfa.example.com A, or other types.

Thus, 4.4 says that you MUST check that the NS bit is set.

> 
> The forthcoming -17 has that section somewhat reworked.  There still is no example in.  Let us know if you really want that.
> 
> (note: the error is also broken, since bravo.alfa.example.com sorts before host.example.com.  maybe there are multiple ways to catch this attack.)
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

--
David Blacka                          <[email-masked]> 
Principal               Verisign Infrastructure Engineering

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 12 Mar 2012 17:24:05 -0400 (EDT)

On Wed, 1 Feb 2012, Paul Hoffman wrote:

> 5.10 is long, scary, and useless for most environments because most 
> environments will have just one trust anchor.

It is long and scary.  Earlier discussion on list discarded several 
ways of helping with that.  David and I came up with a new one: we 
stuck most of the text in an appendix.  It's still long, but maybe it 
will now be less scary.  I think this change is purely editorial; if 
we need to back it out later, we can.  Please let us know if you like 
it.

> 5.6 (setting the DO bit in replies) suggests resolvers should "be 
> liberal in what they accept". That's a bit vague. Instead, say ... 
> "Because some implementations ignore this rule on sending, the rule 
> for receivers is now that they MUST NOT expect the DO bit to be set 
> as it was sent."

We have added normative language.  I know Andrew was uneasy with that, 
having only heard from three of us (you, me, and David Blacka), but I 
continue to contend that this is the clearer way to say what we were 
saying anyway.  Andrew, if you need to flag this in the proto 
write-up, feel free.

-- Sam

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Mar 2012 11:18:32 +1100

I am still not happy with setion "5.9.  Always set the CD bit on Queries"
in draft-ietf-dnsext-dnssec-bis-updates-17.  The recommendation to always
set CD is flawed.  Recommending that CD always be set fails to take into
account normal expected operations issues and as such I do NOT recommend
that this document be published as is.

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

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 13 Mar 2012 10:38:20 -0700

On Mon, Mar 12, 2012 at 12:41 PM, Samuel Weiler <[email-masked]> wrote:
> The quesion is: could an attacker use this NSEC record in reply to a query
> for bravo.alfa.example.com, replying with either a spoofed
> bravo.alfa.example.com or even claiming the name doesn't exist?  Under the
> old rules, read literally, that attack would work: the NSEC does not have a
> DS or SOA bit.  It also does not have an NS bit, but the rules did not say
> to check for that.
>
When proving that the delegation is not secure (which is what this
section is talking about), the NSEC record has to match the name that
is being looked up. If the names don't match, then it can't be a
delegation. David's response clarified this.

> The forthcoming -17 has that section somewhat reworked.  There still is no
> example in.  Let us know if you really want that.
>
This is the new text:

   Without this check, an attacker could reuse an NSEC or NSEC3 RR
   matching a non-delegation name to spoof an unsigned delegation at
   that name.  This would claim that an existing signed RRset (or set of
   signed RRsets) is below an unsigned delegation, thus not signed and
   vulnerable to further attack.

Though the text is improved, it is easy to understand if you read this
text along with the example.

-mohan

> (note: the error is also broken, since bravo.alfa.example.com sorts before
> host.example.com.  maybe there are multiple ways to catch this attack.)
>
>