Subject: Summary: What to do with expired signatures

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 11 Feb 2002 14:03:51 -0500

After reading all the messages posted, it is clear that the answer
to the original question is applicable to nameserver behavior in
general.

Is it accurate to summarize the working group consensus as follows:

Authorative servers: MUST accurately reflect the zone information
supplied. No changes to the contents of the zone file contents are
allowed, even if the server can detect errors in some records.
Authorative servers SHOULD log any errors they detect in zone files.

Caching servers: SHOULD keep all information supplied by
authoritative servers unless provably not correct or
irrelevant to the original query.

Resolvers should ONLY use data that is relevant and temporarily
correct, in addition the answer used MUST meet the local security
requirements.

	Ólafur

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: Peter Koch <[email-masked]>
Date: Mon, 11 Feb 2002 20:41:25 +0100

> Authorative servers SHOULD log any errors they detect in zone files.

+ "Servers MAY refuse to serve zones with errors entirely"?

> Caching servers: SHOULD keep all information supplied by
s/servers/resolvers/;

> irrelevant to the original query.

This leaves undefined the bahavior w.r.t. non-auth answers received from
other caching resolvers. Both should be treated equal. "provably incorrect"
should be restricted to proof by DNSSEC or first hand DNS knowledge (like
a copy of the zone in a mixed server/resolver environment).
It's important to keep RRSets intact.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 11 Feb 2002 14:48:02 -0500

Some comments.

>Is it accurate to summarize the working group consensus as follows:

Do you mean: "Is it ... ?" or "It is ... :"

>irrelevant to the original query.

"Not correct" for the time being or ever again?

And as far as "unless provably not correct or irrelevant to the original
query," this should be removed.  Caching servers should not try to
interpret the data they are "transiting"/as in caching.  (Irrelevant - too
loose because it could be twisted to mean that A records for unreachable
addresses to the user would be culled from the set.  This isn't what is
desired.)

>correct, in addition the answer used MUST meet the local security

s/should/SHOULD/

s/use/return/

s/relevant/relevant to the query/

s/temporarily/temporally/

s/correct/valid/

Why "MUST meet the local security requirements?"  Isn't that up to the
application?  (Remember that resolvers are the general users of the data,
applications are.) Whose/which policy?

What about the observation that caching servers use resolvers to admit data
to the cache?  Do these servers follow the rule for caching servers or
resolvers?  This is an instantiation of the check-on-receive vs.
check-on-send issue.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

Opinions expressed are property of my evil twin, not my employer.

---

From: Rob Austein <[email-masked]>
Date: Mon, 11 Feb 2002 15:55:23 -0500

> resolvers?  This is an instantiation of the check-on-receive vs.

"caching server" == an entity that supports both the "resolver role"
(including the optional cache) and the "name server role".

An entity acting in the resolver role isn't -required- to cache
anything.  There are some rules it has to follow if it does cache
stuff, eg, it must not cache partial RRsets or merge RRsets.

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 11 Feb 2002 15:50:32 -0500

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: "Ólafur Guðmundsson" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 11, 2002 2:48 PM
Subject: Re: Summary: What to do with expired signatures

> Do you mean: "Is it ... ?" or "It is ... :"

I take this as "It is..."

> "Not correct" for the time being or ever again?

I think it should be "ever again" - however, there is the problem of SIGs
with inception times in the future.  What if a SIG has an inception time 1
day in the future, but the TTL for the SIG and RRSet it covers is only 1
hour?  it would be purged from the cache before the signature could be
considered valid.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Mon, 11 Feb 2002 16:13:54 -0500

>(including the optional cache) and the "name server role".

Granted, my comment was meant to be more rhetorical, Olafur's message
talked about the caching server as separate from the resolver.

>stuff, eg, it must not cache partial RRsets or merge RRsets.

Since the earlier comment about middlebox, I was beginning to wonder about
the rules in 2181.  This helps put 2181 in perspective, it makes the the
servers "in the middle" do the right thing as opposed to applying
judgements.

The point that I was troubled over was whether "credibility" was a
judgement.  It is, but the judgement is based on objective protocol data
(section, whether the answer is reported to be authoritative) and not a
policy (as most DNSSEC decisions are).

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2002 18:18:23 -0500

> hour?  it would be purged from the cache before the signature could be

