Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt

From: Brian Wellington <[email-masked]>
Date: Thu, 26 Jul 2001 10:03:34 -0700

On Thu, 26 Jul 2001, Edward Lewis wrote:

> Anyway, here is (a start on) how I would clean up the text:
>
> "In an answer in which all RR sets in the answer and authority sections are
> cryptographically authenticated according to the responding servers policy,
> the AD bit MUST be set to 1 if the query indicates the resolver understands
> DNSSEC [ref: DNSSEC OK draft].
>
> [[Note the use of MUST and not SHOULD.]]
>
> "Unless the responder has cryptographically authenticated all of the RR
> sets in the answer and authority sections of the response, the AD bit MUST
> be set to 0.  Any authentication MUST include authentication of all key
> sets used when chaining.  The authentication MAY occur upon receipt of the
> data or MAY occur upon reply.

Did you intend to change "any relevant negative response RRs in the
authority section" to "all RR sets in the ... authority section"?  I have
no strong feelings one way or the other, but it is a change.

I might also change the last sentence to:

	The authentication MAY occur upon receipt of the data or MAY occur
	upon reply.  If authentication is performed on receipt, the TTL
	MUST be trimmed as described in RFC 2535, section 4.4.  These two
	forms of authentication are considered equivalent.

Does this apply to recursive servers, authoritative servers, or both?  If
recursive only, I agree with the new wording.  Since it looks like the
next paragraph specifically deals with authoritative answers, I'll assume
recursive only, and suggest that the text be modified to make this more
clear.

> "In an authoritative answer (AA bit is set), with RR sets obtained from a
> zone file or zone transfer but not cryptographically authenticated by the
> name server, the AD bit MUST be set to 0.

This is definitely not a cleanup to the text; this is completely different
than the draft.  Would you settle for something like "guaranteed to be
cryptographically verifiable"?

To paraphrase my earlier argument that was ignored, I don't see any reason
why if I sign (and resign) data in a timely manner and verify it by hand,
that I can't run a nameserver with no crypto and have it indicate that my
data has been authenticated.

How about if the name server popped up a window saying "Someone has
requested www.foo.com.  Its SIG record is <...>.  Is this valid?"  This
lets the server safely say that the data is verifiable, but not perform
any verifications itself.  It would also be insane.

Basically, my point is that if I give out bad data and the my server's not
doing authentication, it's my own fault.  This only affects clients using
my server for recursive queries, which I as administrator would probably
not allow anyway, since authoritative and caching services should be split.

> "If the resolver does not indicate knowledge of DNSSEC, the AD bit MUST be
> set to 0."

OK.

>
> A table to summarize AD bit settings:
> Server:             from disk no check verify/get verify/put fail verification
>                     --------- -------- ---------- ---------- -----------------
> Resolver:
> doesn't know DNSSEC     0         0        0           0      0 serv fail
> knows DNSSEC            0         0        1           1      0 serv fail

I'd really prefer:

Server:       disk  secure-xfr insecure-xfr verified failed verify
             ------ ---------- ------------ -------- ---------------
DO not set      0       0          0            0       servfail
DO set         0/1     0/1         0            1       servfail

where 0/1 indicates either value may be used, depending on whether the
data is "guaranteed to be cryptographically verifiable"

Brian

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 28 Jul 2001 08:07:34 -0700

>	forms of authentication are considered equivalent.

I would omit the last sentence.  It is true in some contexts that the forms
described are equivalent, but not in other contexts.  Within the context of
the time-ignorant, non-revokable DNS (which he have today), the two are
equivalent.  In an application which is time-sensitive, the two are not.
Whether one feels that a time-sensitive application should be making use of
DNS for uptodate data is a point to argued elsewhere.

>recursive only, and suggest that the text be modified to make this more

I actually intended the above to apply to all servers.  "Receipt" could be
via recursive fetching or by zone loading from disk.  I don't know why the
distinction between recursive and authoritative is important in this case.
I really did word the clause for all server types.

>cryptographically verifiable"?

Yeah, this isn't a cleanup, but pushing a point that seems to be under
debate.  I wouldn't want the word "guaranteed" as this is even more vague.
I, and I believe a few others, really want the answering process (the one
that transmit the AD bit as 1) to be the one that does the crypto.  I
specifically want to avoid allowing an AD bit to be 1 when the
administrator is willing to trust the signing process to generate good
signatures.

(What I wanted to say is that "the sending process itself performed the
crypto and is sending the result."  I didin't say that because I was trying
to avoid any implementation reference.)

>data has been authenticated.

My concern is that if we allow the answering process to apply the AD bit
because it considers (without checking) that the signatures will verify,
what is to stop an implementation from just setting the bit on all data -
authortitative and learned?  I think the meaning of the AD bit is to convey
that "the answerer has checked this" and we want to maintain this - whether
the next hop is secured by TSIG, IPsec, or the receiver's rechecking of the
chain.

I also feel that it is alright for a server to answer with authoritative
data plus signatures that it hasn't checked - but should indicate this via
the AA=1, AD=0 bit settings.  I don't see the need to want to force AA=1,
AD=1.

>any verifications itself.  It would also be insane.

Yeah, for one, ISC would need to hire an X window programmer who could port
his/her results to Windows.  (I am puzzled about "also be insane."  What
does the also refer to?)

>not allow anyway, since authoritative and caching services should be split.

First - remember that DNSSEC is about securing the answer the resolver
gets, not the reply the server sends.  Be tight with what we allow the
server to do - leave less to local configuration so that a recursive server
can do what it needs to do.

Second - don't assume that admins will run DNS the way you think.  BIND is
built for just about any situation, and there have been many in use in the
past.  Don't pen admins into one right mental model about how to run DNS.

>Server:       disk  secure-xfr insecure-xfr verified failed verify

I don't agree with allowing "guaranteed" to be there.  (Same arguement as
before.)  I think this weakens the definition.

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

You fly too often when ... the airport taxi is on speed-dial.

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