Re: [dnsext] Practically secure DNS

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 24 October 2011 23:56 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69CA11E8162; Mon, 24 Oct 2011 16:56:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319500585; bh=rel320cnzukiniFuEtujgaUgnTNwAG2WmZsmJ6sKzak=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=f5rrUhellDhEWp1HLkopy9wdY+LjVjsyW+/iJo/3wPtMtrTo3Bi3UlVe4JgBekGRa q4fhpCpA3C1xZTLPxuyNiRYbWtaSIdbydy3Uz/vcLbpjG83k9vieY5qLZETtl3sT5W kT3HMXfkkWsqpC/eUoGxZ9rAiY0fl8CyiW/UzRRo=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D486A11E8162 for <dnsext@ietfa.amsl.com>; Mon, 24 Oct 2011 16:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV74Kyjk+lEe for <dnsext@ietfa.amsl.com>; Mon, 24 Oct 2011 16:56:24 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id A69B721F8B72 for <dnsext@ietf.org>; Mon, 24 Oct 2011 16:56:23 -0700 (PDT)
Received: (qmail 66164 invoked from network); 25 Oct 2011 00:17:19 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 25 Oct 2011 00:17:19 -0000
Message-ID: <4EA5FB3D.20509@necom830.hpcl.titech.ac.jp>
Date: Tue, 25 Oct 2011 08:56:45 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: dnsext@ietf.org
References: <20111009135505.GA85221@shinkuro.com> <CACU5sD=-pJUVKG1QmwBX9d-MZJp6_AYkXWDxh_CTAXO=x7+Juw@mail.gmail.com> <20111010051725.3A95214E5206@drugs.dv.isc.org> <CACU5sDnd49zbLxqLFOebFfm6UqJ7qZiQuCqY4DeEA4rHiia8GQ@mail.gmail.com> <20111010220027.F1E2614EB649@drugs.dv.isc.org> <4E9C2413.3030000@nlnetlabs.nl> <20111017134650.816981569E8F@drugs.dv.isc.org> <20111017140437.GA7743@shinkuro.com> <20111018014221.C0E871578C86@drugs.dv.isc.org> <20111018040429.GM7743@shinkuro.com> <20111018054252.1EF21157D5EB@drugs.dv.isc.org> <4E9D1FA2.5020608@necom830.hpcl.titech.ac.jp> <4E9D6BAC.7000100@gis.net> <4E9D8459.1030707@necom830.hpcl.titech.ac.jp> <sjm7h42z8p3.fsf@mocana.ihtfp.org> <4E9E140D.8040803@necom830.hpcl.titech.ac.jp> <20111019015410.5AA45158826F@drugs.dv.isc.org> <4E9EDDE3.3050302@necom830.hpcl.titech.ac.jp> <4EA5329D.8050607@necom830.hpcl.titech.ac.jp> <02C8B7BF-7C6F-4BC2-9A40-2EC087895F58@hopcount.ca> <alpine.DEB.2.00.1110240940230.9077@mail.xelerance.com>
In-Reply-To: <alpine.DEB.2.00.1110240940230.9077@mail.xelerance.com>
Subject: Re: [dnsext] Practically secure DNS
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Paul Wouters wrote:

> Isn't all of this already proposed in 
> http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01 

Which one?

> It also totally ignores the fact that if all involved name servers are 
> "secure" (definition unknown) but

SDNS also totally ignores the fact that SDNS with automatic servers
for clients to modify domain information is not secure if related
servers are not secure.

> the traffic path is not,

SDNS with automatic servers for clients to modify domain
information with password confirmation is not secure if the
traffic path is not secure.

> the "secure" client is still going to take
> rewritten replies. Eg this draft
> does not even handle the "starbucks wifi" scenario or any transparent
> DNS proxy scenario.

SDNS also ignores the fact that secure time is practically
impossible to obtain within certain private networks.

						Masataka Ohta
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext