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

[Brian Wellington <[e-mail]>]

On Fri, 27 Jul 2001, Edward Lewis wrote:

> At 1:03 PM -0400 7/26/01, Brian Wellington wrote:
> >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.
>
> 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.

I would hope that the DNS protocol is replaced with something different
before the ability to revoke records is added.  As there is currently
not such a notion, I see no reason not to treat authentication at-receipt
and on-reply equivalently.

> >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.
>
> 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.

Well, then I'll reiterate the complaint that this is not a wording change.

> >> "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"?
> >
>
> 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.

Yes, guaranteed probably isn't a good work.  It was an idea, and not a
particularly good one.

I, and I believe a few others, want the AD bit to be useful.  It's not
useful if the spec requires the server to do verify-on-query, because
there are enough problems with that so that it will not work in practice.

> (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.)

What I wanted to say is that "the sending process has good reason to
believe that the data verifies, either because it has verified it itself
or obtained this knowledge through a trusted channel".

> >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.
>
> 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.

What is to stop an implementation from violating any spec?  Nothing.  Such
an implementation would be noncompliant.  RFC 2535, section 6.1,
says:

	The AD (authentic data) bit indicates
	in a response that all the data included in the answer and authority
	portion of the response has been authenticated by the server
	according to the policies of that server.

and in section 4.3:

     1. A security aware resolver that receives a response from a
        security aware server via a secure communication with the AD bit
        (see Section 6.1) set, MAY choose to accept the RRs as received
        without verifying the zone SIG RRs.

The first paragraph describes the major point of contention (and I note
that this never came up when 2535 was written), and the second describes
the intent.  The intent is to indicate to the resolver that it doesn't
need to check SIG records, not to explicity indicate that it has verified
the records.

Note also that AD is defined as "authentic data", not "authenticated
data".  If I generate and sign my own data, it is authentic.

> 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.

Neither do I, but I want to allow it.  That's why the draft (still)
contains the term "local policy".

> >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.
>
> 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?)

So, you agree that the calling process doesn't need to do that actual
verification, and it would be ok to set the AD bit if a trained monkey
clicked on the "Yes" button every time this popped up?  At that point,
there's no difference between this and just trusting that the server has
the right data in the first place.

("would also be insane" means that anyone who wrote such code would be
insane.  Not important)

> >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.
>
> 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.

Right.  But I can configure a server to give out good data to a resolver
without it being forced to do validation.

> 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.

I'm not.  The draft (still) says "local policy".  You're the one saying
that all admins should be forced to run a server that verifies
authoritative data.  I'm saying that it should be optional.

> >> 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"
>
> I don't agree with allowing "guaranteed" to be there.  (Same arguement as
> before.)  I think this weakens the definition.

I agree that guaranteed is a not a particularly good word.

It's getting pretty obvious that we're not going to reach a compromise,
since the draft is trying to retain the spirit of the original
specification, which you're disagreeing with, and you're completely
missing the fact that the draft doesn't require AD to be set on
authoritative data, but allows it.

Brian



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