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

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jun 2002 06:31:40 -0700

stub resolvers already have blind trust in their recursive servers.
(dnssec signature verification at the stub level makes no sense.)

this is what tsig is for.

let's look for a new problem.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jun 2002 08:49:27 -0700

> I don't understand why it would never make sense.

because it will take a huge amount of bandwidth on every query.
as in, several kilobytes of traffic to fully verify an A RR 
before your browser will follow a link.

"stub" means no cache.

---

From: Rob Austein <[email-masked]>
Date: Tue, 11 Jun 2002 12:18:57 -0400

> "stub" means no cache.

A resolver which only issues queries with RD=1 may still have a cache.

I don't care whether one calls such a thing a "stub resolver" or not.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Jun 2002 11:59:56 +0859 ()

Erik;

> Suppose I there is a CPU powerful client with a relatively high round-trip 
> time to everywhere (many wireless things have high rtt due to coding
> necessary to deal with fast fading radio issues).
> 
> Having that client do a single DNS query to a recursive resolver
> makes a lot of sense.

First, that is an issue addressed by additonal RRs.

Second, non-stub resolver may ask recursive service.

Third, rtt of most, if not all, wireless things, including those used
for highly interactive service of telephony and plain WLAN, is low.

						Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Wed, 12 Jun 2002 13:37:23 +0700

Date:        Tue, 11 Jun 2002 12:18:57 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | A resolver which only issues queries with RD=1 may still have a cache.

Of course, and this is part of the issue here.

  | I don't care whether one calls such a thing a "stub resolver" or not.

But for the purposes of this discussion, resolvers that have no cache are
what is relevant.   It is useful to have a name for such things, and "stub
resolver" seems to be that.

Other resolvers that issue RD=1 queries (there was a time, probably still
is, when all resolvers issued RD=1 always - the only question was whether
the server had RA=1 and would process the recursion) certainly exist,
but are less relevant.

It seems likely that a stub resolver (as defined 2 paragraphs ago) would
like to know whether or not its (presumably trusted) back end has validated
signatures or not.   Since the back end has no way of knowing whether or
not the stub resolver only wants validated answers, it can't just not
reply if the signature checks fail.   Hence the AD bit seems to be useful.

Now for resolvers that want to check signatures themselves, the AD bit
can simply be ignored.   Having it there, either set or clear, cannot
possibly prevent the SIGS being fetched, and validated.

So, all this discussion seems to me to be pretty pointless.   I am pretty
sure the draft already says that the AD bit shouldn't be trusted unless
the resolver receiving it has some other way of trusting the resolver that
sent it.

