Subject: wildcard optimization and b/w incompatibility

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Nov 2002 21:11:49 -0500

I'm not sure, but I think this paragraph is wrong:

#   The fact that resolvers that obtain an answer with a NXT RR's NOWILD
#   set to 1 do not receive additional proof for the non-existence of
#   wildcards is incompatible with RFC2535.

This is at the end of section 2.2, "resolver side" processing discussion.

After hearing Olaf's presentation I was thinking about whether or not 
this proposal indeed lacks backwards compatibility.

For "old" = not optimizing and "new" = optimizing,  we need to look 
at four cases.

1) New signer, old server.
2) New resolver, old server.
3) Old signer, new server.
4) Old resolver, new server.

1 - a problem only if the server checks the NXT type bit map on load, 
axfr, ixfr, or dynamic update.

2 - not a problem, the resolver will "fall back" to having to handle 
the whole proof.

3 - no a problem, the server will always have to provide the full response.

4 - this is a two step problem.  Old resolvers don't look for the 
wildcard NXT anyway, as we didn't notice the omission until the 
August workshop.  If there is an old resolver that did anticipate 
this, a problem would arise only if the resolver was "lazy" in my 
words.  By this I mean - if a resolver is "missing" some expected 
data, it should go ask for it, not be lazy and give up.

Question to the implementers - are there implementation-level 
problems with the first and last case?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Brian Wellington <[email-masked]>
Date: Tue, 19 Nov 2002 23:12:50 -0800 (PST)

> data, it should go ask for it, not be lazy and give up.

Maybe you didn't notice the omission, but it's been known for years.  The 
lack of wildcard DNSSEC support has been documented in the BIND 9 README 
file since the file was written, well before 9.0.0 was released.

> problems with the first and last case?

The first case is irrelevant, as no servers do that.

The last case will affect servers that support wildcard proof, of which 
there is at least one.  No dnssec capable server that I'm aware of 
will look for missing NXT records, as this would be extremely 
complicated and would likely lead to deadlocks.

There is a backwards compatibility issue.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 09:41:46 -0500

>complicated and would likely lead to deadlocks.

By "no dnssec capable server" do you mean "no dnssec capable resolver 
in use by a server?"  The confusion is:

1) Are you talking about the problem of finding all NXT records 
needed to accomplish a validation of authenticated denial of 
existence?

2) Are you talking about the problem of locating all necessary NXT 
records when assembling a reply?

I'm assuming that you mean #1 - the "last case" was an old resolver 
and a new server.

If so - could you expand on your rationale.  "Extremely complicated" 
leaves me with not enough data to know if this is because of an 
implementation decision or a protocol definition.  Also, a phrase 
such as "likely lead" is just as hard to evaluate.

The reason I ask is that when I once wrote a non-threaded, dedicated 
resolver, discovering that some piece of data is missing and needed 
to be retrieved wasn't all that hard.  Given that BIND 9 is a much 
more complicated code base, perhaps there is some deadlock potential 
(especially if data keeps timing out before you can evaluate the 
signatures), but I'd like a deeper description.

(else - let me know if it's #2 you mean)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Brian Wellington <[email-masked]>
Date: Wed, 20 Nov 2002 18:43:32 -0800 (PST)

> in use by a server?"  The confusion is:

Yes.

> needed to accomplish a validation of authenticated denial of 

Yes.

> records when assembling a reply?

No.  For a non-SERVFAIL reply to be sent, all of the NXT records must 
already be present, since they were needed for validation.

> such as "likely lead" is just as hard to evaluate.

Writing such an implementation would be extremely difficult and not worth
it, since any compliant authoritative server should return all needed NXTs
anyway.

Yes, 'likely lead' is hard to evaluate.  Having written multiple DNSSEC 
validating resolvers, there are many things which lead to deadlock.  
Without implementing this, I can't tell you for sure, but based on prior 
experience, I think there's a very good chance that it would.  I'm not 
going to implement this just to find out.

> signatures), but I'd like a deeper description.

I'm not talking about BIND 9.  I"m talking about servers in general.  Yes, 
going out to get a missing piece of data sounds easy, but then when you 
try to validate it, you might be missing something else, or it might 
depend on the validation which is already in progress, or any of a number 
of other issues which lead to deadlock.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 22:10:21 -0500

>it, since any compliant authoritative server should return all needed NXTs

