Subject: [pkix] CAA record location / tree climbing

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Jul 2012 16:03:14 -0400

Dear colleagues,

Some time ago, I learned that CAA was coming over to PKIX for
continued work.  I thought to myself, "Gee, I oughta follow that," and
promptly forgot about it, which is why I haven't followed this.  My
apologies.

One of the ADs for the DNS directorate poked me the other day, and
asked whether I had read or commented on draft-ietf-pkix-caa.  I
hadn't, so I read it and commented on it, sending that review to the
AD in question as well as the authors.  For the sake of the record,
I'm including that entire review below, just so that people can see
it.  I didn't do it at the time because it seemed to me I was awful
late & didn't want to bother

Today, however, someone poked me about the tree-climbing issue, so I
thought I better say something.

The proposal that Richard Barnes made here on the list, to query the
name directly, seems to me to be the right one.  I do not see how
tree-climbing is going to help.  Moreover, it seems to me to cause a
result that is at least surprising in the face of alias chains
(particularly where DNAMEs are concerned).  

As for the wildcard issue: is there some reason not to put the CAA at
the wildcard in the DNS?  That seems to me to be right, and has the
additional benefit that it delivers the parent-side CAA record benefit
without needing to put a CAA record at any child name.

Best,

A

--- forwarded review

Review of draft-ietf-pkix-caa-11

I've been asleep at the switch.  I knew this draft went off to PKIX to
get worked on, but I failed to continue to follow it.  Here is my
review.  Sorry I'm late.

I.  Definitions

Some of these terms strike me as diverging a little from what I'd have
expected.

   Canonical Domain Name:  A Domain Name that is not an alias.  See
      [RFC1035] and future successors for definition of CNAME alias
      records.

Note that DNAMEs also produce aliases (this is noted later in the
document).  It'd probably be worth pointing that out.  2181 has some
helpful text, and if this and the next term is sorted out correctly I
suspect that this document has fallen into exactly what 2181 warns
about.

   Canonical Domain Name Value:  The value of a Canonical Domain Name.
      The value resulting from applying alias transformations to a
      Domain Name that is not canonical.

The first part of this definition is circular.  It seems that the
second part is talking about a canonical domain name.  In other words,
suppose you have a chain of CNAMEs.  At the end of the chain, if you
don't run out of time or processing patience and don't have a loop, is
a canonical domain name: the one true answer that itself can have A or
AAAA records and so on.  In 1034/5 and, more clearly, 2181, that's
called a "canonical domain name".  The "value" here isn't doing any
work, AFAICS.  Discussion later in the document seems not to rely on
these terms, so I'd be inclined to get rid of them.

   Domain:  The set of resources associated with a DNS Domain Name.

This is an interesting way to put it.  The difficulty I see is in that
term "resources".  Is this intended to mean "resource records"?  If
so, it must be false, because the domain also contains all the records
_not_ at that domain, but named by it.
(this.name.does.not.exist.in.crankycanuck.ca is in crankycanuck.ca,
but a query for it returns RCODE=3, Name Error).  This also seems not
to be the meaning of "domain" (different capitalization?) in section
4.2.  That definition is made up of labels, which are _not_ DNS labels
but instead a subset of DNS labels, constrained so as to meet the
traditional hostname, or LDH, syntax.

   Domain Name:  A DNS Domain name as specified in [RFC1035] and
      revisions.

I suspect the reference here is more appropriately to 1034, since it
has the concepts and so on and therefore expresses what a domain is.
Again, note that the document doesn't actually seem to apply to domain
names, but names conforming to the preferred syntax.

   Domain Name System (DNS):  The Internet naming system specified in
      [RFC1035] and revisions.

Should definitely include STD13, which is both 1034 and 1035.

   DNS Security (DNSSEC):  Extensions to the DNS that provide
      authentication services as specified in [RFC4033]. and revisions.

We decided about two years ago that DNSSEC is defined by 4033,
4034, 4035, and 5155.  The reasoning is only still in I-D form,
though, since that I-D is wending its way to publication, so it's not
surprising people don't have a way of knowing.

   Public Delegation Point:  The Domain Name suffix under which DNS
      names are delegated by a public DNS registry such as a Top Level
      Directory.

I understand why this needs to be defined, but we seem to have about
10 million different ways to refer to these things.  So you might
include, "Also known as public suffix, effective TLD, and even just
public domain," or something along those lines.  What does the term
"suffix" add?  It's a domain name.  COM is a domain name, not a
suffix.  Also, in my reading that definition is inconsistent with
section 2.1.  See below.

   Resource Record (RR):  A set of attributes bound to a Domain Name as
      defined in [RFC1035].

That's a very unusual gloss of RR.  Moreover, it ignores that RRs come
in sets.  See section 5 of 2181.  This definition isn't exactly wrong,
I think, but it's strained and I believe somewhat misleading.  Perhaps
better to say something like this: "A particular entry in the DNS
including the owner name, class, type, time to live, and data, as
defined in [RFC1035] and [RFC2181].  Resource records come in sets
identified by the owner name, class, and type.  The time to live on
all RRs is always the same.  The data may be different among RRs in an
RRset."  Or something like that.

