Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym

"Jim Schaad" <ietf@augustcellars.com> Sun, 06 October 2013 21:40 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57D11E8141 for <dane@ietfa.amsl.com>; Sun, 6 Oct 2013 14:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 AMJIVJwDYbxE for <dane@ietfa.amsl.com>; Sun, 6 Oct 2013 14:40:07 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3E11E8137 for <dane@ietf.org>; Sun, 6 Oct 2013 14:40:05 -0700 (PDT)
Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7AC092C9E7 for <dane@ietf.org>; Sun, 6 Oct 2013 14:40:05 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: dane@ietf.org
References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <EACEEB05-2023-4F76-A6FE-A9B2FDC0AA59@kumari.net>
In-Reply-To: <EACEEB05-2023-4F76-A6FE-A9B2FDC0AA59@kumari.net>
Date: Sun, 06 Oct 2013 14:38:50 -0700
Message-ID: <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ39s23NI8MTM4J4gsDf6CIX3S72AH+2eVVmIXMaBA=
Content-Language: en-us
Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Oct 2013 21:40:13 -0000

Sorry for being late on getting this in.

 1.  I do not understand the reasoning behind the 2119 language in the
introduction.  How would one test this in a protocol fashion?   The document
states that it does not change DANE in anyway, but there are requirement
language statements that can be made?  This should be stated in  natural
language not requirement language.  Section 1.1 can them be removed in its
entirety.

It is expected that DANE parsers in applications and DNS software will adopt
these acronyms for parsing and display purposes, however there are no
requirements that they do so.

 2.  In section 2, it states that the references should be both RFC 6698 and
this document, however that is not the way that the tables starting in
section 2.1 are laid out.  They only use RFC 6698 as a reference document.

3 s/input>/input./

4.  I don't think that this phrase "fewer bad TLSA records" is very helpful.
What is meant by a bad TLSA record?  Is this just ones where the fields were
put out of order or does it include ones where the certificate is
incorrectly hashed?  If the goal is to avoid issues with the certificates
and what is extracted, then doing something about what goes into the blob
would make sense as well.  I would agree that specifying how this would be
done is out of scope, but noting it as an issue would be reasonable.

5.  As I have stated before, I am not a fan of using DANE-TA for value 2.
To me this loses the fact that there will be PKIX processing that occurs
with this section.  I would strongly recommend that this become PKIX-TA.
The use of PKIX-TA for the value of 0 never made any sense since there is
not trust anchor decision that is associated with the certificate in this
record.  The only two records currently that have a trust anchor, as oppose
to a constraint, component are 2 and 3. 

6.  The note component at the end of section 2.1 should be deleted.

7.  In section 3, the descriptive text and the example records do not match
in very significant ways.

Jim