Re: [dnsext] Trustworthiness of DNSSEC data
=JeffH <Jeff.Hodges@KingsMountain.com> Mon, 27 June 2011 01:23 UTC
Return-Path: <Jeff.Hodges@KingsMountain.com>
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 C7E4811E8087 for <dnsext@ietfa.amsl.com>; Sun, 26 Jun 2011 18:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.665
X-Spam-Level:
X-Spam-Status: No, score=-99.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm+y4l0ad3ZY for <dnsext@ietfa.amsl.com>; Sun, 26 Jun 2011 18:23:10 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 55E6211E808B for <dnsext@ietf.org>; Sun, 26 Jun 2011 18:23:10 -0700 (PDT)
Received: (qmail 29929 invoked by uid 0); 27 Jun 2011 00:14:54 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 27 Jun 2011 00:14:54 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=5taezRh/KotjD0saaOkbt20rCazXpxcks1jMvUYofiugAzhIT5iU5HDI5OyRyW/hWVaGXUU8/dIcbIARebo6U1AZzstIoYrgzr2iwB9RAqT2tpM8ey1qMdI6f+0fBLaZ;
Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1QazTa-0005te-Bc; Sun, 26 Jun 2011 18:14:54 -0600
Message-ID: <4E07CB7C.9000009@KingsMountain.com>
Date: Sun, 26 Jun 2011 17:14:52 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: dnsext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: dane <dane@ietf.org>
Subject: Re: [dnsext] Trustworthiness of DNSSEC data
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>
X-List-Received-Date: Mon, 27 Jun 2011 01:23:11 -0000
> More generally, DNSSEC holds > enormous potential utility as a repository of integrity-protected > authoritative information about DNS names, including configuration for > new opt-in security schemes. However, each of these schemes may > increase the degree of exposure to malfeasance by the DNS operator (who > may not be the same entity as the authoritative holder of the domain) in > some or all cases, compared to traditional practice. Not to say that having these concerns is misplaced, but the DNSop WG, as well as various DNS operators, have been thinking along these lines... http://tools.ietf.org/wg/dnsop/ "DPS" = DNSSEC Practice Statement ..perhaps further discussion should go to the dnsop@ietf.org list? There's also: Dnssec-deployment@dnssec-deployment.org HTH, =JeffH --- DNSSEC Operational Practices, Version 2 http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis Abstract This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. --- DNSSEC Policy & Practice Statement Framework http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework Abstract This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. -- DPS framework (slides) <http://brussels38.icann.org/meetings/brussels2010/presentation-dnssec-dps-framework-ljunggren-23jun10-en.pdf> DNSSEC in Sweden: Five Years of Practical Experience (slides) <http://www.gc-sec.org/Events/Documents/AnneMarie%20Amel-2010-06-Rome-DNSSEC-workshop.pdf> Root DNSSEC docs ---------------- Root DNSSEC - documentation (many documents) http://www.root-dnssec.org/documentation/ IANA DNSSEC Information https://www.iana.org/dnssec/ Individual DPSs --------------- DNSSEC Practice Statement for the Root Zone KSK Operator https://www.iana.org/dnssec/icann-dps.txt Verisign DNSSEC Practice Statements (.net, .edu, Signing Services, root zone ZSK operator) https://verisigninc.com/en_US/repository/index.xhtml RIPE DNSSEC Policy and Practice Statement http://www.ripe.net/rs/reverse/dnssec/dps.html DNSSEC Practice Statement (DPS) -- .se http://www.iis.se/docs/se-dnssec-dps-eng.pdf DNSSEC Practice Statement for the JP Zone (JP DPS) https://jprs.jp/doc/dnssec/jp-dps-eng.html --- end
- Re: [dnsext] Trustworthiness of DNSSEC data Matt McCutchen
- Re: [dnsext] Trustworthiness of DNSSEC data Matt McCutchen
- [dnsext] Trustworthiness of DNSSEC data Matt McCutchen
- Re: [dnsext] Trustworthiness of DNSSEC data John Levine
- Re: [dnsext] Trustworthiness of DNSSEC data Phil Regnauld
- Re: [dnsext] Trustworthiness of DNSSEC data Matt McCutchen
- Re: [dnsext] Trustworthiness of DNSSEC data Matt McCutchen
- Re: [dnsext] Trustworthiness of DNSSEC data John R. Levine
- Re: [dnsext] Trustworthiness of DNSSEC data John R. Levine
- Re: [dnsext] Trustworthiness of DNSSEC data =JeffH
- Re: [dnsext] Trustworthiness of DNSSEC data Patrik Fältström
- Re: [dnsext] Trustworthiness of DNSSEC data Patrik Fältström
- Re: [dnsext] Trustworthiness of DNSSEC data Paul Vixie
- Re: [dnsext] Trustworthiness of DNSSEC data John Levine
- Re: [dnsext] Trustworthiness of DNSSEC data Patrik Fältström
- Re: [dnsext] Trustworthiness of DNSSEC data Florian Weimer
- Re: [dnsext] Trustworthiness of DNSSEC data Florian Weimer
- [dnsext] (Client deployment of DANE positive asse… Matt McCutchen
- Re: [dnsext] [dane] Trustworthiness of DNSSEC data Richard L. Barnes
- Re: [dnsext] (Client deployment of DANE positive … Phillip Hallam-Baker
- Re: [dnsext] Trustworthiness of DNSSEC data Masataka Ohta
- Re: [dnsext] [dane] Trustworthiness of DNSSEC data Peter Gutmann
- Re: [dnsext] Trustworthiness of DNSSEC data Phillip Hallam-Baker
- Re: [dnsext] Trustworthiness of DNSSEC data Masataka Ohta