Subject: Re: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt

From: Greg Hudson <[email-masked]>
Date: Sat, 28 Jul 2001 12:57:09 -0700

(Risks dropped from the cc line.)

> Any client implementation that listens to a single bit of the
> response to tell it whether the response is cryptographically valid
> must be considered noncompliant with the DNSSEC spec.  It's just an
> old fashioned insecure DNS client.  There's nothing wrong with that,
> as long as you don't have any high trust expecations for it.

I think you're overreacting.  What we're looking for is a way to deal
with situations like this: in Unix, the libc resolver is generally
pretty lightweight.  It will only do one query; if you ask for
something which turns out to be a CNAME, it expects the recursive name
server to supply the pointed-to record.  If you want your machine to
do full recursive resolution, you run a local named (or dnscache, or
whatever) and point your stub resolver at that.

Pursuant to that architecture, the stub resolver probably doesn't want
to be validating DNS signatures, especially if it would have to go out
and fetch SIG records up to the root.  We have several lightweight
mechanisms for securing the path from the stub resolver to the
recursive resolver: putting it on the machine, TSIG, and (blech)
firewalls plus the presumption of no internal attackers.

I have yet to understand why anyone wants to set the AD bit on
unchecked data.  Sure, an authoritative server shouldn't have to do
cryptography, but it also shouldn't ever need to set the AD bit unless
it's also acting as a recursive resolver for clients.  In which case
it had better be prepared to do cryptography if it wants to set AD
bits.

> PS: I know, I know, the "valid" bit will be secured by some "out of
> band" means.  Like a shared static key, and/or by the security of
> the file system on the server.  Right.  For extra credit: composing
> several weak security primitives produces what?  Strong security or
> weak security?

In the scenario I described with the cache on the same machine as the
stub resolver, where is the weak security primitive?

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

---

From: John Gilmore <[email-masked]>
Date: Sat, 28 Jul 2001 12:35:22 -0700

I think some of you guys have gotten so tied up in micromanaging DNS
Security implementation details that you forgot what swamp we were
trying to drain.

There is no point in building a cryptographically-secured DNS in which
many of the machines will be configured to "just believe whatever they
are told, regardless of the cryptographic signatures"!

We already have such a DNS -- today's.  It doesn't need signatures or
AD bits or big packets or any other changes.  Anyone who is happy
with that can go home and stop arguing.  The rest of us are interested
in the real security and integrity of the Internet.

Any client implementation that listens to a single bit of the response
to tell it whether the response is cryptographically valid must be
considered noncompliant with the DNSSEC spec.  It's just an old
fashioned insecure DNS client.  There's nothing wrong with that, as
long as you don't have any high trust expecations for it.

Any server which deposits a single bit in the response to claim to
clients that it has cryptographically validated the results, so
they don't have to, is just encouraging the above abuse.

I'm not shocked to find people advocating that such a server actually
lie to the clients about whether it has validated the data.  The
entire model (trusting a packet to tell you whether somebody else has
validated the data) provides ample opportunities for not only your
friends but your enemies to lie to you.  Just like in the current DNS.

	John

PS: I know, I know, the "valid" bit will be secured by some "out of
band" means.  Like a shared static key, and/or by the security of the
file system on the server.  Right.  For extra credit: composing
several weak security primitives produces what?  Strong security or
weak security?

PPS: The real question is why anyone is advocating that the DNS be
"secured" by lame security.  There are challenges aplenty even when
you're working with strong primitives; trying to mix in weak stuff is
just wasting everyone's time.  People have encouraged me in the past
to assume the possibility of mere incompetence rather than assuming
actual malice (e.g. when the FBI's Louis Freeh testified to Congress
about the security of DES).  So: Were any of you on the standards
committees for cellphone privacy?  How about on the 802.11 "Wiretap
Equivalent Privacy" committee?  Did any of you have a hand in
shortening the key in DES?  Perhaps you designed the encryption scheme
used in DVDs or in Adobe eBooks?  Whether you're incompetent or
malicious, stick to breaking codes, it's much easier.  Especially when
you break them in the standards committee before they're deployed.

---

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

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.

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

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

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.

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

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

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

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

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

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

"it" - the resolver?  If so, that's the point.  The server does the
validation, the resolver believes it (via TSIG, IPsec, firewall, blind
faith).

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

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.

I have never advocated requiring admins to run a server in a particular manner.

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

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

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.

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

---

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

What is the motivation for allowing a responding element (e.g., a name
server) to set the AD bit 1 for data that the responder has not
authenticated?

---

From: Brian Wellington <[email-masked]>
Date: Sat, 28 Jul 2001 08:22:48 -0700

On Fri, 27 Jul 2001, Edward Lewis wrote:

> >> "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
> >> sets in the answer and authority sections of the response, the AD bit MUST
> >> sets used when chaining.  The authentication MAY occur upon receipt of the

and in section 4.3:

Brian

---

From: Brian Wellington <[email-masked]>
Date: Sun, 29 Jul 2001 22:08:14 -0700

> it had better be prepared to do cryptography if it wants to set AD

Scenario 1: A server reads secure data from a zone file, trusting the
disk.  It then can set the AD bit on responses from that file.

Scenario 2: A server reads secure data from a zone file, and the key from
a configuration file.  Before setting the AD bit, it verifies the
necessary signatures.

Which sounds more secure?  2, obviously.  Until you notice that the key is
read from disk also.  If someone can corrupt your zone files so that you
give out bad data, they can surely corrupt the key so that the bad data
properly verifies.  Or, if they don't want to do that, they can just
hijack your server and insert bad keys into the running process.

The point is that if you trust a server enough to believe that it has
verified data, you should trust it enough to read signed data from disk.
Conversely, if you don't trust it enough to read signed data from disk,
you shouldn't trust it enough that you believe it when it claims to have
verified data.

That's why I believe that setting the AD bit on locally configured data is
acceptable.  It's no more or less secure than having the server verify it.

Brian