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

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 11:55:18 -0500

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

I must confess to being a bit surprised that anybody would even consider 
accepting an AD-is-secure bit from a name server with which their only 
relationship is that they saw its IP address in a DHCP packet.   Of course 
not.   You're going to run a local caching name server on your host that 
you know is configured the right way because you (or Microsoft, or Apple) 
configured it.

If your objection is that there's no way in the protocol to ensure that 
this has been done, I think it's not a good real-world objection.  In the 
real world, there are two classes of DNS users - those who consider it a 
black box, and those who care enough to mess with it.   Neither of these is 
a customer for a way of representing the secure resolver's security policy 
in the wire protocol.   The first group doesn't care - they want their 
vendor or sysadmin to set it up right, and if it's not set up right, they'
ll find out when they're defrauded.   The second group is going to 
administratively verify every part of their resolver system.   Where is the 
third group that you're talking about that needs a  verification system 
that operates in the wire protocol?

--
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: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 10:10:01 -0700

> I must confess to being a bit surprised that anybody would even
> consider accepting an AD-is-secure bit from a name server with
> which their only relationship is that they saw its IP address in
> a DHCP packet.

"accepting an AD-is-secure bit" is a bit difficult, as there is no
way or suggestion of what to do with the bit.  it is defined, but
there is no current way to pass it up through an API to an app, and
no guidance on what an app might do with that information if we
ever got it there.  i have visions of yet another ignored indicator
icon in the status line of one's fave browser.

and, for the vast majority of hosts, getting the address of the dns
server(s) to use via dhcp is the way of life.  and your implication
is right, dhcp is not known for its security.

> Of course not.  You're going to run a local caching name server
> on your host that you know is configured the right way because
> you (or Microsoft, or Apple) configured it.

does my win98 machine have a local caching nameserver?  [i mean the
question seriously] i know macs now have freebsd under them (yes!),
so it really could be a validating cacher underneath in that case.

randy

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Jun 2002 00:30:04 +0700

Date:        Fri, 14 Jun 2002 11:55:18 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | You're going to run a local caching name server on your host that 
  | you know is configured the right way because you (or Microsoft, or Apple) 
  | configured it.

You're thinking about the wrong kind of host.  Sure I could (but as it
happens, mostly don't) do that with PC/mac class systems, but am I
really going to be running a caching resolver in my mobile (cell) phone?
Or in my wristwatch for when it looks up the address of its NTP server?
Or in my light bulb for when it verifies the identity of the switch?

These are the kinds of things that really want to use stub resolvers.
They might also want to know that the answers have been verified (at
least that someone with whom they have some kind of relationship is
claiming that they're verified).

Code to do all of this lives in roms, and moderately large amounts of
that are feasible, easily.   A nameserver cache lives in ram, and that
means power to keep it running all the time.  That's not so easy.  It is
also only effective if the host is doing more than one lookup a week...

kre

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Jun 2002 13:20:51 -0400

Assuming "you" is me (I'm in the To: field).

I agree with Ted's assessment.  One group won't care, the other will 
check themselves.  This is in roughly in line with my objection to 
defining the AD bit (or bothering to redefine it).

When I mention that the DNS protocol lacks the ability to transfer 
the "policy" of the server (keys), I am stating this as a reason why 
the AD bit is of dubious value.  I am not advocating extending the 
DNS protocol to transfer policy.

I should also say that in my arguements I have been trying to tie the 
reasons I object to the draft to technical issues (I understand). 
For this reason I have stayed away from stating "what 
users/applications will want" because I no expert there.  I see that 
the DNS protocol lacked what I mentioned before and rationalized that 
"if I can't see your rules, I don't care whether you followed them."

At 11:55 AM -0500 6/14/02, Ted Lemon wrote:
>If your objection is that there's no way in the protocol to ensure that this
>has been done, I think it's not a good real-world objection.

I'm assuming that by the above you mean that the lacking a means to 
get the policy isn't a sufficient reason to kill the AD bit.  You're 
right, it isn't.  But it is one of the reasons why I dislike the AD 
bit.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "Matt Larson" <[email-masked]>
Date: Fri, 14 Jun 2002 13:43:44 -0400

> icon in the status line of one's fave browser.

What good is DNSSEC going to do for anyone if an answer's security
status isn't conveyed to the user (in a manner appropriate to the
particular application)?  Why bother securing a zone at all if no
applications do anything with it?

> question seriously]

Nope.  Only W2K Server or better.

Matt

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Jun 2002 00:46:13 +0700

Date:        Fri, 14 Jun 2002 13:20:51 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a05111b03b92fd44c9c9c@[192.149.252.173]>

  | One group won't care, the other will check themselves.

