Subject: DNSSEC protocol: attempting to retrieve SIGs

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 17 Apr 2003 14:41:13 +0200

dnssec protocol draft.

A somewhat detailed nit.

Section 4, page 21 first but last paragraph:

  a security aware resolver MUST attempt to retrieve missing DS, KEY,
  or SIG RRs.

Seems to be inconsistent with section 3 that says that:

  SIG RRs which can be used to authenticate the data MUST be included.
  (more detailed in the subsections)

Based on the "MUST" in section 3 I would say if the SIG is not
included in a response packet (while it is being expected) a
implementation can just drop it and concern it bad.

Section 4 could read:
  a security aware resolver MUST attempt to retrieve missing DS and KEYs,
(drop the SIGs from that).

On the other hand it could be that one of the set of authoritative
servers does not properly do the dnssec processing (is buggy or not
DNSSEC aware). In that case such server should be marked as lame and
the query (not for the SIG but the original query, I'd say) should be
done against another server. If that is the expected behavior I think
some explanatory text is needed.

--Olaf

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

--
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: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 09:39:36 -0400

The reason for the differences is that there are non-security aware 
protocol elements out there.  In the old days we had hoped to be able 
to retrieve DNSSEC data through older DNS implementations (e.g., 
caching servers performing proxy DNS service on statefull firewalls).

Perhaps this is quixotic, as we eventually ran into trouble trying to 
implement responses to queries for QTYPE=SIG, and we've seen even 
uglier interactions (with legacy code bases) when looking at the 
"grandparent problem" during discussions of the DS RR.

But a stab at backwards compatibility is the reason for the two requirements.

>   a security aware resolver MUST attempt to retrieve missing DS, KEY,

I.e., be liberal in what you receive.

>   (more detailed in the subsections)

I.e., be conservative in what you send.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."

---

From: Brian Wellington <[email-masked]>
Date: Thu, 17 Apr 2003 10:46:11 -0700 (PDT)

> caching servers performing proxy DNS service on statefull firewalls).

The old days are long gone.

> But a stab at backwards compatibility is the reason for the two requirements.

It won't work at all.  One reason that it won't work is that any
intermediary server that would need to be explicitly queried for SIG
wouldn't have set the DO bit in the first place, and thus wouldn't have
received the SIGs in its response.

Supporting backwards compatibility is a good idea, but not when it won't 
work.  Especially not when it requires servers to add code just to handle 
cases that won't work.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Apr 2003 13:53:18 -0400

>The old days are long gone.

True - but that's why the text was there.  Perhaps changes can be 
made, but it's good to know the history first.

>work.

;)