Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT)

[Jacob Hoffman-Andrews <[e-mail]>]

> I'm not entirely sure why we're going "backwards" from referencing STD13
> to referencing RFCs 1034 and 1035 individually (in the definition of
> "Domain Name System").
I'm not actually sure which is preferred here. For instance RFC 5280 
cites RFC 1034: https://tools.ietf.org/html/rfc5280#section-11.1

> Section 3
>
>     RelevantCAASet(domain):
>       for domain is not ".":
>         if CAA(domain) is not Empty:
>           return CAA(domain)
>         domain = Parent(domain)
>       return Empty
>
> It would be nice to get an explicit note about whether this is intended
> to be pseudocode, Python code, etc..  Specifically, the "for domain is
> not '.'" syntax seems like it might be a more natural fit for a "while"
> construct.
Updated to mention it's pseudocode.
>
> Section 4.3
>
>     issuewild properties MUST be ignored when processing a request for a
>     Domain Name (that is, not a Wildcard Domain Name).
>
> I don't wish to revisit well-trodden ground (as I suspect this is), but
> note that the provided defitinions in Section 2.2 don't seem to exclude
> Wildcard Domain Names from being Domain Names, so that "that is" in the
> quoted text is not accurate.  (In particular, note that the Wildcard
> Domain Name definition says that it is "a Domain Name consisting of
> [...]".)

You're right that this is well-trodden ground, but looking at this a 
second time, I realized I had this wrong. A Wildcard Domain Name *is* a 
Fully-Qualified Domain Name, since an asterisk is a valid DNS label 
(it's just not in Preferred Name Syntax per RFC 1034).
> Section 4.5
>
>     The critical flag is intended to permit future versions of CAA to
>     introduce new semantics that MUST be understood for correct
>     processing of the record, preventing conforming CAs that do not
>     recognize the new semantics from issuing certificates for the
>     indicated Domain Names.
>
> It's not clear to me that the normative "MUST" is best, here.  (Is
> anyone's behavior being constrained by this statement?)
The intent here is to express that future versions would be specifying a 
"MUST" here. Open to suggestions about how to better say that.
> Section 5.1
>
>                An Issuer MUST NOT issue certificates if doing so would
>     conflict with the Relevant RRSet, irrespective of whether the
>     corresponding DNS records are signed.
>
> I recognize that this is already the security considerations section,
> but this requirement introduces its own security considerations, namely
> that in cases where CAA responses received by the Issuer can be spoofed,
> there is an opportunity for denial of service.  Section 5.4 does not
> seem to address this additional consideration relating to spoofing.
> Section 5.5 perhaps touches on it, but merely talks about "introduction"
> of a CAA RR, which may or may not imply the possibility of spoofing to
> an arbitrary reader.
Added to 5.5 some language about spoofing.
>
>     Use of DNSSEC allows an Issuer to acquire and archive a proof that
>     they were authorized to issue certificates for the Domain Name.
>     Verification of such archives MAY be an audit requirement to verify
>     CAA record processing compliance.  Publication of such archives MAY
>     be a transparency requirement to verify CAA record processing
>     compliance.
>
> Neither of these "MAY"s seem to be constraining the parties involved in
> this specification, which makes me wonder if they are more appropriate
> as ordinary "may"s.
Done
>
> Section 5.4
>
>              Data cached by third parties MUST NOT be relied on but MAY
>     be used to support additional anti-spoofing or anti-suppression
>     controls.
>
> Is "relied on" meant to imply "relied on as the sole source of DNS CAA
> information"?
Done
>
> Section 8
>
> Should the registration of the 'CAA' RRtype also be updated to refer to
> [this document]?
Done