This translates into "if you aren't able to check, then you're
not allowed to care".

Certainly from a pure security viewpoint, where all that matters is
perfect validation, that's not unreasonable.

But almost no-one needs that - remember that all security is a trade
off between the costs, and the benefits (as is almost everything else).

It is perfectly acceptable for people (hosts, ...) to agree to
permit some increased risk, in return for some lower cost.  That's
a tradeoff that everyone has to be permitted to make - and it is
not acceptable to simply write off anyone unable to get absolute
proof of correctness (nor to relegate them to "anything goes").

Eg: for many systems, simply trusting what the local resolver says
(without requiring it to be on the same net, and probably without
any special security measures) will be just fine.   If that resolver
has given me false information, then I know who to go and blame.
That, or the answer has been spoofed, and if my net is even half way
reasonably protected, I can usually limit the source of that spoofing
to somewhere local (filtering inbound source addresses, etc).
So, if there's spoofing, it is coming from somewhere local, and
whoever is responsible, either for spoofing, or leaving a system
open enough to allow it to be taken over, can be deal with.

Similarly, if the DHCP server gives me a bogus address as to where
I should query for my DNS answers.

For many users, that level of security is all that is required.
Don't demand that everyone have provably correct security, just
because you have been focused on that kind of issue (perhaps for
others who do need it) for so long, that everything else seems
hopeless.

By all means make sure the mechanisms are in place to allow good
security for those who need it - but don't then simply ignore everything
which isn't necessary in that perfect world.

kre

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 14:05:32 -0400

On Fri, 2002-06-14 at 13:43, Matt Larson wrote:
> > there is no current way to pass it up through an API to an app

I don't think this is true; Jakob Schlyter mentioned the
getrrsetbyname() API a few days ago.

> applications do anything with it?

The major benefit of DNSSEC is: signed records cannot be spoofed to
resolvers who do verification.

In order to realize that benefit, the resolver which performs
verification has to throw out records which fail verification, but pass
through records which can be verified to be unsigned.

But applications don't have to do anything special.

Paul Vixie wrote:
> So, six++ years into the experiment, we still don't agree on what
> problem DNSSEC is supposed to solve, and what the underlying security
> model will be?

Evidently not.  (Which doesn't mean the model isn't well-documented.)

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 13:52:28 -0400

> "if I can't see your rules, I don't care whether you followed them."

I take issue with your terminology.  First, AD does not mean "I followed
my rules."  It means "this record is signed and valid."  We have already
seen some confusion on this point.  Second, the phrase "local policy"
only applies to the AD bit when data is being served from a zone file. 
For data retrieved from other DNS servers, the only relevant "local
policy" is the preconfigured keys used by the caching resolver, and it
is very confusing to refer to the preconfigured keys using the general
term "local policy" when the AD-is-secure draft uses that phrase to mean
something else.

AD-is-secure applies to the case where you know enough about your
recursive resolver to trust it, and want to know whether records you've
asked for were signed or not.  It has nothing to do with discovering
information about a resolver you've just heard of.

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 11:11:32 -0700

> particular application)?

while i agree, i fear a very long security discussion of flavors of secure
and what an app would think about them.  [ i prefer mocha ]

> Why bother securing a zone at all if no applications do anything with it?

warm fuzzies when most of the dns data have been signed?

i can sign my part of the tree, but i can not force you to validate the
signatures.  so this may be a long-term game.  i suspect this is why some
folk focus on how things will act/scale when most of the data are signed
some years out.

randy

---

From: Rob Austein <[email-masked]>
Date: Fri, 14 Jun 2002 14:23:26 -0400

> Or in my light bulb for when it verifies the identity of the switch?

Yes, if doing so is the least painful way to accomplish the task for
which the device in question was created using security services
appropriate for the task at hand (I'm dubious about DNS-using light
switches, but let that pass).

> claiming that they're verified).

If they're part of an environment with stable and well-understood
trust relationships, I agree.  A light switch might fit this model.  I
doubt that a wrist watch or cell phone fits.

> also only effective if the host is doing more than one lookup a week...

Please see the previous discussion of caching recursive almost-stubs.
Long term caching is a service that the environment can provide.  The
device itself may only need to cache a small number of records, may
only need to do so for a fairly short period of time, or may be able
to tolerate a brief interval of less than complete functionality when
first powering up.

With all due respect, I think that this whole caching issue is largely
orthogonal to the security model discussion, and the latter is, I
think, the discussion that the WG really needs to have.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 14 Jun 2002 13:28:38 -0500

[sorry for the dupe if you get one]

> so it really could be a validating cacher underneath in that case.

winsock2 systems have per-process caches, meaning that a lookup will be
cached for the TTL, but it doesn't have support for iterative queries

