Re: OFFTOPIC: DNSSEC groupthink versus improving DNS

Duane <duane@e164.org> Fri, 08 August 2008 03:13 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511873A6983; Thu, 7 Aug 2008 20:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoeFr1d0BEN8; Thu, 7 Aug 2008 20:13:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F27F43A69E0; Thu, 7 Aug 2008 20:12:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KRIIt-000KEQ-JL for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:06:11 +0000
Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <duane@e164.org>) id 1KRIIp-000KA2-En for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:06:09 +0000
Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id CF906FF26C; Fri, 8 Aug 2008 13:05:26 +1000 (EST)
Message-ID: <489BB7F0.4040500@e164.org>
Date: Fri, 08 Aug 2008 13:05:20 +1000
From: Duane <duane@e164.org>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Paul Vixie <vixie@isc.org>
CC: Olaf Kolkman <olaf@NLnetLabs.nl>, bert hubert <bert.hubert@netherlabs.nl>, Namedroppers <namedroppers@ops.ietf.org>
Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS
References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <F153E1C5-6E05-475A-897D-471398D161C9@NLnetLabs.nl> <489B9B48.4090605@e164.org> <28119.1218160261@nsa.vix.com>
In-Reply-To: <28119.1218160261@nsa.vix.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

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.

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.

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.

-- 

Best regards,
 Duane

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