Subject: Re: [lamps] New draft: rfc6844bis

From: Quirin Scheitle <[email-masked]>
Date: Tue, 5 Jun 2018 09:49:06 +0200

Hi Jacob,

thank you for posting this! I have some specific suggestions to add, which might or might not be “too late” in the process. If they are, we can discuss them for some future version. 
(These are taken from our study under https://caastudy.github.io, but prepared in a format more suited to direct discussion on the list)

1) IODEF  ######################

We argue that iodef notification for both failed and successful certificate issuances should be a MUST. 
It provides domain name holders with the ability to quickly react to attacks. 
Reliability can be assured by providing email addresses at different providers. 
Emails should include all related DNS replies. 
Currently, CAs SHOULD notify iodef contacts in case of rejected issuance. 
In our issuance experiments back in Oct’17, during which we checked CAA practices of 12 CAs, we have not received any notification for dozens of failed issuances. 

2) DNSSEC  ######################

This is quite controversial, and the additional concerns raised in RFC6844bis sound like a genuine problem.  
I am hugely in favour of requiring *validation* of DNSSEC where it exists (i.e., a trust chain down from the ICANN root exists).
Our numbers indicated that among CAA-enabled domains, DNSSEC failures were extraordinarily rare, however the specific concern raised in RFC6844bis would require more large-scale measurement to empirically prove/disprove.
I still *believe* that the benefits of making DNSSEC validation mandatory would defeat the alleged downsides, but do not have the facts to disprove these recent concerns.
(Note: I only speak of requiring valid DNSSEC signatures for domains that have decided to actively and correctly deploy DNSSEC to the ICANN root. 
This would not introduce a requirement or domain owners to deploy DNSSEC.)
Tabling this for “later” might be a good option, but I would still love to see this as a strategic goal for CAA.

3) Validation Type   ######################

We suggest a tag (i.e., not a parameter) to permit domain-level control of permitted/restricted validation methods. E.g., an entry such as 

  tum.de 0 CAA 128 dcv "dns-cname"
  tum.de 0 CAA 128 dcv "domain-contact-postal"

would permit dns-cname and domain-contact-postal methods. An entry such as 

  tum.de 0 CAA 128 nodcv "tls-sni”

would restrict the tls-sni method, but permit all others. 
A mapping of BR/ACME defined methods to usable names would have to be conceived. 
This could have helped in the TLS-SNI problem a couple of months ago. 

4) Validation Level    ######################

We suggest a tag to define a minimum validation level. E.g., 
	tum.de 0 CAA 128 vlevel "ov"
In this example, the validation level tag vlevel would specify
that for tum.de, only OV or EV certificates may be issued.
This could, e.g. be used by domain name holders that exclusively
obtain EV certificates, such as financial institutions,
to proactively close the attack surface of DV methods.

5) Name Server Inconsistencies   ######################

We have confirmed that non-trivial amounts of domains run inconsistent
name servers [1], that CAs usually only check one name
server, and that this affects certificate issuance. 
We think it would be beneficial to explicitly state a strategy 
of dealing with name server inconsistency. 
This should be done carefully, as such a strategy can quickly become arbitrarily complex.

A simple strategy might be to explicitly state that CAs will query only one
name server and that domain name holders must assure name
server consistency to achieve security goals. A different, more
complex strategy might be to query all name servers, and
block issuance if not all name servers permit issuance. 

#########

I hope that we can have a fruitful discussion around these, 
and if too late for RFC6844bis, develop a good understanding 
if some of these should be future goals.

Kind regards
Quirin

[1] cf. https://caastudy.github.io, Figure "CAA name server inconsistencies”, 1841 base domains with inconsistent name servers as of Jun 3, 2018

> On 31. May 2018, at 20:46, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> Hi all,
> 
> I've uploaded rfc6844bis (https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00), which is the WG version of https://tools.ietf.org/html/draft-hoffman-andrews-caa-simplification-03. Differences versus the last draft:
> 
> - Adopted Corey's improved ABNF grammar, which also allows hyphens in property names, and spaces around the equal signs in properties.
> - Clarified how to handle CAA RRsets that have no issue or issuewild tags, but do have other CAA tags. Thanks for the proposal on this, Corey!
> - Added a "Differences vs RFC 6844" section.
> - Emptied the IANA Considerations section, which was copied from RFC6844 but irrelevant because the values in it had already been registered with IANA.
> - Added a section to "Deployment Considerations" regarding private nameservers.
> - Improved the wording of "Bogus DNSSEC Responses" section (under "Deployment Considerations").
> 
> If you would like to read the individual commits, they are available at https://github.com/jsha/caa-simplification/commits/master.
> 
> Thanks,
> Jacob
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 5 Jun 2018 06:02:42 -0400

