Re: OFFTOPIC: DNSSEC groupthink versus improving DNS

[Mark Andrews <[e-mail]>]

> Paul Vixie wrote:
> 
> > as a possible proposed "they" in that example, i wonder what other option
> > will allow arbitrary end users to be sure that an NXDOMAIN has not been
> > remapped by their ISP or by their RDNS?  or that a secondary name service
> > provider (or a primary name service provider for that matter) hasn't added
> > a wildcard to catch typo's in their customer domains and send them to an
> > advertising server?  in other words, what other options provide end-to-end
> > data integrity for DNS?  if all you've got is hop-by-hop, i'm uninterested.
> 
> I maybe late to this party but I tried to engage you in this in previous
> email correspondences, suffice to say I don't think either of us have
> all the answers but dismissing alternative opinions on how this could be
> solved out of hand isn't going to help either.
> 
> > amit klein and dan kaminsky have showed us some off-path attacks, to which
> > dan bernstein and amit klein and david dagon have shown us some RDNS-only
> > defenses.  but provider-in-the-middle and more generally man-in-the-middle
> > attacks are on-path not off-path.  i want protection against on-path
> > attacks, as well as against all possible future off-path attacks.  you're
> > right that i'm dismissing proposals that do not address those requirements.
> > now you know exactly why.
> 
> You just pointed out the solution, and I'm pretty sure you or others
> have mentioned this before, but as far as end to end solutions go the
> only solution is to run the resolving DNS caching at the end points.

I don't think anyone would disagree with you.  Preferably validation
should be done in the application.  If that is not supported by the
application then on the local machine.

Validation in off machine caches is only there for the legacy machines.

> While this negates some of the benefits of caching by say ISPs, it's
> more than obvious the ISPs can no longer be trusted on that front in any
> case and end user directly requesting to authoritative DNS servers is
> the only option.

Only if the ISP's don't supply clean path.  DNSSEC allows you to
detect when the path has been compromised.

> After all, do we allow ISPs to cache SSL connections, why should DNS be
> any different?
> 
> > after watching masataka's superior approach get railroaded into a ditch
> > back in 1996 or 1997 or so, i can no longer get bogged down in how ugly
> > the protocol is or how ugly was the process that begat that protocol.  my
> > pragmatic concerns are only, is it end-to-end, and can it be made to work?
> 
> How much enthusiasm has been garnered for DNSSEC since well ever except
> by those evangelising it?
> 
> If you can't sell it to people like me purely on its merits it's already
> a forgone conclusion, I'm not trying to be facetious here or
> antagonistic but pointing out a reality of the way the world is, not the
> way we'd like the world to be.
> 
> > but show me a hop-by-hop solution and i'll say "this isn't complete" and if
> > it requires a replacement or upgrade of both RDNS and ADNS nodes then i'll
> > say "at that price i'd prefer end-to-end data integrity, please."
> 
> You've already outlined numerous corner cases where DNSSEC will fail in
> end to end data integrity, so obviously it's not solving the issue in
> all cases either.
> 
> My hop-by-hop approach wasn't the end game, merely a stepping stone
> until something better could occur at the end points, my approach is
> simply trying to go the path of least resistance and work up from there.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

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