headers
Andreas Gustafsson | 1 Mar 2003 01:06

Re: Poison in a zone

On the IETF list, Claus Färber wrote:
> I think the only requirement that's really essential is that the serial
> number changes whenever the data that would be returned by a zone
> transfer changes (even if that breaks database consistency for the SOA
> record's serial number).

It is also essential that two different authoritative servers that
show the same serial number actually serve the same data.

> One strategy to implement this would be to keep an exact copy of a zone
> obtained from other servers for outgoing transfers (so you'll always use
> the original serial number), which is the BIND 9 strategy.
> 
> Another strategy would be to just increment the serial number of a zone
> when it is actually changed by importing glue records from another zone.
> This would solve the synchronisation problem, too: If the parent zone is
> updated too early, the server might throw away the glue record. But it
> will update the parent zone and increase its the serial number when it
> gets an up-to-date copy of the child zone.

In principle, this approach could work on the primary master server
(at least assuming the zone serial number is being maintained by the
server rather than the administrator), but it won't work on a slave.

If a slave "imports" glue into a zone, it can't update the serial
number, and even if it could, that wouldn't make the zone contents
consistent with the master.

Followups to namedroppers, please.
--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rob Austein | 1 Mar 2003 01:28
Favicon

Re: Q-6: May security-aware resolvers cache "Bad" data?

At Fri, 28 Feb 2003 15:22:54 -0800 (PST), Brian Wellington wrote:
> 
> I'm not sure where negative caching fits into this.  The RRsets returned 
> as part of a valid negative response should all be verified; there's 
> nothing in the negative reponse which would be classified as anything 
> other than Authenticated.

You're thinking of conventional negative response caching, for which
you are of course correct.

The reference here was to kind of negative caching for which we don't
have a name yet, dealing with RRsets whose signatures are demonstrably
bad, so that the resolver can avoid performing the same (failing)
query and verification operations over and over again within a short
period of time.  RFC 2535 appears to forbid this form of negative
caching and doesn't discuss the (potentially serious) implications of
doing so, hence the question.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 4 comments |
headers
D. J. Bernstein | 1 Mar 2003 01:43
Picon

Re: Poison in a zone

Andreas Gustafsson writes:
> It is also essential that two different authoritative servers that
> show the same serial number actually serve the same data.

That's a wild exaggeration. For example, a pure slave can do anything it
wants with its serial numbers. In fact, unless one slave pulls the zone
from two different masters, serial-number coherency is irrelevant.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Permalink | Reply | 0 comments |
headers
Greg Hudson | 1 Mar 2003 03:23
Picon
Favicon

Re: Q-6: May security-aware resolvers cache "Bad" data?

On Fri, 2003-02-28 at 19:28, Rob Austein wrote:
> The reference here was to kind of negative caching for which we don't
> have a name yet, dealing with RRsets whose signatures are demonstrably
> bad, so that the resolver can avoid performing the same (failing)
> query and verification operations over and over again within a short
> period of time.  RFC 2535 appears to forbid this form of negative
> caching and doesn't discuss the (potentially serious) implications of
> doing so, hence the question.

Well, to the extent that the cache's behavior is visible to the querying
client, it's not an implementation detail.  It sounds like the text is
trying to prevent a security-aware caching server from providing bad
responses to a stub resolver, and that's important for people who want
to use security aware local caching recursive resolvers in concert with
old native stub resolvers.

If the caching resolver wants to cache the bad response (or a hash of
it) in order to avoid redoing expensive cryptography operations, that's
obviously an implementation detail and is fine.  Thunking is always okay
when timing attacks aren't an issue.

If the caching resolver wants to cache the fact that it got a bad
response last time so it doesn't have to bother again, that has a couple
of problems: we don't know how long to cache for (any information in the
bad response has to be discarded as potentially malicious, and there's
no SOA record there anyway), and it could make DOS attacks easier. 
There may be some scaling issues associated with doing no caching of
this sort, but I don't think they're the kind of issues that can be
solved during an editing pass.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Wellington | 1 Mar 2003 03:56

Re: Q-6: May security-aware resolvers cache "Bad" data?

On Fri, 28 Feb 2003, Rob Austein wrote:

> At Fri, 28 Feb 2003 15:22:54 -0800 (PST), Brian Wellington wrote:
> > 
> > I'm not sure where negative caching fits into this.  The RRsets returned 
> > as part of a valid negative response should all be verified; there's 
> > nothing in the negative reponse which would be classified as anything 
> > other than Authenticated.
> 
> You're thinking of conventional negative response caching, for which
> you are of course correct.
> 
> The reference here was to kind of negative caching for which we don't
> have a name yet, dealing with RRsets whose signatures are demonstrably
> bad, so that the resolver can avoid performing the same (failing)
> query and verification operations over and over again within a short
> period of time.  RFC 2535 appears to forbid this form of negative
> caching and doesn't discuss the (potentially serious) implications of
> doing so, hence the question.

If that's what you mean, I'd suggest not using the term "negative 
caching", which is well defined (the caching of a negative response, where 
negative means either the host or type doesn't exist).  I'd use a new 
term, like "failure caching".

While forbidding failure caching might be going a bit far, caching
failures is really not a good idea.  It means that if a server receives a
spoofed response, it will cache the data, and use the cached failure as an 
indication to not try again.  This leads to obvious DoS attacks.  Not 
caching failures has other problems (bandwidth amplification attacks), but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Austein | 1 Mar 2003 05:23
Favicon

Re: Q-6: May security-aware resolvers cache "Bad" data?

I'm not really trying to have a debate here, the point was to ask the
WG a question.  However, since Greg's comments suggest that the
context of the question may have been unclear, one clarification:

At 28 Feb 2003 21:23:30 -0500, Greg Hudson wrote:
> ...
> It sounds like the text is trying to prevent a security-aware
> caching server from providing bad responses to a stub resolver, and
> that's important for people who want to use security aware local
> caching recursive resolvers in concert with old native stub
> resolvers.

The text I'm asking about forbids the security-aware resolver itself
from caching "Bad" data, regardless of what it's going to do with that
data or whether it's ever going to send that data anywhere.

What data a security-aware recursive name server is allowed to send to
to a resolver is a separate matter, addressed elsewhere.  As far as I
know, nobody's suggesting that a security-aware recursive name server
should send "Bad" data a response except perhaps when responding to a
query with the CD bit turned on.  Different issue.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 0 comments |
headers
Randy Bush | 1 Mar 2003 12:00

list policy

namedroppers <at> ops.ietf.org is the mailing list for the ietf dnsext wg.  see
<http://www.ietf.org/html.charters/dnsext-charter.html> for the wg charter.
messages should be on topics appropriate to the dnsext wg, which are various
discussion of the dns protocols or administrivia of the wg itself.

calls for papers, announcements of events not directly relevant to the dns
protocols, etc. are not appropriate.  discussion of problems with particular
implementations, announcements of releases, sites' misconfigurations, etc.
should be done on mailing lists for the particular implementations.

posts are only accepted from subscribers.  with the massive amount of spam,
it is easy to miss and therefore delete posts by non-subscribers.  if you
wish to regularly post from an address that is not subscribed to this
mailing list, send a message to namedroppers-owner <at> ops.ietf.org and ask to
have your alternate address added to the list of addresses from which
submissions are automatically accepted.

there is a wg for dns operational practice, dnsop, whose charter can be
found at <http://www.ietf.org/html.charters/dnsop-charter.html>.

there is a mailing list for discussion of whose implementation is better,
and why someone else's is broken.  it is weenie-war <at> ops.ietf.org.  all
discussions of such nature should occur there or on /dev/null.  unlike the
namedroppers list, weenie-war <at> ops.ietf.org is not archived.

questions or concerns related to the acceptance or rejection of
specific messages to the namedroppers mailing list should first be
discussed with the wg chairs, with followup appeals using the normal
appeals process of rfc 2026 (i.e., follup with area directors, then
iesg, etc.).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ólafur Gudmundsson/DNSEXT co-chair | 2 Mar 2003 16:20

DNSEXT draft of revised charter

Send in comments before Randy and I send this one to the IESG.

DNSEXT DNS Extensions Working group
---------------------------------------------------

  Charter
  Last Modified: 28-February-2003

  Current Status: Active Working Group (being rechartered)

  Chair(s):
      Randy Bush <randy <at> psg.com>
      Olafur Gudmundsson <ogud <at> ogud.com>

  Internet Area Director(s):
      Thomas Narten  <narten <at> raleigh.ibm.com>
      Erik Nordmark <nordmark <at> eng.sun.com>

  Internet Area Advisor:
      Erik Nordmark <nordmark <at> eng.sun.com>

  Mailing Lists:
      General Discussion: namedroppers <at> ops.ietf.org
      To Subscribe:       namedroppers-request <at> ops.ietf.org
      Archive:		<http://ops.ietf.org/lists/namedroppers/>

Description of Working Group:

DNS is originally specified in RFC's 1034 and 1035, with subsequent
updates.  Within the scope of this WG are protocol issues, including
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roy Arends | 2 Mar 2003 17:37

Re: draft-weiler-dnsext-dnssec-2535-compat-00.txt

On Sun, 2 Mar 2003, Sam Weiler wrote:

> This document describes a solution to a backwards incompatibility
> problem between DS and resolvers that understand RFC2535.  The
> proposed solution of rolling the DNSSEC RR type codes has been
> implemented and received some testing at the opt-in workshop at RIPE
> in January (see Olaf's message of 5 Feburary and the ensuing
> discussion).  The same problem may be triggered when legacy resolvers
> see proofs of delegations being in insecure spans using opt-in,
> but this has not been tested.
>
> This problem was diagnosed by Jakob Schlyter and Mark Andrews earlier
> this year, though it probably caused some of the misbehavior seen on
> testbeds and in workshops last year.

Sam,

Proposing new DNSSEC RR type codes implies upgrading resolvers,
which seems to be exactly what you wanted to avoid.

Roy

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 2 comments |
headers
Sam Weiler | 3 Mar 2003 05:35

Re: draft-weiler-dnsext-dnssec-2535-compat-00.txt

On Sun, 2 Mar 2003, Roy Arends wrote:
>
> Proposing new DNSSEC RR type codes implies upgrading resolvers,
> which seems to be exactly what you wanted to avoid.

DS already forces resolvers to upgrade if they want DNSSEC validation.

I'm trying to make sure that resolvers that don't understand DS at
least get (and don't discard) insecure answers.  The problem described
causes legacy resolvers to discard good data from signed zones.  If
that were likely to happen, some zones (cnn.com. being my favorite
example) would REALLY not want their parent to be signed.  I don't
want to see the CNN's of the world lobbying to keep .com from being
signed.

-- Sam

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 1 comment |

Gmane