RE: DS and Opt-in - a proposal

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

The message below is the best expression that I've seen
yet of how the "initial fielding" of DNSSEC signed zones
will actually help things.  However, I think that
both of you are correct...

Both Netscape and IE include some DNS-related internal
capabilities--but I believe (as do others) that it's 
just a cache for data received through the normal system
gethostbyname() [or equivalent function].  In other words,
the browser will cache the results of the first "lookup"
of www.aol.com and will initiate subsequent connections
without a DNS lookup.  What the browser *won't* do is directly
try to recurse through the hierarchy, or understand any part
of the DNSSEC signing--at least for now.

The critical piece that's missing is the policy-enforcement
piece.  The end-user (browser/client) will likely not know
anything about DNSSEC-- so the recursive server needs to
decide, based on policy, which of the following information
is "safe" or "correct" (or trusted) enough to be passed to
the browser:
  - Signed data, signed by a key that is directly trusted
  - Signed data, signed by a key that is indirectly trusted
	(trust verified all the way back up to a trusted key
	 like .mil)
  - Signed data, signed by a key that is not trusted
	(which means that it could be bad, could be an impostor,
	 or could just be signed because some other "island"
	 of signed zones exists and we don't have a trust
	 relationship with that island)
  - Unsigned data.

As of right now, we trust all four.  At some point in the
*near* future, we need a configurable capability to trust only
the first two, but to alert to the existence of three and
four. That's great...but at that point, we need a way for
the browser to indicate that there are different degrees of
trust in the provided information--which sounds to me as
though DNSSEC *won't* just be transparent to the client.
(Either that, or we need lwresd or something similar on
every single client system--and don't get me started on
that.)

If all the zones which anyone *ever* needs to contact are
signed, then the problem becomes easier--which was your
stated situation.  However, I think that's an unrealistic
scenario for at least the next several years--and in the
meantime, we either need to have a configurable trust
policy, or we gain minimal benefit from DNSSEC signed
zones.  The best example I have of how to do this is the
MS IE 5.x+ configuration options for "trusted sites",
"local intranet", etc.  Not everyone will know the
difference between signed and unsigned DNS data--but there
should be a way for users (or sysadmins) to limit which
types of DNS data are acceptable.  This should likely
be a system-wide config file, though, rather than a 
browser issue--which means it really is an OS-level
issue.  (This was the path that led to lwresd, IIRC.)

Unless we find a way to ease the transition while still providing
a useful security enhancement, IMHO we're going to have trouble
getting signed zones into the "commonly used" category.

--
Rip Loomis
Senior Systems Security Engineer
SAIC Center for Information Security Technology 

> -----Original Message-----
> From: Greg Hudson [mailto:ghudson@mit.edu]
> Sent: Sunday, 30 December, 2001 00:58
> To: bert hubert
> Cc: namedroppers@ops.ietf.org
> Subject: Re: DS and Opt-in - a proposal
> 
> 
> On Sat, 2001-12-29 at 02:45, bert hubert wrote:
> > > In the Unix world, at least, the applications shouldn't 
> have to get
> > > involved, just the recursive resolver (named, 
> traditionally) and to some
> > > extent the stub resolver in libc.  The application may be 
> interested in
> > 
> > You must live in a parallel universe from mine. The 
> application developer
> > has needs. If DNSSEC is unable to meet, or worse, not 
> interested in those
> > needs, s/he will ignore it. It is not a unix question.
> 
> What needs?
> 
> Your initial message said "DNSSEC is going nowhere if they [browsers]
> aren't going to use it!"  I was arguing that DNSSEC is useful even if
> browsers stay the same as the are, at least in the Unix world.  If:
> 
>   * DNSSEC is deployed at the root,
>   * the recursive resolver is DNSSEC-aware and knows the root's key,
>   * com, amazon.com, and www.amazon.com are signed, and
>   * the path from the stub resolver to the recursive resolver 
> isn't easy
>     to attack (because they're on the same machine, the path 
> is behind a
>     firewall which the attacker can't get behind, or the path is
>     protected by TSIG)
> 
> then it becomes prohibitively difficult to spoof the address of
> www.amazon.com, even if the browser is completely ignorant of DNSSEC. 
> That's a win over the current situation, where it is 
> relatively easy to
> spoof that address (especially if you can watch the query, but in many
> cases even if you can't).
> 
> > There is no difference. Right now DNSSEC is purely academic 
> with some
> > laboratory experiments. Some fairy may come along and 
> suddenly make all user
> > applications DNSSEC aware, but don't count on it. It's not 
> that you write
> > the RFC and suddenly people start implementing it.
> 
> The only reason I can think of why most user applications 
> would need to
> be DNSSEC-aware is to convey to the user whether a domain is signed or
> not.  Since most users don't understand what that means, I don't think
> that's the most important part of DNSSEC.
> 
> > Just saying 'it is transparent from an applications' point 
> of view' does not
> > cut it. 
> 
> Why not?
> 
> > Interesting to note is that I'm told that IE has its own 
> resolver, separate
> > from the regular windows one.
> 
> Its own stub resolver or its own recursive resolver?  If the latter
> (which I somewhat doubt; it wouldn't work so well with 
> firewalls), then
> like any other recursive resolver, that would need to implement DNSSEC
> in order to benefit.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.