Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th

Phillip Hallam-Baker <hallam@gmail.com> Thu, 10 March 2011 14:17 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536353A69B0 for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 06:17:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Level:
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x595lwXCV1bA for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 06:17:00 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E043F3A6996 for <dnsext@ietf.org>; Thu, 10 Mar 2011 06:16:59 -0800 (PST)
Received: by iwl42 with SMTP id 42so1998277iwl.31 for <dnsext@ietf.org>; Thu, 10 Mar 2011 06:18:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=brBVdgBT/1Ecg9Sh9Ptltkoe5m/jNKlUtc18lKPATt8=; b=UuKTQ5DYBUikJA1udrVMs3d+w5e/UH1W02ts3f6KTF+BaXwCvl60BPS2khRUBbE+ra lh/oK5Y6eYBlHYC849obxHgAPGezBEPq0QsRFKJexF0y3Akme4PxYRIn4KQFYb0RDrPF oKgWcC/CN+evb1fhuFxg5RF0uP33aPE+ALDJw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Srz/GXxO6zSwtUkdXJ92WBSQdz52dTcn0lxCo0bmezKxvSD8zv5cfec8q566kcwBRR jsNFC0PbZ4A7MvQX/uaehjjWRSCBQomKzH/R/+MlQdbZyLGzvAkMHX2pwmAPJvLZALRi Ze4hVVqtSysbv1H+HFhXXJWmONA58IOzyzynQ=
MIME-Version: 1.0
Received: by 10.42.108.9 with SMTP id f9mr940730icp.233.1299766696711; Thu, 10 Mar 2011 06:18:16 -0800 (PST)
Received: by 10.43.61.80 with HTTP; Thu, 10 Mar 2011 06:18:16 -0800 (PST)
In-Reply-To: <alpine.BSF.2.00.1103100742001.60284@fledge.watson.org>
References: <20110218213453.GB96163@registro.br> <alpine.BSF.2.00.1103100742001.60284@fledge.watson.org>
Date: Thu, 10 Mar 2011 09:18:16 -0500
Message-ID: <AANLkTimtO-UaJDt+RTdyE56TU-7++OPH55dc_9Xbg3VJ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Samuel Weiler <weiler@watson.org>
Content-Type: multipart/alternative; boundary="20cf303bff463f97c7049e2184a4"
Cc: iana@iana.org, dnsext@ietf.org
Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 10 Mar 2011 14:17:01 -0000

On Thu, Mar 10, 2011 at 7:55 AM, Samuel Weiler <weiler@watson.org> wrote:

> The presentation format definition says:
>   flags  Is an unsigned integer between 0 and 15.
>
> But the flags field on the wire is a full octet, and bit 0 is defined.
> Should the presentation format allow 0-255, instead


Oops, the statement in the Presentation Format is wrong.

We made the flags a full byte after comments received suggested we were
over-optimizing.



>
>
>   H.    Does the requested RRTYPE make use of any existing IANA
>>       Registry or require the creation of a new IANA sub-registry in
>>       DNS Parameters?
>>
> ...
>
>  Yes, the following registry assignment is requested.
>>
> ...
>
>> 5.2.  Certification Authority Authorization Properties
>>
>>  IANA [is requested to create] the Certification Authority
>> Authorization Properties registry with the following initial values:
>>
> ...
>
>   Addition of tag identifiers requires a public specification and
>>  expert review as set out in RFC5395 [RFC5395]
>>
>
> Is it really appropriate to allow a template to create IANA registries?  It
> does seem odd to me that a template can create an IANA registry when the i-d
> it cites can't itself create a registry until published as an RFC.  Perhaps
> IANA should comment on that.
>

Thats a process issue outside my scope :-)



> In any case, the cite to 5395 suggests that this is attempting to reuse the
> DNS RRTYPE expert pool for this registry, which seems odd. It also doesn't
> define the criteria an expert should use.  I suggest the proponents of this
> look at RFC5226 and specific their own criteria, perhaps with their own
> expert.
>

OK,

I see this as being the start of projects intended to make use of the
capabilities of DNSSEC to support application level issues. So I certainly
anticipate a need for a separate expert pool at some point. But not so far
as the scope of CAA alone is concerned.


It might be appropriate to skip the IANA registry for the moment. Resubmit
> the specificcation with no IANA registry ("here are the two values") and
> only create the registry in the RFC.
>

That would only change the template, not the draft?

I am trying to follow the process as I understand it here and that requires
the template to specify the registries the draft proposes to create.

Now what may well make more sense as a process would be to have a two phase
scheme in which DNS RR codes are marked 'reserved' in response to the expert
review and the final allocation is performed when the RFC is issued. This is
effectively what has happened with Stuart Cheshire's Bonjour scheme.

But that is not the process we have.



> Which brings us to the discussion on the list yesterday: the template
> should really be citing a particular version of the spec.  It hardly seems
> fair to ask the expert to approve an RRTYPE based on a reference to a
> changing document.
>

I think that is unhelpful.

The draft was changed in response to earlier review comments. I don't think
we want to have a process that encourages people to ignore comments lest
they incur a penalty of having to wait another 3 months.

Documents are changed after WG and even IETF last call all the time. I have
made rather more substantial changes in AUTH48. The test normally applied in
IETF is not 'has the text changed' but 'has the proposal changed'. The
process does allow for clarifications in the comment period.

We did change the wire format in January but this particular comment period
began 4 weeks later in Feb.

The point of a comment period is to give people an opportunity to influence
the proposal.


This particular proposal is different to most proposals that I have made in
that 1) the assignment is the only thing gating deployment and 2) the
mechanism provides an effective control over a very significant dollar risk.

In most cases deployment is gated on other people writing and distributing
code. Here the CA side of the proposal is entirely within the CA's control.

These mis-issue events are not frequent but when they do happen the results
go on for decades. It is now over a decade since the 2001 mis-issue took
place but I still hear about it in every public discussion of CAs followed
by an argument which taken to its logical conclusion would require the world
to immediately stop all forms of commercial shipping because the Titanic
sank almost a century ago.


-- 
Website: http://hallambaker.com/