Re: [DNSOP] Practical issues deploying DNSSEC into the home.

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 12 September 2013 20:56 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0848911E8210 for <ietf@ietfa.amsl.com>; Thu, 12 Sep 2013 13:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.015
X-Spam-Level:
X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=0.075, 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 jFEnier1foca for <ietf@ietfa.amsl.com>; Thu, 12 Sep 2013 13:56:47 -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 61E7511E80AD for <ietf@ietf.org>; Thu, 12 Sep 2013 13:56:42 -0700 (PDT)
Received: (qmail 76262 invoked from network); 12 Sep 2013 20:51:31 -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; 12 Sep 2013 20:51:31 -0000
Message-ID: <523229E2.20704@necom830.hpcl.titech.ac.jp>
Date: Fri, 13 Sep 2013 05:53:54 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.
References: <CAGhGL2APj-XfuMUHgLsELnZRbRNCLrjMBxFBtcg4zx+5SG7Bag@mail.gmail.com> <3C96E4A9-7E78-421F-A437-7091AEBEB5AA@ogud.com> <20130910224518.GA99190@isc.org> <91AFF488-A3F6-4E30-B542-B5C107DB6114@ogud.com> <CAMm+LwjkOEO6t5v6qMjc036JGaoFi=3jFPNDp=xM=zK5R8_k7A@mail.gmail.com> <D9B745AC-8FCE-4742-AAE1-CC1AC4293F0E@hopcount.ca> <alpine.LFD.2.10.1309111202350.13632@bofh.nohats.ca> <CAMm+LwieYmZNUybCgpdkytb9EfmiraTVNJdTUS6aeNJE5=8PEQ@mail.gmail.com> <F4F9D8B4-57BF-4CB4-A200-3B77A3966A2B@icsi.berkeley.edu> <CAMm+LwjTGZz9BrE1EcuQb9abv+MvOPVTjWHiSBCj774drnF15A@mail.gmail.com> <20130912112400.GB12918@thunk.org> <F4C95731-8044-4B7B-AA93-A1D3E8D8DDDC@nominum.com>
In-Reply-To: <F4C95731-8044-4B7B-AA93-A1D3E8D8DDDC@nominum.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, "ietf@ietf.org TF" <ietf@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Evan Hunt <each@isc.org>, Theodore Ts'o <tytso@mit.edu>, Paul Wouters <paul@nohats.ca>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2013 20:57:10 -0000
X-List-Received-Date: Thu, 12 Sep 2013 20:57:10 -0000

Ted Lemon wrote:

> This isn't _quite_ true.   DNSSEC supports trust anchors at
> any point in the hierarchy, and indeed I think the right
>  model for DNSSEC is that you would install trust anchors
> for things you really care about, and manage them in the
> same way that you manage your root trust anchor.   E.g.,
> you'd install a trust anchor for your employer, and your
> bank, and maybe your local town government.   This is
>  all future UI work, of course.

Operationally, that's not practical. Users can't manage
their trust anchors securely.

> Furthermore, if the root key is compromised and that is then
> used to substitute a bogus key, it isn't that hard to notice
> that this has happened, and indeed we ought to be
> systematically noticing these things.   So hacking the root
> key is certainly a valid threat, but there is a great deal
> more transparency in the DNSSEC system than in the TLS PKI,
> and that should mean that the system is more robust in the
> face of this kind of attack.

According to your theory, we don't need DNSSEC, because
cache poisoning attacks on plain DNS is easily detectable.

						Masataka Ohta