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

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Mar 2011 13:33:51 -0500

Just to be clear here, what is being proposed here is the version of the
specification described in the -02 version of the draft which was simplified
in response to feedback from the list.

In particular we removed a feature from the previous version of the
specification that allowed a single CAA RR to contain a list of property
entries. That was considered to be confusing

Looking through the draft, there is a typo where some text in 3.1 seems to
have escaped this change and may be the source of confusion.

The CAA data field consists of a sequence of at least one property entry.
 Each property entry consists of a sequence of:

This should read.

The CAA data field contains one property entry.  A property entry consists
of a sequence of:

I also note that I did not do a block diagram of the data section. This
should be

+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags          | Tag Length = n |
+----------------+----------------+...+---------------+
| Tag char 0     | Tag Char 1     |...| Tag Char n    |
+----------------+----------------+...+---------------+
| Data byte 0    | Data byte 1    |...| Data byte m   |
+----------------+----------------+...+---------------+

Where n is the length specified in the tag length field and m is the
remaining octets in the data field (m = l - n - 2) where l is the length of
the data section.

I will make these corrections to the editing copy of the draft.

This does not change the intended semantics of the proposal.

On Fri, Feb 18, 2011 at 4:34 PM, Frederico A C Neves <[email-masked]>wrote:

> Dear Colleagues,
>
> Bellow is a completed template requesting a new RRTYPE assignment
> under the procedures of RFC5395.
>
> This message starts a 3 weeks period for an expert-review of the DNS
> RRTYPE parameter allocation for CAA specified in
> http://tools.ietf.org/html/draft-hallambaker-donotissue-02
> IANA #412190
>
> If you have comments regarding this request please post them here
> before Mar 11th 18:00 UTC.
>
> Best Regards,
> Frederico Neves
>
> --begin 5395 template CAA--
>  A.    Submission Date: 3 Dec 2010
>
>  B.    Submission Type:
>        [X] New RRTYPE
>        [ ] Modification to existing RRTYPE
>
>  C.    Contact Information for submitter:
>           Name: Phillip Hallam-Baker
>           Email Address: [email-masked]
>           International telephone number: +1 617 395 4123
>           Other contact handles:
>
>           (Note: This information will be publicly posted.)
>
>  D.    Motivation for the new RRTYPE application?
>        Please keep this part at a high level to inform the Expert and
>        reviewers about uses of the RRTYPE.  Remember most reviewers
>        will be DNS experts that may have limited knowledge of your
>        application space.
>
>  The Certification Authority Authorization (CAA) DNS Resource Record
>  allows a DNS domain name holder to specify the certificate signing
>  certificate(s) authorized to issue certificates for that domain.  CAA
>  resource records allow a public Certification Authority to implement
>  additional controls to reduce the risk of unintended certificate mis-
>  issue. And is designed to be extensible in order to support related
>  concerns including enforcement of issue restriction in applications.
>
>  E.    Description of the proposed RR type.
>        This description can be provided in-line in the template, as an
>        attachment, or with a publicly available URL:
>
> A detailed specification is posted is given in
> draft-hallambaker-donotissue:
>
> https://datatracker.ietf.org/doc/draft-hallambaker-donotissue/
>
>
>  F.    What existing RRTYPE or RRTYPEs come closest to filling that
>        need and why are they unsatisfactory?
>
> The only current means by which this information can be expressed
> in the DNS is via a TXT record which is not differentiated for this
> purpose.
>
> The approach here addfresses purposes that are clearly outside
> the purpose of the CERT record and similar 'keys-in-DNS'
> approaches.
>
>
>  G.    What mnemonic is requested for the new RRTYPE (optional)?
>        Note: This can be left blank and the mnemonic decided after the
>        template is accepted.
>
> The proposed mnemonic is CAA standing for Certification Authority
> Authorization.
>
>  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?
>
>        If so, please indicate which registry is to be used or created.
>        If a new sub-registry is needed, specify the allocation policy
>        for it and its initial contents.  Also include what the
>        modification procedures will be.
>
> 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:
>
>             Meaning                                          Reference
>  -----------  -----------------------------------------------  ---------
>  path         Authorization Entry by Signature Path            [RFCXXXX]
>  policy       Authorization Entry by Certificate Policy        [RFCXXXX]
>
>  Addition of tag identifiers requires a public specification and
>  expert review as set out in RFC5395 [RFC5395]
>
> Note that information carried in this record addresses application
> layer concerns. As such it is highly desirable to employ a tag-value
> approach to attribute specification than the code-value approach that
> is employed at lower layers in the stack.
>
>  I.    Does the proposal require/expect any changes in DNS
>        servers/resolvers that prevent the new type from being
>        processed as an unknown RRTYPE (see [RFC3597])?
>
> No.
>
>  J.    Comments:
>
> While the CAA proposal made in the accompanying Internet Draft
> represents a complete technical proposal, development of a full CAA
> standard will require further work that cannot be begun until a DNS RR
> assignment is made.
>
> In particular the CAA proposal MAY be proposed as the basis of future
> minimum issue guidelines for Domain Validated Certificates published
> by CA-Browser Forum. It is hard to see how such a proposal could be
> made without first obtaining significant experience of enforcing CAA
> issue restrictions.
>
> The CAA proposal MAY also be relevant to ongoing work in the IETF
> Applications area (WEBSEC) and the security area (TLS, IPSEC, Proposed
> KIDNS).
>
> Given the large number of moving parts, the proposal has been crafted
> with the intention of minimizing the number of dependencies in the
> system.
> --end 5395 template CAA--
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Mar 2011 14:44:12 -0500

