Subject: [dnsext] a possible errata to RFC2136

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Nov 2009 13:10:41 +0900

On seeing the dynamic update DoS attack to BIND9:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0696
I've been wondering whether it makes sense to harden the protocol to
prevent this type of troubles.  I have a proposed revised text to
RFC2136 and would like to know if this could be accepted as an errata
item to the RFC.

In short, we could have avoided the bug if the protocol specification
clearly allows performing ACL checks before prerequisite processing.
And, in fact, I heard (off-list) from an author of the RFC2136 that
the original intent is to say "acl processing if any must be done no
later than this point" (instead of saying "must be done at this
point").  (this point = right after the prerequisite section
processing).

If that's what "the community meant" and can be considered a "bug" of
the original wording, I think we could simply submit an errata for
RFC2136, rather than waiting for an opportunity to update the
document. (see http://www.ietf.org/iesg/statement/errata-processing.html)

Specifically, I'd propose fixing Section 3.3.2 of RFC2136 as follows:

OLD:
   3.3.2. While the exact processing is implementation defined, if these
   verification activities are to be performed, this is the point in the
   server's processing where such performance should take place, since
   if a REFUSED condition is encountered after an update has been
   partially applied, it will be necessary to undo the partial update
   and restore the zone to its original state before answering the
   requestor.

NEW:
   3.3.2. While the exact processing is implementation defined, if
   these verification activities are to be performed, such performance
   must take place by this point in the server's processing.  This is
   because if a REFUSED condition is encountered after an update has
   been partially applied, it will be necessary to undo the partial
   update and restore the zone to its original state before answering
   the requestor.  Note also that the verification activities can
   happen before processing the zone or prerequisite section,
   depending on the local policy and implementation.

If I submit it to the errata page, I guess it will eventually be
passed to this wg for review.  So I'm asking this beforehand: does
this proposal make sense?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Bob Halley <[email-masked]>
Date: Sun, 8 Nov 2009 22:18:04 -0800

> this proposal make sense?

I've never understood why the standard requires prerequisite handling  
before permission checking.  I'm not sure we can get away with an  
"errata", however, as it seems like a substantive protocol change.  At  
least I'm not yet convinced it wouldn't break some client out there.

Requiring updating permission checking to be complete before update  
execution begins seems needlessly prescriptive.  If an implementation  
is not doing permission checking before prerequisite processing, then  
there is no visible-to-the-client difference between checking all  
update permissions before executing any update RRs and checking  
permissions for an update RR immediately before executing it.  If an  
implementation prefers to roll back partial updates vs never executing  
them in this case, I see no reason to forbid it.

/Bob

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Nov 2009 07:55:48 +0000

> point").  (this point = right after the prerequisite section

I think moving the ACL check around is covered by the as-if rule.  So
no standards action is required.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Nov 2009 17:01:30 +0900

At Mon, 09 Nov 2009 07:55:48 +0000,

> no standards action is required.

I don't know the as-if rule...could you explain what's the rule and be
more specific about which part of the RFC allows moving the ACL check
around according to that rule?

---
JINMEI, Tatuya

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Nov 2009 08:12:54 +0000

* JINMEI Tatuya / 神明達哉:

> I don't know the as-if rule...could you explain what's the rule

The as-if rule allows you to change implementation details any way you
see fit, as long as the observable behavior continues to match what
the standard requires.

> and be more specific about which part of the RFC allows moving the
> ACL check around according to that rule?

In this particular case, you could perform the ACL check first and
return NOTAUTH (which does *not* mean "not authorized", unfortunately)
or FORMERR because that's a result specified in section 3.1.2.  Or you
could rely on section 4.1.1 of RFC 1035 (which does not seem to be
overridden by RFC 2136) and return REFUSED.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Nov 2009 17:16:06 +0900

At Sun, 8 Nov 2009 22:18:04 -0800,

> least I'm not yet convinced it wouldn't break some client out there.

Good point, and that's actually what I thought would be an argument
against the errata approach.

I personally believe it's justified: if an update request is to be
rejected due to an ACL anyway, the visible-to-the-client behavior
differs only in the error code.  If the request passes the
zone/prerequisite checks, the behavior should be the same, REFUSED;
If the request also fails either a zone or prerequisite check, the
response will still be a failure with NOTAUTH/NXDOMAIN/NXRRSET, etc
(in the original RFC2136 logic) or REFUSED (in the revised proposed
logic).  And, since a server implementation might reject any request
for some non DDNS related reason (e.g., a server may reject any
request from a give source IP address even without checking the type
of the request), a reasonably behaving client would have to expect a
REFUSED anyway.

Of course, if the client assumes a specific behavior of a particular
implementation that never returns REFUSED before DDNS prerequisite
check, the proposed change would break the client.  But I personally
think we can dismiss such clients by "common sense and good judgment"
(per http://www.ietf.org/iesg/statement/errata-processing.html).
Others may have different opinions on this point, though, and that's
one reason why I asked the question here before simply submitting an
errata proposal.

> them in this case, I see no reason to forbid it.

I think I agree, but IMO this is actually beyond the scope of errata.
To me, the position of the ACL check is a bug of the original
specification; allowing roll-back due to a delayed ACL check is a
possible extended clarification suitable for an update to the base
spec.

---
JINMEI, Tatuya

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 9 Nov 2009 10:17:55 +0200

Florian Weimer wrote:
> I think moving the ACL check around is covered by the as-if rule. 

It's not, because it will result in different observable behavior: a
different RCODE will be returned in the case where the update request
meets neither the prerequisites nor the security policy.
-- 
Andreas Gustafsson, [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Nov 2009 17:17:59 +0900

On Mon, Nov 09, 2009 at 05:01:30PM +0900,
 JINMEI Tatuya / ???? <[email-masked]> wrote 
 a message of 21 lines which said:

> I don't know the as-if rule...could you explain what's the rule and
> be more specific about which part of the RFC allows moving the ACL
> check around according to that rule?

I believe that Florian refers to the general IETF rule that an
implementation is allowed to do what it wants internally as long as,
externally, it behaves AS IF it followed the description of the RFC.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Nov 2009 09:01:11 +0000

> meets neither the prerequisites nor the security policy.

Section 4.1.1 of RFC 1035 is not good enough to allow answering with
REFUSED for policy reasons?  I think that's surprising.

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 9 Nov 2009 11:48:45 +0200

> REFUSED for policy reasons?  I think that's surprising.

A server can certainly answer REFUSED at any time, but then it is not
implementing RFC2136 "as if", it is implementing a policy of refusing
to do RFC2136.

The behavior specified in RFC2136 has never made sense to me and I'm all
in favor of changing it, but I still think that's a protocol change.
-- 
Andreas Gustafsson, [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 09 Nov 2009 06:16:16 -0500

>in favor of changing it, but I still think that's a protocol change.

RFC2136-bis is needed.
Editors volunteers welcome,
the scope of the work is to get an RFC that can be pushed up the 
standards track.
I can dig out the interoperabilty tests we did some 10 years ago and 
were supposed
to lead to the bis document.

         Olafur

---

From: Bob Halley <[email-masked]>
Date: Mon, 9 Nov 2009 04:12:08 -0800

> possible extended clarification suitable for an update to the base

The current standard says you "should" do all of the checking before  
executing updates, lest you do extra work rolling back.  Your proposed  
text said "if these verification activities are to be performed, such  
performance must take place by this point in the server's processing",  
and it was the conversion of "should" into "must" that I was objecting  
to.

/Bob

---

From: Chris Thompson <[email-masked]>
Date: 09 Nov 2009 14:21:18 +0000

>clearly allows performing ACL checks before prerequisite processing.

I assume "avoided" mean "restricted it to attackers who could pass the
ACL checks"? Which would, of course, have made it a lot less serious.

>point").  (this point = right after the prerequisite section

I am guessing that you mean Paul Vixie, as he has in the past said on
the bind-users mailing list that it was all a mistake, e.g.

https://lists.isc.org/pipermail/bind-users/2007-July/066869.html

Are ISC actually planning to change BIND's slavish adherence to
the letter of RFC2136 anyway? I see in the changes file for 9.7.0b2:

2737.   [func]          UPDATE requests can leak existance information.
                        [RT #17261]

(and for those not familiar with BIND's RT numbers, that's far from a
being a new one!)

I should say that I would be in favour of such a change, and if it
needs a published erratum to RFC2136, or an RFC2136-bis, to make
it happen, I would be in favour of *that* as well :-)

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Nov 2009 11:38:50 -0500

> it happen, I would be in favour of *that* as well :-)

Are you so much in favour that you hereby volunteer to review or work
on such a document?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Nov 2009 16:43:17 +0000

> Date: Mon, 9 Nov 2009 10:17:55 +0200
> From: Andreas Gustafsson <[email-masked]>
> 
> Florian Weimer wrote:

i agree with both of you :-).

some members the DNSIND WG (precursor to DNSEXT, but also using the
namedroppers@ M/L) wanted clients to know whether an update would not have
succeeded anyway, due to prerequisite failures, even if an update would not
have been accepted (due to permission failures).  i held the opposite view,
which is that this was an information leak.  i fully intended to write "at
or before this point" rather than "at this point".  now that the internet
is even larger and even more commercial than it was when 2136 was written,
my error has been spotlighted.  we have seen DoS and we do have the
expected information leak.

irrespective of the fact that some clients may be depending on using a
preresquisite check in an UPDATE even though they would lack permission to
apply an UPDATE, i believe that the current definition is overly
prescriptive and that implementors ought to be free to put the permission
check earlier.  clients who break because of this are in my opinion
displaying bad manners.  zone operators ought to be free to refuse on
permission grounds without first refusing on prerequisite grounds.

i realize that this is an observable on-the-wire protocol change.  however
it's also a change to what the editor of the underlying draft intended.  i
do not know whether that qualifies it as errata but i hope so.

---

From: Chris Thompson <[email-masked]>
Date: 09 Nov 2009 16:57:41 +0000

>Are you so much in favour that you hereby volunteer to review or work

I will undertake to review (but not to write) an RFC2136-bis Internet
Draft if it decided that is the way to go. 

I am unclear on what is required in the way of review for an erratum,
in the alternative.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Nov 2009 12:01:01 -0500

> I am unclear on what is required in the way of review for an erratum,

Because this is an observable change on the wire, Olafur has already
suggested we need a bis.  I have to agree, alas.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Nov 2009 17:10:35 +0000

> Date: Mon, 9 Nov 2009 12:01:01 -0500
> From: Andrew Sullivan <[email-masked]>
> 

because i'm an nroff guy living in an xml world, i won't volunteer to
reformat rfc2136 into rfc2625 format.  happy to send the nroff source
code to anybody who is willing to do that, but note, jon (who was at
the time rfc editor) extensively reformatted it, so my source is out
of date with respect to the published RFC2136.  it may be better to do
an import of the text itself.

if not for the formatting problems i would undertake 2136-bis.  it was
a nice piece of work but i can think of myriad small ways the language
can be improved.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 10 Nov 2009 07:29:12 +1100

> a nice piece of work but i can think of myriad small ways the language

rfc2625 format. But RFC2625 is  "IP and ARP over Fibre Channel"

IF you mean that you'll do this if someone hand formats rfc2136 into  
XML RFC2629 format
then you are on Paul - I'll send you the equivalent XML shortly!

    Geoff

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Nov 2009 20:30:16 +0000

> IF you mean that you'll do this if someone hand formats rfc2136 into XML
> RFC2629 format then you are on Paul - I'll send you the equivalent XML
> shortly!

oops.  yes.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 09 Nov 2009 18:21:57 -0500

FWIW, I have a copy of the nroff file that the rfc-editor used to generate
RFC2136.

         Olafur

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 11 Nov 2009 00:15:14 +0900

At Mon, 9 Nov 2009 04:12:08 -0800,

> and it was the conversion of "should" into "must" that I was objecting  

Ah, I see.  I didn't intend to make this point stronger in the
proposed text; it's just a wording error.  All I wanted to make is to
clearly state we can perform permission checks before prerequisite or
zone section processing.  So the revised proposed text would be:

NEW:
   should take place by this point in the server's processing.  This is
(the only change is must->should in the third line)

...although I'm afraid such a wording tweak has become a minor issue
now that a simple errata approach doesn't seem to be accepted.

---
JINMEI, Tatuya

---

From: Geoff Huston <[email-masked]>
Date: Wed, 11 Nov 2009 07:43:12 +1100

>> RFC2629 format then you are on Paul - I'll send you the equivalent  

rfc2136.xml is at http://www.potaroo.net/xml/rfc2136.xml

(Its as close as I can get it - the RFC formats have changes slightly,  
nd XML can't replicate the untitled 3rd level sections as distinct  
sections, but most of it translated into XML cleanly)

over to you..

:-)

Geoff