Re: [DNSOP] meaning of tag "match" for CAA RDATA
> On 8 Feb 2018, at 9:43 am, Mark Andrews 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. 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. > -- > 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 -- 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
Re: [DNSOP] meaning of tag "match" for CAA RDATA
> On 8 Feb 2018, at 9:15 am, 神明達哉 wrote: > > At Thu, 8 Feb 2018 08:25:35 +1100, > Mark Andrews wrote: > >>> 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. > [...] >>> 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). >> >> 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. > > 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: > > Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower > case. > > 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 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. -- 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
Re: [DNSOP] meaning of tag "match" for CAA RDATA
At Thu, 8 Feb 2018 08:25:35 +1100, Mark Andrews wrote: > > 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. [...] > > 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). > > 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. 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: Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meaning of tag "match" for CAA RDATA
> On 8 Feb 2018, at 3:26 am, 神明達哉 wrote: > > 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). 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. > It may also be related to Section 5.1.1, which states: > > The canonical presentation format of the CAA record is: > > CAA > [...] > 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. 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 > points? The CA's can deduplicate if they need to after performing DNSSEC validation. > Thanks, > > -- > JINMEI, Tatuya > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
[DNSOP] meaning of tag "match" for CAA RDATA
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 [...] 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
