[Servercert-wg] Ballot SC4 - email and CAA CONTACT

[Ryan Sleevi]

Tim,

Thanks for sending this around. As mentioned in our NO vote, there's still
a lot of opportunity to improve here. I'd like to revisit whether this
makes sense to split into CAA and TXT ballots separately - it seems that
splitting this may resolve some of the technical challenges, and allow a
more proper discussion about the relative merits. This is especially
important given the tradeoffs between the TXT and CAA methods.

Given the warning you've placed on the Github version, it's unclear whether
you're opposed to receiving feedback through that mechanism. I'm hoping you
can clarify. The lack of a pull request suggests you would NOT like
feedback to be echo'd on GitHub, where it can be more clearly provided.

> The CA MUST send the email to an email address found in the CAA Contact
property record of the Authorization Domain Name as defined in Appendix B.

Suggestion: As .13 and .14 define different validation methods, these
should be separate appendices. This especially is to avoid confusion
related to the domain hierarchy (captured later in this email)

> Each email MAY confirm control of multiple FQDNs, provided the email
address used is a DNS contact email address for each ADN being validated.

I think this is ambiguous as to the intent. One reading of this is to
suggest that every ADN must use the same method (e.g. "published in DNS"),
while another reading may suggest allowing some permutation or set of
combinations for validation (e.g. 3.2.2.4.13, 3.2.2.4.2, 3.2.2.4.14). This
is due to the ambiguity of the term "DNS contact email address", and its
reuse within both sections .13 and .14 (but omission from .2 and .4).
What's the expected set of combinations permitted, and then we can figure
out how to clarify that with the language?

> The Random Value SHALL be unique in each email. The email MAY be re-sent
in its entirety, including the re-use of the Random Value, provided that
its entire contents and recipient SHALL remain unchanged. The Random Value
SHALL remain valid for use in a confirming response for no more than 30
days from its creation. The CPS MAY specify a shorter validity period for
Random Values.

The text provided deviates from 3.2.2.4.2 and 3.2.2.4.4 for non-obvious
reasons, including one subtle but potentially meaningful change. On a
formatting perspective, you've reformatted this language, making it harder
to compare the two for differences. Had they been aligned, it might be
clearer that the phrase "in which case, the CA MUST follow its CPS" has
been omitted from this section as compared to the other sections. Was that
intentional?

Appendix B:

> An SMTP email address

I believe this is attempting to borrow from the language of RFC 6844, but
unfortunately conflates some terms to create a new one. RFC 6844 states
that "an SMTP email that is submitted to the mail address specified.".
Notably, the term here is mail address, and the mechanism for delivering to
that address is SMTP within 6844. You'll find the phrase "SMTP email
address" does not appear in any IETF documents, whereas the term used by
most documents that are meaning to indicate this are noted as "Internet
mail address", reflecting the language in RFC 5322 which defines "The
Internet addr-spec address" in section 3.4.1.

Regarding TXT, there's several issues that I think merit separating out
these ballots, in order to achieve the desired expediency in adoption (of
at least the CAA method)

1) Structurally, this has the same issues of SHA-1 and RSA-1024 - namely,
it sets out a claim "Some systems still do not have sufficient support for
CAA records", without describing a system for measuring or quantifying that
support. As we saw with "some systems do not support SHA-1", setting forth
a claim like this - without a means to quantify - quickly sets it up for
cargo culting and superstition. If the goal is to ensure that this remains
'legacy', then we should have some means to quantify these systems, as well
as provide more proactive measurements to address these. For example, if a
customer supports CAA, but chooses to use TXT, is it a violation? Why or
why not?

As discussed previously, requiring concrete information - either from the
Applicant or the CA - to assess claims of legacy support is vital to being
able to eventually retire this method, in favor of its more well-specified
alternative. I thought it best to first pose this position, to see if we're
in agreement about the concerns and goals, before attempting to propose
text for a solution.

2) The format of the record is ambiguous.

One reading is to think that a TXT record exists at _caa_contact that uses
the "attr=val" format of RFC 1464, namely:
_caa_contact.example.com IN TXT "domain-authorization-email=foo at example.net"

Another reading is to think that the TXT record exists outside the
constraints suggested of RFC 1464, and instead is
domain-authorization-email._caa_contact.example.com IN TXT "foo at example.net"

One way to reduce this ambiguity is by consistently using the terminology
from RFC 7719. For example, if the latter interpretation is intended, "The
DNS TXT record label MUST be named "domain-authorization-email", and MUST
be a subdomain of the "_caa_contact" subdomain of the FQDN being validated."

3) If the latter interpretation is correct, this would be the first method
that permits validation at two levels deeper than the FQDN (namely,
"domain-authorization-email._caa_contact.FQDN") versus the other methods,
that only permit 0-or-1 levels deeper (either CAA/CNAME or "label.FQDN" for
TXT). The implications of this to existing systems seems...
under-documented, at best, considering that it can lead to new issuance.
What investigations have you done to ensure that this is safe for existing
systems, and what outreach to domain operators has been done? As was shown
with .9 and .10, it's entirely possible that this design is fundamentally
insecure in its assumptions, so understanding what evidence exists of its
reasonableness is important.


On Fri, Aug 3, 2018 at 5:05 PM Wayne Thayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> On Fri, Aug 3, 2018 at 2:01 PM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
>> Does changing that noun phrase to Authorization Domain Name address your
>> concern?
>>
>>
>> Yes, that fixes the issue.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180806/e7cf1318/attachment.html>