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