True, but, 1) "compliant" changes and 2) I know of current servers 
that don't return the wildcard NXT in NXDOMAIN answers now.  Yes, 
this is non-compliance, but there's always that discussion of 
'miscreant' elements to consider.

>going to implement this just to find out.

There are three possible responses to this.

1) Does anyone else want to try?  (As it's Brian's right to refuse a try.)
2) Can someone prove this analytically?
3) Should we drop this discussion and 'assume' backwards compatibility?

>I'm not talking about BIND 9.  I"m talking about servers in general.

I used "BIND 9" in the sense that it's code that is much more 
complicated than what I wrote, so my experience may not be applicable 
here.

---

From: Brian Wellington <[email-masked]>
Date: Thu, 21 Nov 2002 11:39:47 -0800 (PST)

> 'miscreant' elements to consider.

Yes, but at some point you need to just say that if you're getting bad 
responses to your queries, you're going to fail.

> 3) Should we drop this discussion and 'assume' backwards compatibility?

I'd vote for (3).

> complicated than what I wrote, so my experience may not be applicable 

Right.  The latest validator I've written is far simpler than BIND 9 also, 
and I still think this behavior could be problematic.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Nov 2002 15:51:29 -0500

>>  3) Should we drop this discussion and 'assume' backwards compatibility?

I meant 'incompatibility' (a typo) - does that change your vote?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2002 20:51:19 +0000

regarding backward compatibility, let's talk about RR type codes for
SIG, NXT, KEY, etc

the deployed base of 2535 is insignificant, and no effort has been made
to try to "remain true" to the protocol as described in any earlier dnssec
specification.  therefore in each incompatible revision of dnssec, we ought
to deprecate the old type codes for dnssec-specific RRs.  this will cause
"interrim" implementations to believe that "there is no security data" and
fall back to normal, pre-dnssec operation.

naturally this also presents an unfortunate opportunity to change the rdata
format with each revision, but i hope that we can manage not to take it.

it also means that the mneumonics will change with each revision, so we may
end up with things like SIG2/KEY2/DS2 or even SIG3950/NXT3950/DS3950 if there
were a dnssec revision defined in RFC3950.

however, this is the only way to be sure of "b/w compatibility" with interrim
dnssec implementations -- and that is, to invalidate them entirely and force
them into their pre-dnssec mode.

---

From: "Matt Larson" <[email-masked]>
Date: Thu, 21 Nov 2002 16:19:39 -0500

Paul Vixie wrote:
> it also means that the mneumonics will change with each revision, so
> we may end up with things like SIG2/KEY2/DS2 or even
> SIG3950/NXT3950/DS3950 if there were a dnssec revision defined in
> RFC3950. 

Why do the mnemonics need to change if the type codes change?

Matt

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2002 21:25:14 +0000

> Why do the mnemonics need to change if the type codes change?

formally speaking, a type code and mneumonic are allocated as a tuple.

informally speaking, "dig" will never stop printing the old rrs if
it encounters them, even if they came from interrim dnssec implementations.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Nov 2002 16:38:23 -0500

Yes!

I once suggested that we just chuck the KEY RR instead of publishing 
the 'KEY RR restrict' document.  But I can't find any record that I 
sent this to a public list.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Nov 2002 16:39:41 -0500

>Why do the mnemonics need to change if the type codes change?

So the documents are also obviously obsoleted.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 21 Nov 2002 21:37:48 -0500

To quote the "A-Team":  That's so crazy it just might work!

But I still have some doubts.  That will help identify the "true" security
aware servers/resolvers, but will it help the problem of a non-DS aware
cache between the resolver and authoritative server?  If a recursive
forwarder doesn't know where to ask for the DS record, it doesn't matter
what the type code is.

I don't know.  I need to think about it.  It does make some other unpleasent
problems go away.

Scott
PS (non US) The A-Team was a TV show in the 80's where a band of ex-military
misfits solve problems with wierd plans that always worked, no matter how
silly/crazy/outlandish.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 22 Nov 2002 04:21:26 +0100

The show hit Europe as well. We get the best of american culture:
A-team, McDonalds, etc :-).