The MacOS resolver in 8.5 actually has iterative support, but it still
requires a local server to get the process started (if it only gets
delegation information but no answer, then it will go ask the delegation
target itself). I don't know what's in OS X but my guess would be that it
is the typical braindead stub in all other UNIXes.

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Jun 2002 14:31:04 -0400

At 1:52 PM -0400 6/14/02, Greg Hudson wrote:
>my rules."  It means "this record is signed and valid."  ...

For intance, look at RFC 3008:
1 - Introduction

    This document defines additional restrictions on DNSSEC signatures
    (SIG) records relating to their authority to sign associated data.
    The intent is to establish a standard policy followed by a secure
    resolver; this policy can be augmented by local rules.  This builds
    upon [RFC2535], updating section 2.3.6 of that document.

Note "local rules."  Whenever any validation is done in DNS, it is 
subject to local rules.  (This is a point of the DNSSEC protocol that 
is often overlooked.)  Whether a record is signed is an objective 
statement.  Whether the signature is valid is subjective.

I am short handing trusted keys and local policy.  The reason is that 
the trusted key set is the only part of local policy that has become 
concrete enough to use in an example.  Expressing authorization rules 
(what key is trusted to sign what data) has not been attempted.

>information about a resolver you've just heard of.

If you trust the recursive resolver, then trust it to follow the 
protocol rules.  No where in the protocol is a compliant recursive 
resolve allowed to send onward bad data - pending data than may be 
proven bad in a moment, but not bad data.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 13:31:24 -0500

> icon in the status line of one's fave browser.

AFAIK, there isn't a standard that defines the resolver API, so this is a 
bit of a red herring.   If an application cares about the AD-is-secure bit,
  it will find a way to use it.   And I think it's plausible that an 
application might care about it - for example, I wouldn't mind a bit if my 
web browser were smart enough to stop me from sending a credit card number 
to a site the browser had reached in an insecure manner.   It's too early 
in the life of secure DNS for this to happen now, but I think it's 
reasonable to say that secure DNS might be part of a security validation 
process like this in the future.

> is right, dhcp is not known for its security.

A host that implements AD-is-secure can't use the DNS server listed in the 
DHCP packet as its resolver - it's that simple.   Even if DHCP were secure,
  that would still be true, because secure DHCP just means that you know 
which DHCP server you're talking to - it says nothing about the security 
policy at the site you happen to be connected to, as Ed has pointed out.

> so it really could be a validating cacher underneath in that case.

You can install a local caching nameserver on your Win98 machine, but by 
default it doesn't.   We are talking about the future, here, though.   If 
DNSSEC becomes something for which there is a market, Microsoft is neither 
stupid nor lazy - they will implement a secure DNS caching nameserver or 
something like it on Windows YO, or in .OFU (the next version of .NET).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 13:44:01 -0500

> I agree with Ted's assessment.  One group won't care, the other will check 
> themselves.  This is in roughly in line with my objection to defining the 
> AD bit (or bothering to redefine it).

I think  you missed part of my point, though.   On some level, some system 
somewhere has to tell the application "I was able to validate this data," 
or "this data was not signed."   I would say that there is no need for this 
system to be able to say "this data failed validation," because in that 
case it should just discard the data.   Whether that validation is 
something that needs to be set in the protocol, with a bit, is something 
that I have to admit I am not qualified to say, but if applications use 
stub resolvers, it seems clear that it would be necessary.

> I see that the DNS protocol lacked what I mentioned before and 
> rationalized that "if I can't see your rules, I don't care whether you 
> followed them."

You have to be careful to identify who "I" is in this case.   In the case 
of the black box user, "I" is not the user - it is the author of the 
application that the black box user trusts.   And "your rules" are rules 
that are probably guaranteed by the operating system - this is why it's 
important whether there's a caching resolver on the system that's setting 
the ADis bit.

If you are an under-the-hood kind of guy, then "I" is the user - you.   And 
"your rules" are also the user's rules - your rules - because you set up 
the caching resolver that's doing the verification.

So in both cases, *if* the application cares about ADis, and *if* the 
application isn't going to do the name resolution process itself, the ADis 
bit is useful.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 13:50:26 -0500

> Or in my light bulb for when it verifies the identity of the switch?

If you can believe that there's going to be a network connection to your 
light bulb, I don't see why thinking that the light bulb will have a 
caching resolver is any more of a stretch.   At this point the computer in 
my cell phone is a lot mobier than my first PC, and I'm quite sure I could 
have gotten a caching resolver running on my first PC if I'd cared to do so.

> also only effective if the host is doing more than one lookup a week...

Then maybe this is a case where you don't need the ADis bit, because the 
application would just do the lookup and verify the signatures itself.