Subject: [DNSOP] meaning of tag "match" for CAA RDATA

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Feb 2018 08:26:54 -0800

I happen to have this question while reading RFC6844: what does the
"matching" mean in the following description of Section 5.1?

   Tag:  The property identifier, a sequence of US-ASCII characters.

      Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
      through 'Z', and the numbers 0 through 9.  Tag values SHOULD NOT
      contain any other characters.  Matching of tag values is case
      insensitive.

Although the boundary is not very clear, Section 5.1 generally seems
to talk about the DNS-level syntax (e.g. what should/should not appear
in wire as a DNS message or in a zone file), while Section 5.2 and
later mainly talk about the semantics at the application layer
(something that validates certificates).  Since the above text is in
Section 5.1, I first thought "matching of tag values" was a DNS level
concept.  But then it's not clear to me what it actually means.

Does this mean, for example, we should perform case-insensitive
comparison of this field when we compare CAA RDATAs?  (If so, at least
ISC BIND 9 isn't compliant to the spec; it doesn't care about the case
of the tag field when loading or serving or updating or signing a CAA
RR).

It may also be related to Section 5.1.1, which states:

   The canonical presentation format of the CAA record is:

   CAA <flags> <tag> <value>
[...]
   Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
      case.

which might read, for example, as 'dig' should present the tag field
with lower-case letters.  But 'dig' currently doesn't work that way.

Could someone more familiar with the background of CAA clarify these
points?

Thanks,

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Feb 2018 08:25:35 +1100

> On 8 Feb 2018, at 3:26 am, 神明達哉 <[email-masked]> wrote:
> 

Why should it care about the case? ABC is different to abc as far as
DNSSEC and handling of unknown record types is concerned.  A signer
that is CAA aware could remove “duplicates” that differ in the case
of this field but nothing else can.

When you load from disk you can’t know if the signer was CAA aware or
not.

UPDATE has to behave as is the records are opaque as the UPDATE client
has no idea whether the server is CAA aware or not.  You need to send
perfect matches to delete a individual record.

> with lower-case letters.  But 'dig' currently doesn't work that way.

Dig presents data such that it can re-entered into a master file.  Others
can transform it if they wish.

> Could someone more familiar with the background of CAA clarify these

The CA's can deduplicate if they need to after performing DNSSEC
validation.

> Thanks,
> 
> --
> JINMEI, Tatuya
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Feb 2018 14:15:50 -0800

At Thu, 8 Feb 2018 08:25:35 +1100,

[...]
> of this field but nothing else can.

I didn't intend to say it (DNS implementation) should care about the
case.  My point (or question) was the RFC text can be ambiguous.  On
re-reading RFC3597 I now see it would clearly violate Section 6 of
RFC3597:

   specifications for new RR types MUST NOT specify
   type-specific comparison rules.

if it meant case-insensitive RDATA comparison.  But the current text
of RFC6844 made me think whether the RFC erroneously violated it or it
meant something else.  It would have been clearer if "Matching of tag
values is case insensitive" were somewhere after Section 5.1, or at
least it explicitly said this is about CAs that use the CAA, not for a
DNS implementation.

I'd also wonder what the "Canonical Presentation Format" means then:

so, for example, we can't always safely dump a validly loaded zone
containing CAA whose tag has an upper-cased letter into a file in the
"canonical presentation format" and then re-load it, since the dump
can result in false duplicates.

...and now I see there was almost exactly the same discussion about 2
years ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16810.html

Perhaps it's pretty clear that the current text of RFC6844 is very
confusing (if not wrong) and worth some errata again?

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Feb 2018 09:43:47 +1100

> On 8 Feb 2018, at 9:15 am, 神明達哉 <[email-masked]> wrote:
> 

Software that processes CAA records returned by the DNS can remove
any duplicates detected at that level of processing. The DNS isn’t
in a position to do that de-duplication.

For UPDATE I would always delete the CAA RRset and re-add it to
update it rather than do it at the RR level.

I believe the current RFC is enough for the records to be interpreted
correctly if you don’t violate the SHOULD NOT.  I don’t believe that
they ever will contain values that violate that SHOULD NOT except in
test suites.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Feb 2018 09:52:01 +1100

> On 8 Feb 2018, at 9:43 am, Mark Andrews <[email-masked]> wrote:
> 

Additionally any record that can’t be represented in the canonical form
can be presented in unknown record format.  This will handle tags that
violate the SHOULD NOT.