Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

Dave Crocker <> Wed, 18 July 2018 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26389130F18 for <>; Wed, 18 Jul 2018 09:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DOhZopmGh_Il for <>; Wed, 18 Jul 2018 09:50:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64D03130DF1 for <>; Wed, 18 Jul 2018 09:50:31 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w6IGr4P4005857 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 09:53:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1531932784; bh=fj9ZsS4s6sOp0zIlXORFjDsLvM/L5uIO/6qkGEDF1jI=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=Xcy5kCy6tnTvfPbfmVSOTqtks8tZ6nXG3PhceqygBJKAvxzzsKYMqZYPHIOhfSzpv pn30p4mvaA2b0ePw2AQXYkNa5KEiIb3JzoM//B9uWkDX6H0hXpiXFdK8IJJfNYL/OT wGp74d28nvuWQn28fU9dbhXGEFzsgv1eirnvIfag=
To: "Murray S. Kucherawy" <>
References: <> <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Wed, 18 Jul 2018 09:50:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2018 16:50:36 -0000

On 7/18/2018 9:28 AM, Murray S. Kucherawy wrote:
> On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker < 
> <>> wrote:
>     Folks,
>     I'm responding to Murray's impressive proofreading details offlist,
>     but there are some points he raises that might need wg discussion:
> Aw shucks.
>         COMMENT:
>         The text specifically calls for a stable reference. Do we have
>         guidance about what constitutes such a thing? I believe IANA has
>         its own guidelines to that end; are they available to the
>         Designated Expert?
>     I'm inclined to let IANA raise this if they see and issue and then
>     let them drive the resolution of this point.
> Yeah, I don't have the right answer either, but I'm concerned that we're 
> asking the DE to make a decision with guidelines she doesn't have (or 
> worse, come up with some that are not consistent with what IANA usually 
> does).
>         Section 6:
>         COMMENT:
>         I have doubts that SECDIR would accept this one-sentence
>         comment. I suggest saying something more specific, like:
>         "This document establishes a registry, and encourages a slight
>         reorganization of attributes stored in the DNS. It establishes
>         no new security issues."
>     The first clause is redundant and makes sense to have here only
>     either if the readers of this section haven't read the rest of the
>     document, or if the clause is useful to what follows.  I believe
>     neither applies here.
> I imagine myself as a SECDIR reviewer, and believe this would be the 
> first section I would read for any document to which I'm assigned.  
> Discovering there a sentence that basically says "None" would get my 
> back up ("We'll see about that!").
> More generally, I have had success with my proposed tactic in the past, 
> so I thought I'd suggest it here.

I've gotten decreasingly tolerant of using gambits in a specification 
document, in order to maneuver through the process. I think the document 
should say what it needs to to do its job and not have material that is 
primarily for appeasement those in charge.  Gambits add cruft, and often 
mislead the reader into thinking there is substance when there isn't.

(I think I hit my limit when we appeased an AD for KIM and added the 
requirement for the DKIM signature cover the From: field, thereby aiding 
in community misunderstanding of what DKIM does.)

If the suggested change had any actual substance with respect to 
security issues, that would be quite a different matter.  But it doesn't.

Obviously if the wg would prefer different language, we'll use it...

>     I don't understand the 'encourages' statement but suspect I don't agree.
> Reading the document, I got the impression that in your research you 
> discovered some underscore names that don't quite follow the proposed 
> placement.  If my inference is wrong, then so is that clause.

sorry, but apparently something is getting in the way of my 
understanding this issue.  Now I'm confused about the 'placement' 

Anyhow, the only problematic, existing specs, I think, are the SRV and 
URI documents, because they create naming complexities that invite 
problems.  Especially the two-source approach that the URI spec has.


Dave Crocker
Brandenburg InternetWorking