Hi,

With my administrative hat on, I just want to clear up some details.

> entries. That was considered to be confusing

Is that a change to the definition of the RR?  I.e. is there a
difference between the RRTYPE in the original template and the one in
the latest draft?  If so, it's strictly speaking a new RRTYPE request
and it needs a different template.  The RRTYPE code that you get is
for the particular definition.  There isn't a mechanism so far to get
a number and then be able to change the RRTYPE substantively, because
the idea is that the typecode could be baked into software all over
the place.

> I will make these corrections to the editing copy of the draft.

It would be good, actually, if you could post an update.  The review
requirements include these criteria for rejection:

   1. Was documented in a manner that was not sufficiently clear to
      evaluate or implement.

   3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete.
      (Additional documentation can be provided during the public
      comment period or by the Expert.)

The block diagram in particular would be helpful.
 
> This does not change the intended semantics of the proposal.

The Expert isn't reviewing the semantics of the protocol, so that
doesn't matter.  The expert is simply reviewing whether the RRTYPE
assignment meets the criteria for assignment.  These are pretty broad,
but the filters are important for interoperability and therefore we
need to follow them stringently.  It would help, of course, if I also
followed the procedures stringently and ensured the reviews got done
on time.  I'm not trying to be super bureaucratic here.  But if
there's a change to the RRTYPE as requested, it's important to know
that.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Mar 2011 15:32:27 -0500

> the idea is that the typecode could be baked into software all over

The change took place in the -02 version of the draft that is specified in
the template.

I have submitted a new -03 version of the draft that clarify the description
of the RRTYPE but do not change the proposal from that described in -02.

> requirements include these criteria for rejection:

http://www.ietf.org/id/draft-hallambaker-donotissue-03.txt

> The block diagram in particular would be helpful.

The -03 draft provides additional documentation but does not modify the -02
RRTYPE definition submitted in January.

The template does not specify the version number of the draft.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Mar 2011 15:39:26 -0500

> of the RRTYPE but do not change the proposal from that described in -02.

Gotcha.  Thanks.  Sorry I was confused.
 
> The template does not specify the version number of the draft.

Excellent.  Very helpful.  Thanks!

A

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 10 Mar 2011 07:55:08 -0500 (EST)

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?

>        Registry or require the creation of a new IANA sub-registry in
...
> Yes, the following registry assignment is requested.
...
> Authorization Properties registry with the following initial values:
...
>  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.

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.

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.

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.

-- Sam

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Mar 2011 09:18:16 -0500

On Thu, Mar 10, 2011 at 7:55 AM, Samuel Weiler <[email-masked]> wrote:

> 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.

> 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.

> 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.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 10 Mar 2011 12:08:22 -0500 (EST)

> Thats a process issue outside my scope :-)

Heh.  Indeed.  :-)

>       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.
> 
...
> 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.

I'm sensitive to the "we don't want to start over from square one". I 
also want to be able to point to a firm "here's the definition of the 
RRTYPE" document.  And I'm concerned that your use of the "Expert 
Review" IANA assignment metric is underspecified in this case.

I was suggesting you take the IANA registry bits out of the draft (for 
now), point to a static-list version of the draft for purposes of 
RRTYPE assignment, and later create a registry for that field (in a 
subsequent revision of the i-d, as it gets closer to publication).

I suppose that's inconsistent, in some ways, with wanting a static 
specification, but it highlights my desire to nail down particular 
version of the i-d which is the definition.

Two alternate ideas are below.

> 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.
> 

You can still do that: 5395 specifically recognizes that RFC can 
allocate RRTYPES (with no template), including using the RFC420 early 
allocation process.  It sounds like that might be appropriate here, 
since you plan to publish as an RFC -- skip the template and ask for 
an early allocation.

Another idea: change the IANA assignment metric to one of the more 
thoroughly defined ones like "First Come First Served" or "RFC 
Required".  Those get you away from needing to tell the expert what to 
look for, though with First Come First Served you still should put 
restrictions on the tag field (max length 15 and only numbers and 
lowercase letters, consistent with section 3.1 of the draft).  You can 
easily change that assignment metric later.

>       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 of it more from the "let's make sure the record is clear" 
perspective.  In two years, how will I know which version of the 
document is the one that defined this RRTYPE?

-- Sam

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Mar 2011 14:52:11 -0500

On Thu, Mar 10, 2011 at 12:08 PM, Samuel Weiler <[email-masked]> wrote:

