Subject: Re: [pkix] Erratra rejection

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Mar 2016 07:34:03 +1100

I believe the erratra below was rejected incorrectly.

Firstly I can't see any discussion of this erratra on the pkix list
in the archive.

Secondly there are lots of technical errors in the rejection logic.

1) Nameserver reject whole zones at load time if a record refuses to parse.
   The record is not just stipped.  This is a reqirement of STD 13.
   [BIND used to do just that 2 decades ago and I stopped it doing so as it
    caused problems and because it was against STD 13.  Zones with syntax
    errors in them are not loaded.  This actually results in people fixing
    the zones.]
2) Master file format is a recognised transfer format in STD 13.
3) Not being able to print out all records held the DNS back for years until
   RFC 3597 was written.

Master file format is also a storage format for some slave zones
so, yes, it very much is "as important" as the wire format.  It has
to work across multiple vendors.

The code "has to work" where work can be "reject the label" and
reject responses with the label.  Responses and zones with invalid
records get rejected all the time.

There is no requirement for a nameserver to accept garbage in a
zone transfer even if it is a slave.

There is no need for labels to be anything other than the restricted
syntax of a-z, 0-9.  They are essentially not for human consumption.
Even if humans were to consume them then DNS tools (assuming that
they accept them in the first place) will convert the non printable
ascii octets to \DDD format as required by STD 13 to produce a
single label.  The only character set in the DNS is ASCII.  Tags
in anything other than ASCII have no character set associated with
them so they cannot be displayed in native format even if you wanted
to.  Personally I would have had "-" to make the tag LDH but it was
specified as LD.

Non DNS tool are likely to just "print out the tag" and that is a
security failure waiting to happen.  Sendmail provides a object
lesson of what happens when that occurs.

Additionally for labels to be useful they need to be accepted into
the IANA registry.  Are you now telling IANA that non a-z 0-9 labels
are acceptable?

This record was also allocated on the basis of a MUST NOT.  Changing
it to SHOULD NOT breaks deployed code.  Parsers get written as soon
as the code point is allocated, not on RFC issuance when the expert
path is used as it was in this case.

Mark

Status: Rejected (1)
RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record", January 2013
Source of RFC: pkix (sec)
Errata ID: 4061

Status: Rejected
Type: Technical

Reported By: Evan Hunt
Date Reported: 2014-07-24
Rejected by: Kathleen Moriarty
Date Rejected: 2014-09-03
Section 5.1 says:

Tag values SHOULD NOT contain any other characters.
It should say:

Tag values MUST NOT contain any other characters.
Notes:

Since the text representation of the tag field is unquoted, spaces and other whitespace must be explicitly excluded. Otherwise, it is possible to create a CAA record whose text representation cannot be parsed.
--VERIFIER NOTES-- 
This really gets down to MUST/SHOULD theology and whether you consider
the zone file syntax at the same level of conformance as DNS protocol.

The author believes SHOULD is correct here. The protocol on the wire will work
just fine if someone breaks this advice.

Yes, it might well break some zone file parsers. But those aren't on
the wire and that type of incompatibility is exactly what I would
expect from violating a SHOULD.

Code has to work if someone creates a RR with a non conformant label,
therefore a MUST does not saves any work. And the only circumstance in
which the editor can imagine someone using it would be where they wanted a
label that could not be inserted through normal zone files.

Phil Hallam-Baker certainly doesn't want people writing parsers to strip out records
with non conformant labels. So, stick with SHOULD.

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

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 11 Mar 2016 12:47:27 -0500

Dick Franks wrote:
> There is no need to resort to doctrinal arguments about MUST/SHOULD, or
> imagine that the RFC6844 tail can wag the RFC1035 dog.
> 
> Mark A's objection really points a fundamental contradiction in RFC6844
> itself.

Hi, Dick:

Are you implying that 6844 violates 1035 in some way? I understand the
reasoning in the erratum rejection:

    [...]

    The author believes SHOULD is correct here. The protocol on the wire
    will work just fine if someone breaks this advice.

    [...]