Yea?  So?  What's the problem with that?

> Scott

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Brian Wellington <[email-masked]>
Date: Mon, 11 Feb 2002 20:22:31 -0800 (PST)

> Authorative servers SHOULD log any errors they detect in zone files.

Is it the feeling of the working group that expired signatures are
considered an error?

Brian

---

From: [email-masked]
Date: Tue, 12 Feb 2002 15:54:40 +1100

> Is it the feeling of the working group that expired signatures are

	They are not errors.  Just interesting data.  If it was a
	error the zone should not be served at all.

	Mark

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 12 Feb 2002 15:46:31 +0700

Date:        Mon, 11 Feb 2002 14:03:51 -0500
    From:        Ólafur  Guðmundsson <[email-masked]>
    Message-ID:  <5.1.0.14.2.20020211133821.03129210@localhost>

  | Authorative servers: MUST accurately reflect the zone information
  | supplied. No changes to the contents of the zone file contents are
  | allowed, even if the server can detect errors in some records.
  | Authorative servers SHOULD log any errors they detect in zone files.

Looks OK to me.

  | Caching servers: SHOULD keep all information supplied by
  | authoritative servers unless provably not correct or
  | irrelevant to the original query.

Caches (to side step the question of whether a cache is a server or a
resolver...) keep whatever they like, for as long as they like, within
the TTL bounds.  They don't have to cache anything.   So SHOULD is too strong.
Of course a cache that caches nothing wouldn't be a very useful product, but
it still compiles...   What is relevant to the question here is that caches
should not be making value judgements on the data (based upon what they see
as worth keeping, and what is not).

The 2181 rules that someone mentioned relate to what happens when the cache
(or a resolver even, though without a cache it is very unlikely) has 
conflicting data, wants to keep some, and has to decide which to retain.

  | Resolvers should ONLY use data that is relevant and temporarily
  | correct, in addition the answer used MUST meet the local security
  | requirements.

Resolvers just fetch data from the servers and return it to the application.
It is beyond our scope to decide what data the application uses, or why.
It is also beyond our scope to lay down boundaries between what is implemented
as part of a set of functions an implementor calls "the resolver" and the
rest of the application - if "the resolver" wants to do SIG verification in
some implementation, that's fine, if another wants to simply pass SIGs back
to he application for it to verify, that is also fine.

kre

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 12 Feb 2002 08:16:58 -0500

Not a "major" problem, but not a wise thing to do if an admin wants their
DNS data to be accepted by other servers.  If there is at least one SIG in a
set that is valid (cryptographically and temoraly) then no problem.

SIGs that are not valid can easily be dropped, since it makes no sense
storing them.  It's an implementation detail.

Still fighting the urge to save clueless admins from themselves I guess.  :)
Scott

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Feb 2002 09:19:33 -0500

>storing them.  It's an implementation detail.

I think the issue is a bit more significant than an implementation detail.
Personally, this thread has convinced me that the servers should not edit
zones in any way.  Putting in "shortcuts" for "efficiency" is how
complexity creeps into the design and becomes threatens scaleability
(depending on how scaleability is defined).  By scaleability I mean: a
growth in the number of servers, a growth in the interaction of servers.
I'm excluding growth in the size of messages - an obvious consequence of
servers editing (downward in size) the responses.

Dynamic delete is an exception.  It is an acceptable exception in that
dynamic update is sufficiently independent of the action of
publishing/distributing data.  It is a complication of the zone loading
process, not the zone serving process.

Is a signature that has passed its expiration date a protocol error?  No,
its a data error, like a bad A record.  Is a missing SOA record a protocol
error.  Yes.  My point is that servers should (according to specifications)
stick to reporting protocol errors and not data errors.  An implementation
is free to add other reporting, the freedom is determined by the
implementation's users, but this should not enter the specification process.

I understand the desire to make things easier for the administrators.  I
don't think this desire belongs in the protocol specifications but perhaps
in implementation guidance, perhaps BCP's.

OTOH - to an administrator, multiple tools means complexity, a single tool
is simpler (even if the guts of it are complex).  There is a tradeoff of
simplicity to the protocol and simplicity to the user.  Hmmmm.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2002 06:40:29 -0800

> zones in any way.

I was astounded that anyone here even thought that that was debatable.

> process, not the zone serving process.