>> Resubmit the specificcation with no IANA registry
>> requires the template to specify the registries the draft proposes to
>> create.
>>
>
> I'm sensitive to the "we don't want to start over from square one". I also
> want to be able to point to a firm "here's the definition of the RRTYPE"
> document.  And I'm concerned that your use of the "Expert Review" IANA
> assignment metric is underspecified in this case.
>
> now), point to a static-list version of the draft for purposes of RRTYPE
> assignment, and later create a registry for that field (in a subsequent
> revision of the i-d, as it gets closer to publication).
>
> specification, but it highlights my desire to nail down particular version
> of the i-d which is the definition.
>
>  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.
>>
> You can still do that: 5395 specifically recognizes that RFC can allocate
> RRTYPES (with no template), including using the RFC420 early allocation
> process.  It sounds like that might be appropriate here, since you plan to
> publish as an RFC -- skip the template and ask for an early allocation.
>
> thoroughly defined ones like "First Come First Served" or "RFC Required".
>  Those get you away from needing to tell the expert what to look for, though
> with First Come First Served you still should put restrictions on the tag
> field (max length 15 and only numbers and lowercase letters, consistent with
> section 3.1 of the draft).  You can easily change that assignment metric
> later.

Given the size of the tag space, I think either alternative is acceptable as
they will converge on the same effect: Anyone can define a new tag with
minimal risk of collision but it is rather unlikely that tags will be widely
supported or recognized unless they are described in an RFC somewhere.

I suggest RFC required.

>> 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.
>>
> perspective.  In two years, how will I know which version of the document is
> the one that defined this RRTYPE?
>

Well the hope would be that we replace the document with a published RFC by
then.

Now in theory the draft could change in ways that are incompatible with the
wire format proposed here, but if that happens then either there will have
to be a new RR code issued or the RFC should probably not be published.

I really want to get this nailed down much sooner because getting the wire
format settled and set in concrete is a pre-condition to discussing the
lawyer stuff in CABForum.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Mar 2011 15:07:48 -0500

Dear colleagues,

I write as the locally-appointed pointy-hair on this subject.  I am
not the appointed Expert, please note.

On Thu, Mar 10, 2011 at 07:55:08AM -0500, Samuel Weiler wrote:
>
> Is it really appropriate to allow a template to create IANA registries?  

The template does not actually leave open the possibility of creating
an entirely new registry, but it does permit "the creation of a new
IANA sub-registry in DNS Parameters?"  I've always found this a little
odd, but RFC 5395 does not list this as a reason to reject the
application.  RFC 5395, on my reading, defaults to permissive: as long
as section 3.1.1 criteria 1 and 2 are met, then the application should
go ahead so long as it does not meet any of the criteria under section
3.1.2.  Therefore, I see no reason that subregistries to DNS
Parameters can not be created along with an RRTYPE.

The registration rules are what make this a little funny.  But the
template does not require us to specify the registration rules for the
subregistry, and RFC 5395 is similarly silent.  I think any I-D that
actually specifies the RRTYPE and its use should, in the end, also
contain rules for the registration in the subregistry.  But I am not
at all sure that the registry's rules need to be specified at its
creation.  (I wouldn't be surprised to learn I am wrong about this; if
so, I'd like a reference to the rules.)

> It might be appropriate to skip the IANA registry for the moment.  

If the RRTYPE requires a subregistry, then the subregistry is not
optional; that would make the template incomplete.

> should really be citing a particular version of the spec.

I don't believe it should, and I don't think that would be desirable.

There are two reasons for that.

First, the template says this:

The publicly-available URL might well track changes to the use of the
RRTYPE.  As long as the use does not violate any of the rules, even if
the use changes slightly, that appears to be allowable.  

Moreover, section 3.1.2 of RFC 5395 appears explicitly to allow
changing documentation:

Finally, the template has room for the case where an existing RRTYPE
(presumably, one assigned early on in the review process) is altered:

   B.    Submission Type:
         [ ] New RRTYPE

This suggests that the WG was prepared for the possibility that
RRTYPEs would change slightly in the time between initial conception
and assignment, and between assignment and final publication.  Small
communities of users of an RRTYPE can presumably be expected to
tolerate incompatible changes shortly after assignment, when all the
implementations in the world are still being used by the developers
and nobody else.

Best regards,

Andrew

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Thu, 10 Mar 2011 20:10:30 +0000

Hi,

> published as an RFC.  Perhaps IANA should comment on that.

Requests to create registries should be published in an RFC. 

thanks,

Amanda Baber
IANA

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Mar 2011 13:05:31 -0800

> I don't believe it should, and I don't think that would be desirable.

+1 to Andrew's response and analysis. It is pretty inexcusable to have 
an IETF-vetted BCP that says how this registry is populated, and then 
say "we didn't really mean that, we want to be more restrictive". If you 
really want to have that much control over the registry, please write 
rfc5395bis and see if others agree.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Mar 2011 16:10:23 -0500

> Requests to create registries should be published in an RFC. 

Creating a completely new registry, yes.  But since the template in
RFC 5395 explicitly asks whether a new sub-registry to DNS Parameters,
surely such a sub-registry can be created as part of the creation of
the RRTYPE, no?  Otherwise, that ought to be called out as one of the
reasons not to approve the RRTYPE, no?

Best,

Andrew