Subject: [lamps] AD Review: draft-ietf-lamps-rfc6844bis-04

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Dec 2018 13:32:45 -0800

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5745

IMPORTANT
S 3.
>      property entry authorizes the holder of the domain name <Issuer
>      Domain Name> or a party acting under the explicit authority of the
>      holder of that domain name to issue wildcard certificates for the
>      domain in which the property is published.
>
>      iodef <URL> : Specifies a URL to which an issuer MAY report

I know that this seems nitpicky, but the rules here seem
underspecified. Specifically,  you don't say that you can't issue of
neither "issue" nor "issuewild" is present. Also, see below.

S 4.1.
>   4.1.  Use of DNS Security
>
>      Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not
>      required.  An issuer MUST NOT issue certificates if doing so would
>      conflict with the relevant CAA Resource Record set, irrespective of
>      whether the corresponding DNS records are signed.

what if I get a bogus record set which would preclude signing?

S 5.3.
>
>   5.3.  CAA issuewild Property
>
>      The issuewild property has the same syntax and semantics as the issue
>      property except that issuewild properties only grant authorization to
>      issue certificates that specify a wildcard domain and issuewild

say we have "issuewild" for "example.com", I know I can issue for
"*.example.com", but how about "*.a.example.com"

S 5.3.
>
>      The issuewild property has the same syntax and semantics as the issue
>      property except that issuewild properties only grant authorization to
>      issue certificates that specify a wildcard domain and issuewild
>      properties take precedence over issue properties when specified.
>      Specifically:

Wait, are you saying that "issue" allows wildcard issuance?

S 5.3.
>      issue certificates that specify a wildcard domain and issuewild
>      properties take precedence over issue properties when specified.
>      Specifically:
>
>      issuewild properties MUST be ignored when processing a request for a
>      domain that is not a wildcard domain.

What's the reasoning for this? In general, it seems like a wildcard
domain is more powerful than a non-wildcard.

COMMENTS
S 1.
>      sufficient condition for issuance of a certificate.  Before issuing a
>      certificate, a PKIX CA is required to validate the request according
>      to the policies set out in its Certificate Policy.  In the case of a
>      public CA that validates certificate requests as a third party, the
>      certificate will typically be issued under a public trust anchor
>      certificate embedded in one or more relevant Relying Applications.

These two sentences don't really connect, as the Policy may just say
nothing about CAA.

S 2.1.
>   2.  Definitions
>   2.1.  Requirements Language
>
>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>      document are to be interpreted as described in [RFC2119].

This needs to be updated to RFC 8174.

S 2.2.
>      Certification Practices Statement (CPS): Specifies the means by which
>      the criteria of the Certificate Policy are met.  In most cases, this
>      will be the document against which the operations of the
>      Certification Authority are audited.  See [RFC3647].
>
>      Domain: A DNS Domain Name.

This probably needs a cite.

S 3.
>
>      issue <Issuer Domain Name> [; <name>=<value> ]* : The issue property
>      entry authorizes the holder of the domain name <Issuer Domain Name>
>      or a party acting under the explicit authority of the holder of that
>      domain name to issue certificates for the domain in which the
>      property is published.

How about for subdomains?

S 3.
>
>      issuewild <Issuer Domain Name> [; <name>=<value> ]* : The issuewild
>      property entry authorizes the holder of the domain name <Issuer
>      Domain Name> or a party acting under the explicit authority of the
>      holder of that domain name to issue wildcard certificates for the
>      domain in which the property is published.

This is not entirely clear. Say the CAA is at a.example.com, I assume
that this means I can issue wildcards for "*.x.example.com" not
"*example.com"

S 7.1.
>      This generally manifests as a timed-out DNS query, or a SERVFAIL at a
>      local recursive resolver.
>
>      For deployability of CAA and future DNS record types, middleboxes
>      SHOULD block DNS packets by volume and size rather than by query
>      type.

This sentence doesn't seem appropriate for a doc in a SEC WG.

S 7.2.
>      Some authoritative nameservers respond with REJECTED or NOTIMP when
>      queried for a resource record type they do not recognize.  At least
>      one authoritative resolver produces a malformed response (with the QR
>      bit set to 0) when queried for unknown resource record types.  Per
>      RFC 1034, the correct response for unknown resource record types is
>      NOERROR.

What is the reader supposed to do with this sxn?

S 7.4.
>      case queries, also known as DNS 0x20, are used by some recursive
>      resolvers to increase resilience against DNS poisoning attacks.
>      DNSSEC-signing authoritative resolvers are expected to copy the same
>      capitalization from the query into their ANSWER section, but sign the
>      response as if they had use all lowercase.  In particular, PowerDNS
>      versions prior to 4.0.4 had this bug.

I'm not sure what I'm supposed to do with this section either. What's
the take-home?

S 10.
>   10.  Acknowledgements
>
>      The authors would like to thank the following people who contributed
>      to the design and documentation of this work item: Tim Hollebeek,
>      Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul
>      Hoffman, Stephen Kent, Adam Langley, Ben Laurie, James Manager, Chris

Is this by any chance "James Manger"