The zone whatting process?  I have here a server with persistent zone storate.
All zone changes are made by RFC2136 "UPDATE" requests.  There is no "load"
and there is no "zone file" and there is no way to map your "implied delete"
to any process that it has.  Yet this server is entirely protocol compliant.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Feb 2002 10:06:22 -0500

>I was astounded that anyone here even thought that that was debatable.

I'm confused by this response.

Are you saying that this issue "is" just an implementation detail?  Or are
you saying that "servers should not edit zones" is undebateable?

>to any process that it has.  Yet this server is entirely protocol compliant.

This is entirely philosophical:  Dynamic update accomplishes the same thing
as sending a change request to the appropriate person, editing the zone
file and reloading the zone.  The serial number is updated, and the if the
zone is signed, new signatures are produced as needed.  Dynamic update does
this much more quickly than the "old" way.  That's why I said that dynamic
update is related to zone loading.  As far as being a "complication,"
dynamic update is a new process - meaning that there are now more ways to
get data into a zone.

The fact that this is protocol compliant isn't a debate.  I was just trying
to decide if dynamic update was a symptom of middleboxness or not.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2002 07:40:59 -0800

> ... Or are you saying that "servers should not edit zones" is undebateable?

Yes.

> ... That's why I said that dynamic update is related to zone loading.
> As far as being a "complication," dynamic update is a new process -
> meaning that there are now more ways to get data into a zone.

Some folks here have suggested, both in this thread and in threads past,
that a zone server ought to be free to elide some nodes or RRs during its
"loading" process, and still serve the resulting (implicitly) edited data.

I'm now coming to the conclusion that "zone loading" should be deposited in
the same dustbin as "zone file format."  I was shocked to see $TTL codified
since there were, even at that time, totally compliant (on the wire) DNS
implementations which had no concept of a "zone file" or "loading."  The
standard ought to talk about what's on the wire and what to do with stuff
you got off the wire and what to put on the wire (and when and why), not
implementation details like "zone file format" or "zone loading."

If we re-turn RFC 1034/5 I will strongly recommend that all descriptions
of "zone file format" be given BCP status.  A correct and complete DNS
implementation ought not have to deal with these historical card images
unless its implementor wants to offer a backward-compatibility crutch.

---

From: Rob Austein <[email-masked]>
Date: Tue, 12 Feb 2002 11:02:38 -0500

I don't see dynamic update as a middlebox thing.  As Ed suggests,
conceptually it's equivalent to updating a zone file followed by
loading that zone file; the fact that a clever implementation might be
able to optimize this so completely that the zone file per se doesn't
exist anymore doesn't really change the model.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Feb 2002 11:06:17 -0500

At 10:40 AM -0500 2/12/02, Paul Vixie wrote:
>the same dustbin as "zone file format." ...
>... The

You are right.  I perceive that there has been a tendency for discussions
and documents to stray from the mission of specifying protocols and from
the goal of interoperability.  Given that there is but one testbable
implementation of RFC 2535, it has become easy to confuse that
implementation with the protocol.

---

From: Jim Reid <[email-masked]>
Date: Tue, 12 Feb 2002 08:20:10 -0800

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    Edward> Given that there is but one testbable
    Edward> implementation of RFC 2535, it has become easy to confuse
    Edward> that implementation with the protocol.

Doesn't Olaf's Perl version of 2535 qualify as a second implementation?
IIRC it found a bug in the BIND footprint calculation.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Feb 2002 11:28:41 -0500

I'd have to ask Olaf.  If it is, I should put it into use.

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Feb 2002 16:01:05 -0500

> I was astounded that anyone here even thought that that was debatable.

i believe that http://ops.ietf.org/lists/namedroppers/2001/... has a long
and interesting discussion of the subject based on a difference between two
prominent implementations.

> All zone changes are made by RFC2136 "UPDATE" requests.  There is no
> "load" and there is no "zone file" and there is no way to map your
> "implied delete" to any process that it has.  Yet this server is entirely
> protocol compliant.

as the docs do specify a zone file and format, this is interesting.

randy

---

From: Danny Mayer <[email-masked]>
Date: Tue, 12 Feb 2002 20:56:19 -0500

>         error the zone should not be served at all.

Not only that, a signature could expire while it's loaded. It may have been
perfectly valid during the load of the zone.

         Danny

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 13 Feb 2002 09:32:43 +0100