Yes, I too have always wondered why people are so hang-up on
compatabilaty with 2535, a propossed standard, hardly been deployed
and according to the rules should not be deployed for disruption-sensitive
producting work. (RFC 2026, secton 4.1.1).

	jaap

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Nov 2002 22:52:00 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott Rose <[email-masked]> writes:
    Scott> But I still have some doubts.  That will help identify the "true" security
    Scott> aware servers/resolvers, but will it help the problem of a non-DS aware
    Scott> cache between the resolver and authoritative server?  If a recursive
    Scott> forwarder doesn't know where to ask for the DS record, it doesn't matter
    Scott> what the type code is.

  Bingo.

  Fundamentally, both DS and pre-DS KEY are broken because they are defined to live
in the parent zone. (SIG is even more bizarre...)

  As such, they need specific behaviour to make them work with caches that
are unaware of their special nature. 

  pre-DS KEY lived in both places, but like NS, the child is considered the 
authoritative respository for the record and the parent just has some
"hints". 

  We could have solved this by having the child pull the records out of the
parent zone, and then insisting that the parent has to maintain the old
KEY/SIG records for some long time.
  This could work, and with a lot more thought I think that we can make the 
KEY rollover work as well.

  However, I think that DS is probably a good seperation for zone cuts.
If we can simply make the child pull records from the parent again, then we
might find a resolution to this problem. The stub zone stuff that bind has
might be a good model - pull it down when you can and save it. 

  If you are offline and can not speak to the zone's parent during a key
rollover is a clear problem here.

  So, we either find a way to put the DS record CLEARLY in the parent, or
a way for the CHILD to get a copy of it.

  BTW: NS also lives in both places, BUT, we don't have failures if the
child and parent disagree. In fact, this is often a feature for some.

    Scott> Scott
    Scott> PS (non US) The A-Team was a TV show in the 80's where a band of ex-military
    Scott> misfits solve problems with wierd plans that always worked, no matter how
    Scott> silly/crazy/outlandish.

  _I love it when a plan comes together_
  I watch it more often than I'd like to admit... 6pm on DejaView.

]                   At IETF55 in Atlanta, GA                    |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Nov 2002 22:57:19 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jaap" == Jaap Akkerhuis <[email-masked]> writes:
    Jaap> Yes, I too have always wondered why people are so hang-up on
    Jaap> compatabilaty with 2535, a propossed standard, hardly been deployed
    Jaap> and according to the rules should not be deployed for disruption-sensitive
    Jaap> producting work. (RFC 2026, secton 4.1.1).

  My understanding is that we have a problem whenever there is a caching
resolver in the way that is not DS aware. It doesn't matter if it is 2535
aware or not.

  As I understand the problem, it is irrelevant whether or not it is 2535
aware, so long as it can deal with records that it doesn't understand. If it
fails to return SIG/NXT/KEY records because it doesn't understand them, then
there is no problem.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Nov 2002 04:12:41 +0000

> To quote the "A-Team":  That's so crazy it just might work!

i apologize for keeping the thought to myself for the last year, then.
(i keep wanting to stay out of dnssec's innards because security hurts
me to think about, but then dnssec keeps running aground on issues more
related to dns than security... i promise to speak up sooner next time.)

> cache between the resolver and authoritative server?

no, and it isn't expected to.  what we want to do is limit the cases to
"pre-dnssec" and "current-dnssec" and not "interim-dnssec-N" or even
"interim-dnssec-N+1".

> If a recursive forwarder doesn't know where to ask for the DS record,
> it doesn't matter what the type code is.

right.  but that problem is separately tractible.  later tonight i will write
in with "ENS", which while uglier than sin, may yet be prettier than namehack.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Nov 2002 04:50:47 +0000

> might be a good model - pull it down when you can and save it. 

it's not reasonable to ask an authoritative server to have to fetch anything
from anybody.  it should not need a root.cache file, it should never have to
ask a udp/53 question other than, perhaps, when a slave server asks a master
for its SOA to find out if "now" is a good time for an AXFR.

> a way for the CHILD to get a copy of it.

watch for the "ENS RR", coming soon to a namedroppers list near you.

> child and parent disagree. In fact, this is often a feature for some.

putting crap at the delegation point is hairy business.

---

From: Brian Wellington <[email-masked]>
Date: Fri, 22 Nov 2002 11:03:00 -0800 (PST)

> I meant 'incompatibility' (a typo) - does that change your vote?

Not really.  We've known all along that 2535 DNSSEC will not work when DS
is deployed, so I don't see why this is an issue at all.

Brian