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 12:10 PM -0400 7/27/01, Brian Wellington wrote:
> >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.
> >
>
> I didn't say anything about treating them differently.  But they two
> situations are not equivalent, and stating that they are does not help in
> any way.  I suggest you simple omit any commentary on the equivalence.  If
> I am interpreting your words right, you are saying that the two are
> equivalent in the implementation of the name server.  I agree with that,
> but this spec is supposed to be discussing just the protocol elements and
> not the implementation.

That's fine.  I just don't think the spec should explicity differentiate
these cases, which your alternative wording did.

> >> >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.
> >
>
> Well, yes.  Now what?

Um, stop trying to change the underlying meaning and calling it 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.
>
> No where do I require a server to do verify-on-query.  I thought it has
> been made clear that such an operation is not intended to be main-line
> processing.  I and a few others have thought it might be a good option to
> have - and an option means "not the default."
>
> How about this - for the remaining discussion on this document,
> verify-on-query is not mentioned as an operation.

Sounds fair.

> All I have been asking for is to limit the setting of AD to 1 in situations
> in which the responder (responding process) has verified the sets itself.
> This means a server that loads a zone without verification doesn't set the
> AD to 1.  Just about every other situation would lead to AD being 1.

And all I'm asking is that the responder trusts the set itself, either due
to validation or some other reason (like the data was properly
configured).

> >> (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".
>
> A "good reason to believe" isn't good enough in my opinion.
>
> I would like to know why you want to allow a server to set the bit based on
> something as weak as a "good reason."  Asking you as an implementor - do
> you plan to set the AD bit because you assume there's a "good reason" to do
> so?  As the implementor of BIND, you said you won't set the bit.  Because
> of that statement, I'm a bit puzzled as to why you want a relaxed reason as
> a precondition to setting the bit.

Huh?  As an implementor, I said that the current implementation doesn't
set the bit, not that it won't.

I believe that it serves no purpose to have an authoritative server verify
data, and still don't see how hit improves security.  If you sign the data
on the same machine as the server (or a different machine, and transmit it
securely), the server will see the signed data.  At that point, any error
that the server encounters validating the data is as likely to be the
fault of the server as the data.

You're arguing that administrators should not be allowed to be competent
wnough to manage their signed zones.

> >> >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.
> >
>
> The reason for bringing this up now is an increase in work on applications
> that will make use of DNSSEC-backed data.  I realize that a security
> sensitive application should check the answer on its own, but there are a
> lot of applications that want to sit at a point where they don't do crypto,
> but do want to know.

Right.


> I am asking to have this document to clarify the "authenticated by the
> server according to the policies of that server" to include an assurance
> (at least in spec) that the policy includes doing the crypto.  After all,
> the document's purpose is to redefine the AD bit to be set to 0 if there is
> no SIG RR to check.  (In other words, AD means that the data has at
> sometime been checked.  Well, an unsigned zone can be considered checked if
> the admin says "yup, that's mine" - so we are back to square one and don't
> need this draft at all.)

But the server wouldn't set AD if the data was not signed.  That's the
point of the draft - the AD bit means the data is secure (the draft is
called ad-is-secure, not
ad-is-cryptographically-verified-by-the-responding-process, after all).

> >> 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".
>
> Allow it, yes, but don't make it worthless.  Make the AD bit mean something.

It does.  That the data is secure, according to the local policy of the
server.

> >> >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.
>
> I don't follow this part of the thread.  I really don't know where you're
> going with this.

I'm trying to get the point across that data can be declared secure
without crypto in the server itself.  It's not working, I guess.

> >> >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.
> >
>
> "it" - the resolver?  If so, that's the point.  The server does the
> validation, the resolver believes it (via TSIG, IPsec, firewall, blind
> faith).

No, "it" == the server.  The server indicates that the data is secure
according to its local policy (which may mean that it verified it), and
the resolver believes it.

> >> 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.
>
> No, I never said that "admins should be forced to run a server that verifies
> authoritative data."  Again, it would be a nice option to have.  Two, all I
> want to have is the AD bit set to 0 if the answerer did not do the checking.

And all I want is the ability to run an authoritative server without
crypto that can set the AD bit to 1 on data that is secure.

> I have repeatedly said that it is fine for a resolver to see AA=1, AD=0 and
> the answer protected by some local link method (TSIG, et.al.) and (the
> resolver) can still believe the answer to be true.

Have you?  I haven't seen this recently.  I believe someone else (Jacob?)
has complained that checking both AD and AA makes things more complicate
for the resolver.

> >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.
>
> Since you stated this as a personal attack, I'll respond that way.  I am
> not missing the fact mentioned above.  I don't know where you got the idea
> that I want to tie the AD bit to the authoritativeness of the responder.
> How many times do I need to say "it is fine for the resolver to accept AA=1
> AD=0 TSIG'd (et.al.) answers as trustworthy?   I don't want the AD bit set
> on authortative data!  (Unless the authortative server bothered to check it
> - which doesn't mean I want the server to check it - but if checked, AD can
> be 1.)

Where have you said this?  Not in this thread.  I didn't mean that as a
personal attack, just a statement of frustration.

> PS - If your draft is trying to retain the spirit of the original, why
> bother writing it?  I thought this was to be a clarification to the spec.

The intention was basically to stop:
  - recursive servers from setting the AD bit on provably insecure data.
  - authoritative servers from setting the AD bit on unsecured zones.

Brian



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