to be asserting that a valid wire format RR can have no valid canonical
presentation format. The closest requirement I can find in 1035 is this:

    5. MASTER FILES

    Master files are text files that contain RRs in text form.  Since the
    contents of a zone can be expressed in the form of a list of RRs a
    master file is most often used to define a zone, though it can be used
    to list a cache's contents.

I.e., cacheable RRTYPEs (non- meta TYPEs) must be representable in
master files. At the time 1035 was written, this would have implied a
requirement that valid wire format RRs must have a valid canonical
presentation format. But 3597 defined the generic "\#" encoding for
RDATA appearing in master files, and explicitly allowed its use for
representing known RRTYPEs:

   An implementation MAY also choose to represent some RRs of known type
   using the above generic representations for the type, class and/or
   RDATA, which carries the benefit of making the resulting master file
   portable to servers where these types are unknown.  Using the generic
   representation for the RDATA of an RR of known type can also be
   useful in the case of an RR type where the text format varies
   depending on a version, protocol, or similar field (or several)
   embedded in the RDATA when such a field has a value for which no text
   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
   0.

   Even though an RR of known type represented in the \# format is
   effectively treated as an unknown type for the purpose of parsing the
   RDATA text representation, all further processing by the server MUST
   treat it as a known type and take into account any applicable type-
   specific rules regarding compression, canonicalization, etc.

> RFC6844:
> 
> 5.1.1.  Canonical Presentation Format
> 
>    The canonical presentation format of the CAA record is:
> [snip]
> 
>    Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
>       case.
> 
> [I assume "non-zero" really means "non-empty"]
> 
> 
> is incompatible with the text in 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.
> 
>       Tag values submitted for registration by IANA MUST NOT contain any
>       characters other than the (lowercase) US-ASCII characters 'a'
>       through 'z' and the numbers 0 through 9.
> 
> 
> which not only appears to imply the existence of two distinct species of
> tag identifiers, but has the bizarre consequence that not all tag
> identifiers are exactly representable using the canonical format prescribed
> by section 5.1.1
> 
> The same form of words, or at least compatible words, should be used in
> both places.  RFC6844 offers no justification for case folding, so
> specifying exact matching would make the whole issue go away.

