[cabf_validation] Authorization Email to Domain Contact

[Ryan Sleevi]

On Fri, Apr 13, 2018 at 3:38 PM, Doug Beattie <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] On Behalf Of
> > >
> > >> On Thu, Apr 12, 2018 at 1:30 PM, Quirin Scheitle
> > <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”
> > >>
> > > 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:
>       example.com.  domainEmail 0 example at example.com
>
> This would allow the email address to be used to approve any/all
> subdomains of example.com, including example.com
>       example.com.  domainEmail 0 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


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 "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/9e3cbcf3/attachment-0001.html>