Re: [lamps] New draft: rfc6844bis

[Quirin Scheitle <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm