Subject: [lamps] CAA Simplification draft

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 12 Sep 2017 17:23:51 -0700

Hi all,

This is a revision to RFC6844 as discussed previously on the list and at
IETF 99. In particular, RFC6844 specifies that CAs should implement
"tree climbing" not only on the original FQDN, but also on any
intermediate CNAMEs discovered during primary lookup. As discussed
on-list, this disallows certain deployment scenarios, and can produce
surprising results in common CNAME-based hosting scenarios.

Additionally, because RFC6844 re-specified parts of CNAME lookup, some
details were ambiguous. This draft updates RFC6844 to eliminate tree
climbing on CNAME targets, and to reference RFC 1034 for the standard
DNS lookup algorithm, including CNAME resolution.

Because all of this draft is the same as RFC6884 except for the
"Certification Authority Processing" section, I've retained the original
two authors and added my own name. Please let me know if IETF etiquette
indicates a different approach.

I'd like to propose this draft for adoption by the WG.

https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-00.txt

Thanks,
Jacob

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Tue, 12 Sep 2017 18:28:59 -0700

While this removes the ambiguities with regard to CNAME and DNAME alias
handling I think the definition of the algorithm is still unnecessarily
hard to read. Also references to 'CNAME' should be replaced with
'aliases' since 1034 section 4.3.2 as updated by 6672 also handles
DNAMEs (although to be honest I think any references to specific 1034
4.3.2 behavior can just be removed since they are incorporated simply by
referencing that algorithm).

I'd suggest that Section 4 paragraphs 3-9 be replaced with the following
cleaned up definition using pseudocode and a better explanation of the
steps the algorithm uses in the example:

https://github.com/jsha/caa-simplification/compare/master...rolandshoemaker:alg-cleanup?expand=1

I'd also recommend this RFC be paired down to only section 4 since that
is all that is being changed and make it a 'Updates' instead of
'Obsoletes' style RFC that just redefines the lookup algorithm.

Thanks for doing the work on this! I think taking this approach, of
simplifying the algorithm definition, is better as completely
re-designing the algorithm and using a different record style,
especially given this is what CABF has already adopted, without a well
defined reason is just asking for more problems down the line.

On 09/12/2017 05:23 PM, Jacob Hoffman-Andrews wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 12 Sep 2017 22:28:30 -0700

Thanks Roland! I've incorporated this feedback into a new draft:
https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt.

If anyone else would like to propose edits or make PRs, I have a copy
available on GitHub: https://github.com/jsha/caa-simplification.

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Tue, 12 Sep 2017 22:56:11 -0700

> 'Obsoletes' style RFC that just redefines the lookup algorithm.

I'll actually retract this after reading through RFC 2223 and 7322,
since this is a breaking change from the algorithm in 6844 this should
probably be a 'Obsoletes' and therefore contain all of the existing
content that isn't being changed.

---

From: [email-masked]
Date: Tue, 19 Sep 2017 19:20:08 +0900 (JST)

I did not know about RFC 6844 and was surprised about "tree climing"
and "CNAME".

> From: Jacob Hoffman-Andrews <[email-masked]>

I checked differences between RFC 6844 and the draft.
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/rfc/rfc6844.txt&url2=https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt

I have some comments.

- Current draft has some formatting mistakes.

  current text: $ORIGIN example.com .  CAA 0 issue "ca.example.net"

  should be   (from RFC 6844)

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

  However, I would like to suggest to remove "$ORIGIN" and add tailing
  dot in domain names.

  proposed:  example.com. CAA 0 issue "ca.example.net"

- Current document still contain "tree climing" and checks CAA RR in TLDs.

  The tree climing should stop at administrative domain boundaries.

  "example.com." domain name owner does not want to be checked "com. CAA".

  See (concluded) dbound WG and Public Suffix list discussions.
    https://tools.ietf.org/wg/dbound/
    https://publicsuffix.org/

- I like prefixed record solution proposed at IETF 99 lamps WG.
  https://datatracker.ietf.org/meeting/99/materials/slides-99-lamps-caabis/

  However, it is not compatible with RFC 6844.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Sep 2017 08:04:53 -0400

Administrative boundaries are not visible in the DNS. Attempting to attach
semantics to the zone cut creates more problems than it solves.

Given the length of the document and the need to cite it in other
documents, I don't think an update is appropriate. Obsoleting the old text
and replacing is the way to go.

The reason the tree climbing is necessary is that MANY DNS host and service
names are not visible on the public DNS. So most of the time, a CA has no
way to validate the records for secrethost.example.com, the CAA record has
to be at example.com.

The reason aliases are necessary is two fold. One is to support delegation
of the domain to a different administration as is typical in a CDN, the
other is to simplify management of large portfolios of domains. The DNS
only provides one alias record (DNAME is not an alias, see below) so it is
not clear what the purpose of the alias is. When RFC6844 was written, CDNs
were the exception, now they are much more common.

Further, the DNS spec is broken in that it requires that a CNAME be the
only entry at a node if present.

On the DNAME issue, it is not really an alias as a DNAME is a wildcard
record that would have never appeared on the wire until DNSSEC made it
necessary. An application does not process a DNAME directly, it uses the
DNAME record to either validate a CNAME or infer that one should have been
presented but was not.

On Tue, Sep 19, 2017 at 6:20 AM, <[email-masked]> wrote:

> https://tools.ietf.org/rfcdiff?url1=https://tools.
> ietf.org/rfc/rfc6844.txt&url2=https://www.ietf.org/id/draft-
> hoffman-andrews-caa-simplification-01.txt
>
> I have some comments.
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 20 Sep 2017 09:10:47 -0700

> - Current document still contain "tree climing" and checks CAA RR in TLDs.

Yes, the goal is to remove tree climbing on the targets of aliases,
which causes known problems (discussed earlier on this list), but keep
tree climbing on the actual hostname being checked, which provides
useful properties as Phillip mentioned.

Thanks for pointing out the formatting mistakes, I'll fix those.