[cabf_validation] Authorization Email to Domain Contact

[Doug Beattie]

Well, I was 0 for 4 on that one.  We’re attempting to come up with some new domain validation methods but it’s incredibly hard when we keep getting negative feedback without some concrete recommendations on what would work.

  *   What Opt-in mechanism are you referring to for the use of TXT records?
  *   What CAA semantics or approach are you recommending?  Can you give an example?  I don’t understand how to permit or restrict subdomains with the use of this new email address CAA record at the base domain without needing to populate every subdomain record
  *   If CNAME needs to point to a label that has a CAA record, then why not use CAA directly?  I’m sure I’m missing the point.


From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, April 13, 2018 4:06 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: Quirin Scheitle <scheitle at net.in.tum.de>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Authorization Email to Domain Contact



On Fri, Apr 13, 2018 at 3:38 PM, Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>> wrote:

I like most of the ideas proposed below.
- CAA: Excellent
- email in well-known: Good, assuming we can agree on parsing rules
- TXT record: Good, assuming we can come up with an agreed-to format for the TXT record
- CNAME: don’t like it at all

See more comments inline below


> -----Original Message-----
> From: Validation [mailto:validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>] On Behalf Of
> >
> >> On Thu, Apr 12, 2018 at 1:30 PM, Quirin Scheitle
> <scheitle at net.in.tum.de<mailto:scheitle at net.in.tum.de>> wrote:
> >> The record to be looked up could be the subdomain _dcv or the main
> domain (i.e., the domain name to be validated). The main domain is certainly
> a bad idea for CNAME, and maybe for TXT.
> >> For CAA, I think the main domain could be used.
> >> For CAA, I propose the tag “dcvemail” with the value of the format
> “abc at example.com<mailto:abc at example.com>”
> >>
> > I'm not a fan of overly abbreviated things (I'm guessing you're trying for
> 'domain control validation'?).
>
> Yes. I would think that if it is properly defined in some document, “dcvemail”
> is understandable, but happy to use something else.

For CAA, it seems we can come up with an approach, probably the preferred approach, for allowing a domain owner to enter an email address which will be used as the recipient of the challenge.

We might want to default to only that domain being authorized and suggest a flag "allowSubdomains" which would permit this to be used to approve subdomains and wildcard certificates.  Is that reasonable/desired?

No, I don't think those semantics make sense. CAA has defined semantics for the processing of subdomains - as do the BRs (with respect to the authorization domain name). Layering an additional set of semantics atop that will only add to the difficulty to reason about the security properties, nor would it introduce anything that the system does not already account for.

This would permit the email address to be used for only example.com<http://example.com>:
      example.com<http://example.com>.  domainEmail 0 example at example.com<mailto:example at example.com>

This would allow the email address to be used to approve any/all subdomains of example.com<http://example.com>, including example.com<http://example.com>
      example.com<http://example.com>.  domainEmail 0 example at example.com<mailto:example at example.com> "allowSubdomains"

It sounds like you're proposing introducing a new record type - that's not how CAA records are formatted.



> >
> > With respect to the introduction of any form of subdomain-suitable-for-
> the-base-domain, we have the same problem as the introduction of
> additional constructed email addresses or validation paths (outside of /.well-
> known/pki-validation) any introduction of a new subdomains breaks any
> blacklisting solution, and due to the architecture of today (of email, of DNS,
> of websites), blacklisting is unfortunately the only solution available.
> >
> > Thus, I think there's several preconditions at play here:
> > 1) We need to restrict the underscore prefix usable for existing
> > methods (e.g. "_pki-validation" as the Only Acceptable Label)
> > 2) If we're going to keep abusing TXT records, rather than switching
> > to CAA as we should, we need to define a semantically meaningful
> > format to disambiguate between multiple methods that may wish to allow
> > them

If we use TXT records that contain _pki-validation followed by the email address, is that sufficient structure that DNS admins could limit who can create such records (assuming that is the risk).  For instance:
   _pki-validation example at example.com<mailto:example at example.com>

Note: I was explicitly discouraging such an approach, because that effectively the limits the use of the _pki-validation label to only this method of validation, which requires other validation methods that wish to use TXT records to introduce new labels, which defeats the purpose of providing a whitelisted set of labels.

If we go down that route, then it has to be enforced via opt-in, and cannot be done as an opt-out mechanism (as our current TXT records permit). This is about providing clear, unambiguous semantics, while allowing domain holders to be safe-by-default.

We also need to discuss if this can be used for wildcards or subdomains.  Maybe we need another field to signal that "allowSubdomains", "allowWildcard"
  _pki-validation example at example.com<mailto:example at example.com> "allowSubdomains"

I think this is a good idea.

I do not think this is a good or necessary idea. If you wish to express such semantics, then CAA already provides affordences for allowing that, and in a way that be scoped unambiguously to the CA.

> >> For CNAME, I guess one could make it contain an e-mail address,
> although it certainly is odd.
> >>
> > How? The CNAME contains a host name =)

I'm not a fan of using CNAME to specify email addresses.  We already have TXT and CAA, do we need a 3rd DNS method?

I think this rather misses the point. A CNAME record contains a hostname. The use of CNAME is because "TXT" is an abuse of the DNS system that makes the IETF folks sad (and reasonably so), and also because it's more widely usable than either TXT or CAA in terms of managed DNS providers and software stacks. If anything, this argues for CNAME (which, again, can only contain hostnames) pointing to a label that has a CAA record that contains the additional semantics. And it means this method cannot be used if the DNS provider or software does not support CAA stacks. Understandably, I don't find this worrying, but I imagine that if adopted as such, CAs would quickly realize the difficulty their customers have in deploying. Maybe CAs are ready to take one for the team and help encourage the ecosystem down the right path this time, rather than the expedient path? :)

> Good points. I intentionally said this on high level as I lack experience in the
> typically used definitions of a “sound” email-address :) [I guess CAs must
> have some e-mail soundness checking script for current e-mail validation
> methods].

Don’t we have the same parsing problem now pulling email addresses from who-is?  Regardless, if we can get around that, do we agree that putting an email address in a specific (standardized) file name in the /.well-known/pki-validation directory, is that an acceptable approach?  Bruce suggested the file name auth-email.txt.     It sounds good to me.

Bruce suggested a directory. I was highlighting the flaws, in the hope that proponents will work to address the technical deficiencies (i.e. it's a directory), as well as provide normative requirements as to how CAs process such records (i.e. what standards for expressing / parsing email addresses CAs MUST support)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180413/5183a10f/attachment-0001.html>