I would hazard a guess that the "Matching of tag values is case
insensitive" sentence is a requirement on applications that consume the
RR, and not to DNS protocol comparisons like RRset data equality or
DNSSEC canonical form. (Note the sentence "Applications that interpret
CAA records..." a few lines up.)

-- 
Robert Edmonds

---

From: Dick Franks <[email-masked]>
Date: Fri, 11 Mar 2016 13:08:48 +0000

RFC6844:

Dick Franks
________________________

---

From: Dick Franks <[email-masked]>
Date: Fri, 11 Mar 2016 20:29:17 +0000

On 11 March 2016 at 17:47, Robert Edmonds <[email-masked]> wrote:

> Are you implying that 6844 violates 1035 in some way?

6844 5.1.1 defines the tag field in a way which forbids the (arbitrary)
characters which MAY (but SHOULD NOT) be present according to the text in
5.1.

This conflicts with the 1035 notion that master files contain text
representation of RRs.

I understand the
> presentation format.

But CAA _does_ have a canonical presentation format, defined at 5.1.1.

>     to list a cache's contents.

So are you really suggesting flipping between canonical 6844 format and
3597 \# format merely because the tag field happens to contain some
non-alphanumeric character or upper case letter?

> RFC6844 offers no justification for case folding, so

An unnecessary complication in my view, but maybe that is off-topic here.

--
Dick Franks

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 11 Mar 2016 16:42:28 -0500

Hi,

> characters which MAY (but SHOULD NOT) be present according to the text in

It's clear from the context that 6844 §5.1 is talking about the wire
format, while §5.1.1 is talking about the presentation format. If the
rules for the canonical presentation format are stricter than the rules
for the wire format, then there exist wire RRs that cannot be
represented using the canonical presentation format. Which, the
verifier's notes in erratum 4061 claim, is OK, and not a contradiction.

> This conflicts with the 1035 notion that master files contain text

Any instance of a cacheable wire RR has a master file compatible text
representation, thanks to the generic text encoding defined in RFC 3597.

1035 doesn't distinguish between canonical and generic text
representation because the generic encoding hadn't been invented yet, of
course.

> But CAA _does_ have a canonical presentation format, defined at 5.1.1.

Sorry, I meant to say that the erratum rejection asserts that there can
exist instances of valid on-the-wire RRs of known type that don't have a
valid canonical presentation form.

> non-alphanumeric character or upper case letter?

Yes. If a RR can't be presented canonically, how else would you do it?

This is apparently exactly how BIND handles LOC records whose VERSION
field is not 0, BTW:

$ dig +norec @70.89.251.90 -t AXFR test.mycre.ws

; <<>> DiG 9.10.3 <<>> +norec @70.89.251.90 -t AXFR test.mycre.ws
; (1 server found)
;; global options: +cmd
test.mycre.ws.      3600    IN  SOA mycre.ws. hostmaster.mycre.ws. 2016031104 7200 3600 604800 3600
test.mycre.ws.      3600    IN  NS  bst.mycre.ws.
loc.test.mycre.ws.  3600    IN  LOC \# 16 FF0000C0237F0000B02600C0237F0000
loc2.test.mycre.ws. 3600    IN  LOC 42 21 28.764 N 71 0 51.617 W -100000.00m 2000m 10000m 10m
test.mycre.ws.      3600    IN  SOA mycre.ws. hostmaster.mycre.ws. 2016031104 7200 3600 604800 3600
;; Query time: 0 msec
;; SERVER: 70.89.251.90#53(70.89.251.90)
;; WHEN: Fri Mar 11 15:58:01 EST 2016
;; XFR size: 5 records (messages 1, bytes 197)

> An unnecessary complication in my view, but maybe that is off-topic here.

Well, speaking of unnecessary complications, maybe the practice of
defining data RRTYPEs with canonical presentation formats that can only
represent a subset of valid on-the-wire RRs ought to be explicitly
banned going forward.

-- 
Robert Edmonds

---

From: Mark Andrews <[email-masked]>
Date: Sat, 12 Mar 2016 09:26:29 +1100

In message <[email-masked]>, Robert Edmonds writes:
> It's clear from the context that 6844 5.1 is talking about the wire
> format, while 5.1.1 is talking about the presentation format. If the

That's only the verifier's opinion (sorry Kathleen).  Master files
are used for zone transfers (see STD 13).  They need to be able to
represent all records.  Master file parsers need know when they are
being presented with garbage or well formed records.  The RFC does
not do that.

Unknown format is for *unknown* records not *know* records.  If the
text representation cannot represent *every* record for that type
then the RFC is *broken*.

If CAA want implementations to use unknown format then the RFC
should say that. [ There are some other DNS type RFC's that could
be updated to say the same thing. ]

Note saying that the canonical format is lower case causes potential
DNSSEC issues if record get written out in canonical form then get
read back in as there is potential for case change which will cause
RRSIGs to no longer match.

> > >     ...
> > >     ...

There are subtle difference between LOC and CAA. While it is
forseeable that we may need to define a different version we have
no idea what that version will be.  For tags we do actually have
ideas about what that could be as we have deliberately choosen to
restrict the syntax of the tag from the set of all known characters.
CAA could have defined the tag to be a UTF-8 string.  CAA could
have defined it to be a arbitary ASCII string.  It could have defined
the canonical presentation format to be a printable lowercase ASCII
string with a prefered syntax of a-z, 0-9 or escaped UTF-8 with A-Z
mapped to a-z.

The record is just plainly poorly defined as different implementors
have different ideas about what is meant to be supported and that
is causing problem.  PKIX needs to fix this.  Once they fix this
the nameserver vendors can fix implementations to match.

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