II.  Issues in the text

In section 2.1, we have this:

   The following example informs CAs that certificates MUST NOT be
   issued except by the holder of the domain name 'ca.example.net' or an
   authorized agent thereof.  Since the policy is published at the
   Public Delegation Point, the policy applies to all subordinate
   domains under example.com.

   $ORIGIN example.com
   .       CAA 0 issue "ca.example.net"

First, "the policy" here is not, AFAICT, published at the Public
Delegation Point, but at a delegation beneath it.  The Definition of
PDP above means that com is the delegation point ("under which DNS
names are delegated": com does the delegation).  Second, this seems to
suggest that the policy flows top-down and constrains subordinate
names, but that's not what's in section 3.  Finally, that example
isn't actually for the example.com name, but for the root zone, at
least as it shows up when I look at it.  According to RFC1035, the
master file format uses <blank> there.  See RFC 1035 section 5.1 This
is true of other examples in the draft also.

Section 2.1 also includes this:

   $ORIGIN example.com
   .       CAA 0 issue "ca.example.net; account=230123"

Unless I overlooked it (and I might have), I can't find where the
document says that ";" is the parameter-separation character.  This
makes sense, because, "The syntax and semantics of such parameters is
left to site policy and is outside the scope of this document."  The
problem here, however, is that the document is supposed to be defining
the "issue" property tag, which is supposed to be somehow interpreted
by a reader of the document.  It's sort of hard for me to see how one
can define an output format of completely opaque blobs and call
it a "standard".  (This isn't particularly a DNS issue.  I just find
it a strange way to proceed.)

Section 3 depends on two different notions, the Issuer Authorization
Set and the Extended Issuer Authorization Set.  The ISA is just what
you'd think: the stuff you get back from a CAA query at that owner
name.  This is, of course, inconsistent with the bit from 2.1 (see
above), but I think it makes sense.  Then, however, we get the EISA,
which requires climbing the DNS tree to a Public Delegation Point.
How you get the Public Delegation Point is not defined, though I guess
the usual way to do it these days is to use the list at
publicsuffix.org and hope they are right.

I have two objections to this procedure.  The first is the usual
tree-climbing problem: this isn't something the DNS is well-suited to,
and it directs a bunch of queries into the DNS for no good reason.  

The second is that it imposes a constraint on subordinate names when
they don't know it.  Suppose that I delegate myfriend.crankycanuck.ca
(a domain I control), and I happen to publish a CAA record at
crankycanuck.ca.  If I don't tell my friend to publish a CAA record,
then my friend is stuck using the CA I selected.  I understand why it
would be convenient to climb the tree, but I don't think it's
necessary and I'm not convinced it's a wise addition to the protocol.  

We also have

   The DNS defines the CNAME and DNAME mechanisms for specifying domain
   name aliases.  The canonical name of a DNS name is the name that
   results from performing all DNS alias operations.  An issuer MUST
   perform CNAME and DNAME processing as defined in the DNS
   specifications [RFC1035] to resolve CAA records.

In combination with the tree-climbing issue, this is going to be
problematic.  Suppose we have

    example.net DNAME example.com

and 

    example.net CAA [$x]

Now, suppose we also have

    foo.example.com CAA [$y]

If someone requests a cert for bar.foo.example.net, does the CAA at
example.net rule, or the CAA at foo.example.com?  I guess it's the one
at foo.example.com, because the alias resolution appears to be
performed before anything else, but I find this result a little
surprising.  (It would just go away if the EISA wasn't there.)

Section 4.2's ABNF constrains domains to the hostname/LDH syntax.
This might be fine, but the document should probably state that
explicitly somewhere, since as things stand it seems to suggest that
you can use CAA for "domain names" and not for "domain names made up
entirely of LDH-labels".

Does section 4.3 constrain iodef URLs to only the mailto and http[s]
schemes?

Section 5.3 suggests that complete failure to get an answer for CAA
queries for a name results in the issuer refusing to issue a
certificate.  This could be stated more directly.

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Jul 2012 16:08:23 -0400

> without needing to put a CAA record at any child name.

Can you clarify what you mean by "at the wildcard"?  ISTM that that would mean

*.example.com CAA etc...

How would a CA look that record up?  Is it possible to have a qname "*.example.com"?  

Thanks,
--Richard

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Jul 2012 17:32:24 -0400

> Can you clarify what you mean by "at the wildcard"?  ISTM that that would mean

Yes.

> How would a CA look that record up?  Is it possible to have a qname "*.example.com"?  

Yes.  RFC 1034 section 4.3.3 says this:

    A * label appearing in a query name has no special effect, but can be
    used to test for wildcards in an authoritative zone; such a query is the
    only way to get a response containing RRs with an owner name with * in
    it.  The result of such a query should not be cached.

This has always worked for me with dig.  I'm not entirely sure what
high-level libraries do with wildcards, though; I wouldn't be
surprised to learn that some of them do stupid things.  Still, you're
supposed to be able to ask for these.

Best,

A

-- 
Andrew Sullivan
[email-masked]