On Tue, 12 Feb 2002 08:20:10 -0800

> IIRC it found a bug in the BIND footprint calculation.

FYI:

I have added the SIG, KEY, NXT and DS classes to Net::DNS that means
you can read these records from a zone file and 'translate' them into
wireformat and vice verse. Off course wire-wire is also possible :-).

The SIG class has methods to create RSA and DSA signatures using keys
generated by the bind tools but does not use the openssl
libraries. The SIG class also can verify signatures, made by bind
signer's and itself.

The DS class has a create method that creates a DS RR from a given
key.

The (original) Net::DNS packet had resolver functionality and there is
some server functionality in the 0.19 alpha version. 

I am working on a Zone object that can be used as to build a server in
perl but that is still pre-alpha. (If you are interested in playing
with it please contact me). 

As for the verifying resolver: all the classes to build such a thing
are there but it does need to be done. As soon as there is a server
that does DS-style serving and/or I have some time I will to make
a verifying resolver using the perl tools.

--Olaf

"Original" Net::DNS on http://www.fuhr.org/~mfuhr/perldns/  

DNSSEC extensions are build against the 0.19 development version of
Net::DNS and can be found on: 
http://www.ripe.net/disi/SRC/Net-DNS-0.19-DNSSEC-0.5.tar.gz

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Paul Vixie <[email-masked]>
Date: 13 Feb 2002 08:54:20 -0800

> as the docs do specify a zone file and format, this is interesting.

Yes.  Since at no time in any interoperability workshop has it ever happened
that one implementor handed the other a *.TXT file and said "read this and
serve it so we can test interoperability", I can legitimately claim that a
server which does not parse "zone file format" and does not have a concept
of "loading" a zone is completely protocol compliant.  On the wire, you just
can't tell how the other guy deals with backend storage of zone data.  And
if an implementation can pass every possible on-the-wire compliance and
interoperability test you can devise, then they are fully compliant with the
protocol.

This supports my earlier statement that zone file format should be a BCP
rather than a PS.  You can't have a PS that is by its nature untestable,
according to my reading of the IETF charter documents.

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 13 Feb 2002 17:37:21 -0500

Paul Vixie wrote:
> of "loading" a zone is completely protocol compliant.

Well... This is *exactly* what happened at the 46th IETF (DC) interoperability
event, and perhaps at prior events as well.  The results are posted here:
<http://www.isc.org/interop/>.  Note the reference to the Perl config file
generator and the Perl master file generator.

Still, I agree completely that a protocol compliant server can exist which does
not parse zone files (we make one here at Cisco).  However, having a user
interface which does parse zone files can make life a lot easier, as it did for
me in this particular case.  I think BCP status for zone file format might make
sense.  I certainly don't see it as part of the protocol, but as an aspect of a
useful user interface.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Feb 2002 16:32:19 -0800

you are discussing a small element of what you would like a theoretical
revised dns spec to be.  i am discussing what the standard is.

randy

---

From: Paul Vixie <[email-masked]>
Date: 14 Feb 2002 15:22:27 -0800

> revised dns spec to be.  i am discussing what the standard is.

since you're telling me what i'm discussing, i'll do the same.

you are not discussing a standard, you are discussing a document.
rfc1034/5 were written well before the ietf's current standards
process existed.  (a good thing, too, or else we'd still be arguing
about dns rather than using and extending it.)  the documents of
this area were just documents.  they had no status like PS or DS
or FS or BCP or FYI.  they were just, as i said, documents.  you
can go on explaining what the documents of this era say, and i will
go on listening to you, but you are not describing a "standard" by
today's standards.  anything that rfc1034/5 say which do not meet
the definition of "interoperable standard" is actually just extra
words in the document, which don't make or change any "standard".

zone file format is an example of this kind of "extra words".

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Feb 2002 16:08:52 -0800

1034 Domain names - concepts and facilities. P.V. Mockapetris.
     Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882,
     RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982,
     RFC2065, RFC2181, RFC2308, RFC2535) (Also STD0013) (Status: STANDARD)

1035 Domain names - implementation and specification. P.V.
     Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes
     RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348,
     RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181,
     RFC2137, RFC2308, RFC2535, RFC2845) (Also STD0013) (Status: STANDARD)