Note that the back end resolver (the one that received Rd=1, has RA=1, and
actually sets the AD bit) has no method to know what kind of resolver is
talking to it - it doesn't know whether the back end trusts it or not
(it may know that it is going to use TSIG to communicate with its client,
but presence of TSIG does not guarantee trust, nor does its absence
prohibit it), so it just sets the AD bit (or doesn't) on all queries it
processes, regardless of whether the value will end up being used or not.

While space in DNS packets is limited, I thing we can afford that one bit...

kre

---

From: Greg Hudson <[email-masked]>
Date: 12 Jun 2002 10:45:46 -0400

On Wed, 2002-06-12 at 02:37, Robert Elz wrote:
> signatures or not.

Uh, I'm not quite sure what you're saying here, but this statement makes
me a little nervous.  AD=1 means the back end has validated signatures,
*and* all the required signatures were present and valid.  AD=0 means
the back end has not validated signatures, *or* the required signatures
were absent or invalid.  AD doesn't give you a way to determine if the
back end is DNSSEC-aware or not, unless you happen to know of a record
with a valid signature.

It's important that everyone be on the same page here, so that we don't
get AD-is-confused.  People (including area directors) in the opt-in
discussion have already raised the possibility that a query for an
unsigned record in an opt-in zone might come back with the AD bit set,
which could only happen with a completely different meaning for the AD
bit.  Sure, you can cryptographically determine that the requested
record wouldn't be signed if it does exist, but the record clearly fails
the test:

   "The AD bit MUST NOT be set on a response unless all of the RRsets in
   the answer and authority sections of the response are Authenticated."

---

From: Robert Elz <[email-masked]>
Date: Wed, 12 Jun 2002 22:13:57 +0700

Date:        12 Jun 2002 10:45:46 -0400
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Uh, I'm not quite sure what you're saying here,

Most likely I wasn't being very clear, but I disagree with nothing
that you said, so I don't think we have any problem...

My point was more along the lines that receiving a reply with AD=1
set does not commit the recipient to trust the thing - it can go and
do its own validation if it feels the need.

kre

---

From: Rob Austein <[email-masked]>
Date: Wed, 12 Jun 2002 13:01:11 -0400

At Wed, 12 Jun 2002 13:37:23 +0700, Robert Elz wrote:
> what is relevant.

Sorry, but I don't agree that only resolvers with no cache are
relevant.  A resolver for a PDA might include both a small cache and
DNSSEC signature verification code but still be recursive-mode-only,
simply because the iterative resolver function is something that
really doesn't need to be on the PDA if it's readily available from
the environment du jour.  Farming out signature verification to the
environment du jour is a very different proposition.

I'm not saying that there won't be dumb little boxes that support
neither iterative resolution nor signature verification (there almost
certainly will).  I am saying, however, that if I were writing code
for a device with constrained resources, I'd put signature
verification much higher on my priority list than iterative
resolution, particularly since the bulkiest part of the signature
verification code is likely to be crypto functions that I might well
have loaded anyway to support IPsec, TLS, or something like that.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Jun 2002 17:12:14 +0700

Date:        Wed, 12 Jun 2002 13:01:11 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm not saying that there won't be dumb little boxes that support
  | neither iterative resolution nor signature verification (there almost
  | certainly will).

But surely these are the boxes for which the AD bit is relevant?
Your (slightly) smarter boxes can just ignore the bit, however it
is set, can't they?   How can the state of this one bit possibly
alter how your smarter resolver works, assuming it isn't interested
in the information provided (however little or much that may be) ?

kre

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Jun 2002 07:53:32 -0400

>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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Jun 2002 14:43:48 +0200 (CEST)

> back end is DNSSEC-aware or not, unless you happen to know of a record

I've been assuming that 'some of the required signatures are invalid'
would mean that the data wouldn't be returned to the client.
Section 6 in 2535 might mean this by "not retained" below
but this is far from obvious:
   Data stored at a security aware server needs to be internally
   categorized as Authenticated, Pending, or Insecure. There is also a
   fourth transient state of Bad which indicates that all SIG checks
   have explicitly failed on the data. Such Bad data is not retained at
   a security aware server. Authenticated means that the data has a

My concern is that it seems really broken if the client can't easily
tell the difference between Insecure and Bad.

So what should a recursive resolver do whith Bad data?

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 13 Jun 2002 12:10:21 -0500

on 6/12/2002 1:37 AM Robert Elz wrote:

> Note that the back end resolver (the one that received Rd=1, has RA=1,
> and actually sets the AD bit) has no method to know what kind of
> resolver is talking to it - it doesn't know whether the back end trusts
> it or not (it may know that it is going to use TSIG to communicate with
> its client, but presence of TSIG does not guarantee trust, nor does its
> absence prohibit it), so it just sets the AD bit (or doesn't) on all
> queries it processes, regardless of whether the value will end up being
> used or not.

First a disclaimer that I haven't fully internalized all of the DNSSEC
stuff so this has the potential to be a really stupid question.

It seems to me that there are a couple of problems that can be solved by
providing a way for the stub resolver to indicate whether or not the
calling application and/or the stub resolver is going to perform
validation, at which point there is only a question of how this desire
should be signalled.

I would think that using a flag in a psuedo OPT RR would handle this
nicely. On the one hand this tells the back-end resolver what kind of data
it needs to return (if the calling application or stub resolver is opaque
about DNSSEC then it only has to return the normal stuff). Secondarily,
the use of the OPT RR tells the back-end resolver that the stub resolver
is capable of accepting large messages containing all of the crap that the
stub and/or application needs. Would this work?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Andy W. Barclay" <[email-masked]>
Date: Fri, 14 Jun 2002 18:38:06 -0700

After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to 
me that DNSSEC may be a waste of time.

It seems that applications are capable of the same security that we can 
provide with DNSSEC. (I realize that if we could get a global 
deployment, we could increase security on legacy protocols).

For example, the draft referenced above says:
"The resulting list of desired security services was
      1) data integrity, and
      2) data origin authentication."

Any application that uses certificates has those capabilities. Legacy 
applications that require security are being upgraded to support 
certificates/keys (ntp).

Can someone convince me that DNSSEC still makes sense?
(One argument that I won't buy into is that my phone/PIM or whatever 
doesn't have the horsepower to do certificates. By the time we get 
dnssec deployed, they will have that horsepower.)

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

