Subject: Re: [Spasm] Erratum 4988

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 5 Jun 2017 12:27:42 -0400

I fixed the 'is not empty' thing in Errata 4992.

https://www.rfc-editor.org/errata_search.php?eid=4992

If you missed it, I am not surprised as I only noticed it after I was half
way through entering it again. For some reason the Errata are not in
numerical order.

I would prefer not to change the description of the algorithm in the way
you propose in what is an Errata.

On Wed, May 31, 2017 at 8:39 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> Hi Phillip,
>
> Did you see this earlier mail from me? I think at least the "is not
> empty" should be fixed before we submit a ballot to CA/Browser Forum.
> Ideally I'd like to land the simpler language I proposed, but I'd be
> fine with your offered text if we add the missing "is not empty."
>
> On 04/05/2017 12:43 PM, Jacob Hoffman-Andrews wrote:
> > https://www.rfc-editor.org/errata_search.php?eid=4988
> >
> > Rob Stradling said:
> >> 2. Bug?: Shouldn't this...
> >>   o  If A(X) is not null, and CAA(A(X)), then R(X) =
> >>      CAA(X), otherwise
> >>
> >> ...actually be this...
> >>
> >>   o  If A(X) is not null, and CAA(A(X)), then R(X) =
> >>      CAA(A(X)), otherwise
> > A further edit: "and CAA(A(X))" should be "and CAA(A(X)) is not empty"
> >
> > Also, did you see my earlier suggestion on the list? I think now that we
> > aren't tree-climbing on CNAME targets, we can express this algorithm in
> > a more straightforward way that emphasizes its similarity to how other
> > DNS records are looked up:
> >
> > ----- Proposal -----
> >    Let CAA(X) be the record set returned by performing a CAA record
> > query on the domain name X, according to the name server lookup
> > algorithm specified in RFC 1034 section 4.3.2 (in particular including
> > CNAME responses). Let P(X) be the domain name produced by removing the
> > leftmost label of X.
> >
> >  - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise
> >  - If P(X) is the root domain '.', then R(X) is empty, otherwise
> >  - R(X) = R(P(X))
> >
> > ----- End proposal -----
>
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 5 Jun 2017 09:56:06 -0700

When I visit https://www.rfc-editor.org/errata_search.php?eid=4992,
 I still see this incorrect text:

> If A(X) is not null, and CAA(A(X)), then R(X) =
>      CAA(A(X)), otherwise

Specifically the clause "and CAA(A(X))" should be "and CAA(A(X)) is not
empty".

And yep, understandable about wanting to minimize changes to get this
through promptly; I'm fine with that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 5 Jun 2017 13:52:42 -0400

OK, will update and correct. Sorry about that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 5 Jun 2017 14:27:10 -0400

Thanks to Paul for also pointing this out. Is the following correct:

Section 4 says:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
      R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

It should say:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record chain specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

  Thus, when a search at node X returns a CNAME record, the CA will
  follow the CNAME record to its target. If the target label contains a
  CAA record, it is returned. otherwise, the CA continues the search at
  the parent of node X.

  Note that the search does not include the parent of a target of a
  CNAME record (except when the CNAME points back to its own path).

  If the target of a CNAME record is itself a CNAME record, the CA MAY
  follow it or MAY ignore it. In either case, the search continues at
  the parent of the label containing the initial CNAME.

  Processing for DNAME is exactly the same as for CNAME. Note that since
  DNAME records are implemented by creating the corresponding CNAME
  records on the fly, it is only necessary for DNAME records to appear
  on the wire for purposes of DNSSEC.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 5 Jun 2017 15:04:12 -0700

This looks good to me, thanks!

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 6 Jun 2017 10:04:08 -0400

It is now Errata 5029.

https://www.rfc-editor.org/errata/eid5029

Looking for a CABForum seconder.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 6 Jun 2017 09:24:05 -0700

Great! I was giving a final read-through and noticed a couple more

>  CNAME record (except when the CNAME points back to its own path).

It's not clear what "back to its own path" means here. How about "unless
it happens to be the result of one of the P(X) lookups in the algorithm
above"

>  the parent of the label containing the initial CNAME.

This seems to introduce a normative statement that CAs need only chase
CNAME alias record chains one level deep, when the rest of DNS assumes
that you will chase them arbitrarily deep, with loops treated as an error:

RFC 1034 3.6.1:
> CNAME chains should be followed and CNAME loops signalled as an error.

It's undesirable to introduce these two MAYs because they creates
ambiguity in how different CAs will interpret a given CAA configuration
containing chained CNAMEs.

I think we should remove the paragraph starting with "If the target of a
CNAME record..."

On 06/06/2017 07:04 AM, Phillip Hallam-Baker wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 10:19:30 -0400

On Tue, Jun 6, 2017 at 12:24 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:
> Great! I was giving a final read-through and noticed a couple more problems.
> Sorry I didn't spot these on the first read:
>
> It's not clear what "back to its own path" means here. How about "unless it
> happens to be the result of one of the P(X) lookups in the algorithm above"
>
> This seems to introduce a normative statement that CAs need only chase CNAME
> alias record chains one level deep, when the rest of DNS assumes that you
> will chase them arbitrarily deep, with loops treated as an error:
>
> RFC 1034 3.6.1:
> It's undesirable to introduce these two MAYs because they creates ambiguity
> in how different CAs will interpret a given CAA configuration containing
> chained CNAMEs.
>

The ambiguity is inescapable. An implementation may be following the
old or the new rule. I think it is better to point out that ambiguity
exists.

Unless there is a really good reason, I am opposed to further changes.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 13 Jun 2017 09:40:56 -0700

> old or the new rule. I think it is better to point out that ambiguity
Ah, now I see. Is your intent with this paragraph to say that CAs MAY
follow the old tree-climbing behavior? Because that's not what it says
currently. It says that CAs may terminate CNAME following after
following a single CNAME. For instance if you have:

www.example.com CNAME validation.example.net
validation.example.net CNAME server123.example.net
server123.example.net CAA "ca.example.com"

This paragaph says that the CA MAY choose not to follow that second CNAME.

Also, I think it's incorrect to say that this ambiguity exists. We
should specify clearly what the correct behavior under this erratum is,
and simply mention "some CAs may implement an earlier version of the CAA
spec, with X behavior." But that behavior wouldn't be following the
erratum behavior.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 13:04:53 -0400

Ah now I know that the issue was. Back in the vagaries of DNS.

The problem is that CNAME is not supposed to point to a CNAME but
frequently does. CAs may implement a limit on the number of chained
CNAME links they follow.

So maybe reword to explicitly state that if we have a CNAME chain like
that, CAs may set a processing limit (provided they declare it) ?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jun 2017 17:07:46 +0000

> frequently does. CAs may implement a limit on the number of chained

Where does it say that?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 13:24:13 -0400

>> frequently does. CAs may implement a limit on the number of chained

https://tools.ietf.org/html/rfc1034
3.6.2. Aliases and canonical names

Domain names in RRs which point at another name should always point at
the primary name and not the alias.  This avoids extra indirections in
accessing information.  For example, the address to name RR for the
above host should be:

    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
principle, domain software should not fail when presented with CNAME
chains or loops; CNAME chains should be followed and CNAME loops
signalled as an error.

It is this sort of drafting that makes dealing with DNS difficult.
Whatever you try to write, you build on quicksand.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 13:29:43 -0400

> Whatever you try to write, you build on quicksand.

Oh and it is updated and clarified in several places. But not to
change the above as far as I can see. But there are a dozen updates.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jun 2017 17:50:13 +0000

> > chains or loops; CNAME chains should be followed and CNAME loops

You are misreading the spec.  First, the quoted example is PTR records, not CNAME.  Second, the text alks about CNAME loops and chains, if how can you have either without a CNAME pointing to a CNAME?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 15:04:49 -0400

> You are misreading the spec.  First, the quoted example is PTR records, not CNAME.  Second, the text alks about CNAME loops and chains, if how can you have either without a CNAME pointing to a CNAM…

"Domain names in RRs which point at another name should always point at
the primary name and not the alias."

Seems pretty clear to me. The part about loops is prefixed with "Of
course, by the robustness principle".

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jun 2017 19:39:19 +0000

> Seems pretty clear to me. The part about loops is prefixed with "Of course,
> by the robustness principle".

Well 1036 predates SHOULD MUST etc.  But it does say should :)

And anyway, CNAME pointing to CNAME is common.  Perhaps it's time for yet another update to 1036.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 13 Jun 2017 12:53:02 -0700

> that, CAs may set a processing limit (provided they declare it) ?
This works for me, but we should include a MUST with a minimum number of
CNAMEs to follow, e.g. 10.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Jun 2017 00:42:48 +0000

> CNAMEs to follow, e.g. 10.

Works for me.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Jun 2017 19:11:11 -0400

The RFC Editor has deleted all three of the existing errata. I would like
for the next errata to be the very last.

Could people read, review and state if this works for them?
​ This text is the same as the one I posted to CABForum earlier with the
one exception being that I capitalized Otherwise in the place it needed it.​

Original Text

-------------

      R(A(X)), otherwise

   o  R(X) is empty.

Corrected Text

--------------

      CAA(A(X)), otherwise

   o  R(X) is empty.

  CAA record, it is returned.
​O​
therwise, the CA continues the search at

  the parent of node X.

 To prevent resource exhaustion attacks, CAs should limit the length of

  CNAME chains that are accepted. However CAs MUST process CNAME

  chains that contain ten or fewer CNAME records.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Jun 2017 15:52:18 -0400

In response to comments by a non list subscriber:

s/follow the CNAME record/follow the CNAME record chain

s/ten or fewer/8 or fewer/

The first is just for clarity and the second is because it turns out that
unbound has a hard limit of 8 CNAME records to follow in a chain which
provides a justification for a number that was previously arbitrary.

If there is a revision of RFC1035 to specify a limit it will certainly
follow unbound unless there is another library in common use with a
different limit.

Corrected Text

--------------

      CAA(A(X)), otherwise

   o  R(X) is empty.

  follow the CNAME record chain to its target. If the target label

  contains a CAA record, it is returned.

​O​

  the parent of node X.

  chains that contain 8 or fewer CNAME records.

On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 23 Jun 2017 17:15:05 -0700

This version looks good to me. Good catch to whoever pointed out
Unbound's hard limit. And thanks to Phillip for pushing this through
multiple revisions. Any other thoughts from the list?

On 06/22/2017 12:52 PM, Phillip Hallam-Baker wrote:
> The first is just for clarity and the second is because it turns out
> that unbound has a hard limit of 8 CNAME records to follow in a chain
> which provides a justification for a number that was previously arbitrary.
>
>
>   contains a_ _CAA record, it is returned.
>
>
> ​O​
> On Wed, Jun 14, 2017 at 7:11 PM, Phillip Hallam-Baker
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The RFC Editor has deleted all three of the existing errata. I
>     would like for the next errata to be the very last.
>
>      
>
>     ​ This text is the same as the one I posted to CABForum earlier
>     with the one exception being that I capitalized Otherwise in the
>     place it needed it.​
>
>
>      
>
>     Original Text
>
>     -------------
>