Re: IESG feedback on dnsext-ad-is-secure

[Edward Lewis <edlewis@arin.net>]

At 5:12 PM +0700 6/13/02, Robert Elz wrote:
>But surely these are the boxes for which the AD bit is relevant?

I've objected strongly to this draft for some time now.  There is no 
new content here that hasn't already been presented to the AD, 
chairs, and authors during the last call.

My reasons boil down to:

1) Name servers are already instructed to return only valid answers 
(unless the CD bit was set on query).  Absent TSIG/SIG(0), if the 
resolver is going to trust an unprotected bit (the AD is in the 
header), the resolver might as well trust the operation of the 
protocol.  (I.e., what does the bit add?)

2) The bit is defined to indicate if the answers were checked in 
accordance to the name server's local policy (e.g., the trusted keys 
used, who it feels is authorized to sign the data).  As there is no 
means in the protocol to ask a name server what it's policy is (nor 
even what trusted key was used), the usefulness of know that the 
server followed its policy is of questionable value. (I.e., this 
relates to the "middleboxes" - opaque entities in the network that do 
not yield sufficient information when it is needed for 
troubleshooting.)

2a) The "danger" is that a server is using an incorrect trusted key 
and is passing off data as AD'd.  Although this is correctable 
easily, without the ability to ask for the trusted key used, a 
"victim" can't easily determine that the problem is the incorrect key.

3) The only case in which the bit comes into play is when data 
arrives that is signed.  A setting of 1 means that the signature is 
germane and has been sufficiently checked.  A 0 means that the name 
server deemed the signature immaterial and did not check it.  I don't 
see that distinguishing between the two cases is of use to a stub 
resolver.

4) The need to redefine the bit is rooted in the DNSSEC workshops. 
Prior to the addition of logging to the software we tested (BIND), 
there was no way to determine if the name server's verification code 
kicked in.  We looked for the AD bit to indicate whether the trusted 
key statements and the zone signing was being performed correctly. 
Now, with logs available, this can be watched at the server.  I.e., 
the AD bit really is best used as a debugging tool at the server - 
but that role has been overcome by events (the addition of logging).

5) This is a speculative objection...What if the data srrives with 
the AD bit set to 0?  Is the resolver going to try and get a 
different answer?  What will the user (presuming the bit's setting 
bubbles up to the GUI) do?  Basically, somewhere along the line, a 
different name server is needed to find a better answer, will this 
happen in stub resolver situations?

Yes, I realize that in #2 I say that troubleshooting is a problem, 
and in #4 troubleshooting was helped.  In #2 I an talking about 
end-to-end troubleshooting, in which the shooter has no access to the 
server in question.  In #4 I am talking about troubleshooting of 
one's own server.

In summary - I don't see how this bit improves upon a correctly 
running DNS(SEC)  protocol.  (If you're going to trust the server to 
tell you it followed the protocol, trust the server to follow the 
protocol!)

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


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