"Money, not morality, is the principle commerce of
civilized nations"
    -- Thomas Jefferson

---

From: [email-masked]
Date: Sat, 15 Jun 2002 12:10:35 +1000

> dnssec deployed, they will have that horsepower.)

	DNS is just another application trying to secure its own
	transactions using cryptography.  You have no problem with
	NTP using cryptography to secure its transactions.  What's
	your problem with DNS using cryptography to secure its
	transactions.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 22:18:38 -0400

The primary purpose of DNSSEC is to protect the DNS infrastructure,
which is mostly name-to-address and address-to-name mappings, not to
provide security for applications.  There are those of us who wouldn't
mind being able to use DNSSEC to protect application keys, perhaps
because of a dislike of X.509 certificates or the certificate model in
general, but that's a separate problem.

You could argue that protecting infrastructure is pointless; that
everyone should use secure application protocols instead.  I wouldn't
agree, though:  Defense in depth is a fine thing.

For instance, right now, if you want to attack www.amazon.com, you can
simply spoof its DNS record to some set of clients to point to your own
web server, which is a replica of www.amazon.com except it never uses
SSL.  The vast majority of users are unlikely to notice.  You'll be
detected eventually, but not before you steal some large number of
credit card numbers and/or sales.

With DNSSEC deployment to the www.amazon.com record and the resolvers of
most users, this attack gets harder.  You can't spoof the DNS record, so
you have to hijack TCP connections or do something similarly difficult.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 15 Jun 2002 11:56:09 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

"Andy W. Barclay" <[email-masked]> writes:

> It seems that applications are capable of the same security that we
> can provide with DNSSEC. (I realize that if we could get a global

One of the design goals with DNSSEC was to distribute keys used not
only for securing the DNSSEC infrastructure, but also for use by
applications in general.  This is still not commonly implemented, but
is IMHO the main feature of DNSSEC.  The RFC 2535 abstract is
refreshlingly clear about this being on of the goals:

,----
|    The extensions provide for the storage of authenticated public keys
|    in the DNS.  This storage of keys can support general public key
|    distribution services as well as DNS security.  The stored keys
|    enable security aware resolvers to learn the authenticating key of
|    zones in addition to those for which they are initially configured.
|    Keys associated with DNS names can be retrieved to support other
|    protocols.  Provision is made for a variety of key types and
|    algorithms.
`----

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 16 Jun 2002 08:17:47 -0700

> general, but that's a separate problem.

I am one of those people.

> everyone should use secure application protocols instead.  

This is precisely my point. I'm arguing that protecting DNS maybe
pointless, and I'm looking to be convinced that it makes sense.

> I wouldn't

Ok, so your argument is that its worthwhile to protect legacy protocols.
My argument is that if we are modifying the applications anyway, why
not have the "default" protocol of the web browser be https? In this
way, if someone has spoofed the address, then the user will get
a dialog box indicating a certificate mismatch. I realize that there
is still a class of users that will simply dismiss this dialog box, and
continue to use the site, but that same class of users would probably
also dismiss the box that says "the DNS name could not be 
authenticated". Actually, its probably worse, because there is a larger
class of users that, during deployement, would get so annoyed at this
warning, that they would check the "don't tell me this again" box.

> you have to hijack TCP connections or do something similarly difficult.

yes, you are correct, assuming that the application or resolver has been 
modified to check signatures, or if the application trusts its local
nameserver.

It takes a long time to understand nothing.
    --EDWARD DAHLBERG

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 16 Jun 2002 09:01:36 -0700

I agree about using DNS to distribute keys, and that would convince me 
that DNSSEC is still worthwhile, however, with the draft suggestion to 
limit the KEY RR, and with DNSSEC taking so long to be deployed, I feel 
that people requiring secure key-based protocols won't wait for
DNSsec. I've checked the working group drafts, and I can't find any
that are working on storing application keys in the DNS. Is anyone aware
of work being done in this area - possibly outside the WG?

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Jun 2002 14:31:50 +0200 (CEST)

>    the answer and authority sections of the response are Authenticated."

A negative response, containing opt-in NXT records do not fail that test.
Setting AD on a response for a query (regardless where from) indicates
that all RRsets present in answer and authority section have been
validated. This does not mean that QNAME and or QTYPE do not exist.

This implies that the entity receiving the response can interpret the
difference between 2535-NXT and opt-in-NXT. This intelligence is nowhere
implied, and thus there is ambiguity. 

Roy

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Jun 2002 14:51:12 +0200 (CEST)

Roy