Re: [dnsext] [reed@reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18]

Samuel Weiler <weiler@watson.org> Fri, 18 May 2012 11: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 197D121F869D; Fri, 18 May 2012 04:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1337342217; bh=cBwEcbW0lBLBHSaSasJ5BDR0T72K3Gi4sL7ficsRfgM=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=RkJngcGk99HCEgPAy0DiBFSgiuGw89hz/XXsVFLdLIkL4H4xlrzyhp7myhqdIakiR dSG01TpzQdx7HCdiQiwHxU37PlAKjp9dew6kzcQPrb8lvh9p/i5ItuS5nanBA/xyfm Tc07ZcTLTlO2AMjElrY9jXg3hnfQjcOVmw7KSvBM=
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 0A34D21F869D for <dnsext@ietfa.amsl.com>; Fri, 18 May 2012 04:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599]
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 wMHrrAOhDw3f for <dnsext@ietfa.amsl.com>; Fri, 18 May 2012 04:56:55 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5628121F8686 for <dnsext@ietf.org>; Fri, 18 May 2012 04:56:54 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4IBursE085591; Fri, 18 May 2012 07:56:53 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4IBuq7a085588; Fri, 18 May 2012 07:56:53 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 18 May 2012 07:56:52 -0400
From: Samuel Weiler <weiler@watson.org>
To: "Jeremy C. Reed" <reed@reedmedia.net>
In-Reply-To: <20120507175312.GL8963@mail.yitter.info>
Message-ID: <alpine.BSF.2.00.1205180720340.66835@fledge.watson.org>
References: <20120507175312.GL8963@mail.yitter.info>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 18 May 2012 07:56:53 -0400 (EDT)
Cc: dnsext@ietf.org
Subject: Re: [dnsext] [reed@reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Thank you for these comments.  I've proposed some textual changes to 
address these.  Assuming there's not objection, these will be pushed 
out after the IETF LC ends.

> 4.3.  Check for CNAME
>
>   Section 5 of [RFC4035] says little about validating responses based
>   on (or that should be based on) CNAMEs.
>
> * The wording above is confusing or misleading. RFC 4035 Section 5 says
> nothing about CNAME specifically.

Good catch.  I propose changing to "...says nothing explicit about 
validating responses based on ..."

> 5.3.  Private Algorithms
>
> ...
>
>   In the remaining cases, the security status of the zone depends on
>   whether or not the resolver supports any of the private algorithms in
>   use (provided that these DS records use supported hash functions, as
>   discussed in Section 5.2).
>
> * This may be confusing since the draft's section 5.2 matches up with
> numbering of RFC 4035's Section 5.2 and the draft's 5.2 does not use the
> terminology "hash functions".

I propose: "(provided that these DS records use supported message 
digest algorithms, as discussed in Section 5.2 of this document)".

> 5.6.  Setting the DO Bit on Replies
>
> * Mention is is Section 3.

Done.

> 5.7.  Setting the AD Bit on Queries
>
> The use of the AD bit in the query was previously undefined.
>
> * It was defined for queries. See RFC 4035 4.6: ``A security-aware
> resolver MUST clear the AD bit when composing query messages to protect
> against buggy name servers that blindly copy header bits that they do
> not understand from the query message to the response message.''

What to do with it was defined, but there was no "use" for it.  Even 
so, this is a little unclear.  I propose:

        The semantics of the AD bit in the query were previously
        undefined.  Section 4.6 of RFC4035 instructed
        resolvers to always clear the AD bit when composing
        queries.  This document defines setting the AD bit in a
        query...

> 6.1.  Finding Zone Cuts
>
> * What are the "special rules" and "special processing rules"?  The
> wording is unclear if these are the rules defined in RFC 4035 3.1.4.1 or
> if they are new special rules.  In other words, what is the minor
> correction or clarification here?

There isn't one.  This is just restating something that should be 
obvious.  I don't even remember what inspired including this section 
-- it dates from the pre-WG draft, which started over seven(!) years 
ago.

It might be better to just take this out.  For the moment, I propose 
trimming the section to:

 	Appendix C.8 of RFC4035 discusses sending
 	DS queries to the servers for a parent zone but doesn't say
 	how to find those servers.  Specific instructions can be
 	found in Section 4.2 of RFC4035.

> Appendix B.  Discussion of Setting the CD Bit
>
> * Maybe mention "(server failure)" in first mention of RCODE=2.

Done.

> * Also be consistent with referring to RFC numbers, maybe always use
> brackets around them every time.

I changed the 4035 reference at the top of Appendix B.  I'll try to 
look for others later.

-- Sam


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