On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle <[email-masked]>
wrote:

> We suggest a tag (i.e., not a parameter) to permit domain-level control of
> permitted/restricted validation methods. E.g., an entry such as
>

> to proactively close the attack surface of DV methods.

I am not supportive of either of these as part of 6844-bis.

Both of these concepts are specific to a particular industry and set of
policies (namely, the commercial Web PKI and the CA/Browser Forum
documents), and as such, do not have normative references and are not
standards themselves that can be referenced.

I am supportive of the former, to be defined in the CA/Browser Forum. While
this document might countenance syntax of such an expression, the semantics
of such an expression is inherently tied to the CA/Browser Forum's
validation requirements, and thus exclusively should be viewed in that lens.

I am not supportive of the latter, even in the CA/Browser Forum, as they're
unnecessary expressions of syntax for what can already be achieved via
policy. That is, by restricting the set of CAs that can issue, one can
already restrict the type and nature of certificates issued. For nominal
views of 'high' security, this is the only defensible position - as shown
by the ample OV and EV misissuance of CAs.

---

From: Quirin Scheitle <[email-masked]>
Date: Tue, 5 Jun 2018 16:45:52 +0200

> On 5. Jun 2018, at 12:02, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle <[email-masked]> wrote:

Hi Ryan,

thank you for your reply! 

> Both of these concepts are specific to a particular industry and set of policies (namely, the commercial Web PKI and the CA/Browser Forum documents), and as such, do not have normative references and are not standards themselves that can be referenced.

That sounds convincing to me. Happy to move that part (#3 and #4) over to CABF VWG.

> 
> I am supportive of the former, to be defined in the CA/Browser Forum. While this document might countenance syntax of such an expression, the semantics of such an expression is inherently tied to the CA/Browser Forum's validation requirements, and thus exclusively should be viewed in that lens.
> 
> I am not supportive of the latter, even in the CA/Browser Forum, as they're unnecessary expressions of syntax for what can already be achieved via policy. That is, by restricting the set of CAs that can issue, one can already restrict the type and nature of certificates issued. For nominal views of 'high' security, this is the only defensible position - as shown by the ample OV and EV misissuance of CAs.

The way I understand your answer, you imply it would be bad if “vlevel” would be used *instead* of issue/issuewild tags. I full agree to that.
I meant “vlevel” to be an addition to issue/issuewild:
If I am an institution only using EV, and permit only CAs X and Y, attackers could still obtain DV certificates from CAs X or Y. 
With vlevel “ev”, attacks only using DV level would fail. 
[This part of the discussion can also be continued at the VWG, I guess]

Kind regards
Quirin

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 5 Jun 2018 13:19:55 -0400

On Tue, Jun 5, 2018 at 10:45 AM, Quirin Scheitle <[email-masked]>
wrote:

> > We suggest a tag (i.e., not a parameter) to permit domain-level control
> of permitted/restricted validation methods. E.g., an entry such as
> >
> > I am supportive of the former, to be defined in the CA/Browser Forum.
> While this document might countenance syntax of such an expression, the
> semantics of such an expression is inherently tied to the CA/Browser
> Forum's validation requirements, and thus exclusively should be viewed in
> that lens.
> >
> > I am not supportive of the latter, even in the CA/Browser Forum, as
> they're unnecessary expressions of syntax for what can already be achieved
> via policy. That is, by restricting the set of CAs that can issue, one can
> The way I understand your answer, you imply it would be bad if “vlevel”
> would be used *instead* of issue/issuewild tags. I full agree to that.
> If I am an institution only using EV, and permit only CAs X and Y,
> attackers could still obtain DV certificates from CAs X or Y.

Yeah, the CA/Browser Forum requires that CAs support organizations listing
who their certificate approvers are, so if you've limited to CAs X & Y, you
can instruct CAs X & Y to restrict that issuance, and it's a violation if
they don't. Subtle but it exists :)