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: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
