[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

Hi Doug,

It looks like the quoting configuration in your mail client may be messed
up. It's rather hard to notice your replies, and certainly the archives
have trouble with them. It may be worth looking into. Hopefully my inline
replies below will fare better.

On Thu, Mar 15, 2018 at 4:28 PM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

>
>
>
>
> *From:* Validation [mailto:validation-bounces at cabforum.org] *On Behalf Of
> *Peter Bowen via Validation
> *Sent:* Thursday, March 15, 2018 12:52 PM
> *To:* Ryan Sleevi <sleevi at google.com>
> *Cc:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains
>
>
>
> On Mar 15, 2018, at 9:37 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
>
>
> On Thu, Mar 15, 2018 at 12:28 PM, Peter Bowen <pzb at amzn.com> wrote:
>
> From the discussions of CA use cases where they were using 3.2.2.4.1, it
> seems that we might be able to cover a number of these by clarifying
> 3.2.2.4.2/.3.
>
> Specifically, the BRs currently say:
>
> "Each email, fax, SMS, or postal mail MAY confirm control of multiple
> Authorization Domain Names. […] MUST be sent to an email address, fax/SMS
> number, or postal mail address identified as a Domain Contact.”
>
> "Each phone call SHALL be made to a single number and MAY confirm control
> of multiple FQDNs, provided that the phone number is identified by the
> Domain Registrar as a valid contact method for every Base Domain Name being
> verified using the phone call"
>
> What is unclear is whether an an email, fax, SMS, postal mail, or phone
> call MAY be used to confirm approval for an unbounded set of domains names
> which have that method as a contact method.  For example, can a CA email
> hostmaster at example.com and say “Will you approve Bob to get a certificate
> for _any_ domain which has hostmaster at example.com as a Domain Contact,
> including domains not yet registered but which are registered in the future
> with hostmaster at example.com as a Domain Contact?”  This authorization is
> subject the aging requirements already in the BRs.
>
>
>
> Yes, the intent is that if you send an email to hostmaster at example.com
> and ask them if they approve issuance for example.com, and if they
> further approve issuance for future domains with a who-is contact listed as
> hostmaster at example.com, this would be approval for issuance for domains
> that have not been provided to the CA yet, or perhaps for domains that are
> not yet registered.  Yes, this authorization is subject to the aging
> requirements.
>
>
> If this is allowed, it would seem to cover the use case of adding domains
> to an existing applicant/subscriber account without requiring a new
> communication with the domain contact for each domain.  This was the
> primary use case that I heard for 3.2.2.4.1 (1) & (2).
>
>
>
> I suppose this yet again depends on the answer to the question of what are
> we trying to validate?
>
>
>
> I think this would be a net-negative for security and a problematic
> interpretation, if authorization for 'example.com' could be interpreted
> as future authorization (for up to 825 days) for 'example.net'. I
> understand some CAs would like this. I think they're wrong and it's
> insecure, and not what domain holders would or should expect.
>
> The approval to authorize issuance under example.net would only be done
> if they expressly said they wanted approval of new domains.  There are some
> domain owners that would like this model, but I also agree there are some
> that won’t.  They don’t need to provide this approval.
>
>
The "problem" with this model is that you're effectively relying on the
Applicant over the Domain Owner. As discussed in Reston, the presumption
has to be the Applicant is an Attacker and the Domain Holder is the
Defender. Hopefully, the alliterative association will help CAs internalize
this threat model, since it's so key.

In an ideal model, the flow is that you validate the Applicant is
authorized to assert Public Key X for Domain Y in Certificate A as a
hermetic, wholly self-contained step. If you also want to assert Public Key
X for Domain Z, that's effectively a new process. 3.2.2.4.2/.3/.4 allow you
to coalesce that validation across Domains, and 4.2.1 allows you to
amortize/coalesce that validation across Public Keys and Certificates -
that is, reusing the Domain Authorization for multiple distinct
certificates/public keys.

During the discussion of 4.2.1, it's clear that some CAs view the steps as
further segmented - namely, that you validate the Applicant is authorized
(for any public key) for Domain Y as a distinct step, and then later they
can provide the public key. This is the "Do the validation before there's a
CSR" discussion - namely, the Applicant saying "I will request a
certificate for Y and Z" without providing the public key X yet in a CSR.

The challenge with 3.2.2.4.1 (and this model) is that it subverts the
notion further, by treating the Applicant as a reusable entity that doesn't
have to be validated across domains. Namely, once you've validated the
Applicant once, they can reuse this across multiple domains. As we
discussed, this creates serious challenges - the notion of validating the
Applicant as "Stripe Inc (Kentucky)" is great, and may allow you to
validate the issuance for https://stripe.ian.sh , but you certainly don't
want Ian to be able to then request a certificate for "
https://www.stripe.com" simply because you see a substring match for
"Stripe" in the (previously validated) applicant identity of Stripe and the
whois information expressed.

The proposal made in Reston seemed to hinge around the notion that "Imagine
we could unambiguously determine, from the DNS information, the exact legal
identity" - that is, that it would require, *at minimum*, all of the
information within an EV certificate (since we claim that's sufficient to
disambiguate legal identity). We discussed, on a per-TLD basis (that is, no
CA interpretation/flexibility permitted) alternative requirements on a
per-TLD basis - for example, for .no, allowing the registration number
expressed in a .no domain registration to serve as an unambiguous key,
since it ties back to the national registry.

This, of course, would still be insecure - for example, it would allow any
Affiliate of Alphabet (which is a wide portfolio of companies) to obtain
any certificate for any other Alphabet property - so during the Reston
discussions, it was further refined to be an "exact" match - no
affiliations permitted.

If we imagine that system, with its conditions, my understanding of the
current proposal is that once we've validated the Identity I for Domain Y
for Applicant-Attacker A, if we then go look up Domain Z, and see it also
matches Identity I, can we allow the Applicant-Attacker to self-declare
their authorization? The old 3.2.2.4.1 allowed it (insecurely), and the
proposal below seems to be based on a notion of "If the Domain Y holder
opts in, then they can authorize the Applicant-Attacker A for any future
domains, such as Domain Z"

The argument for this goes that, since you know it's Identity I, any
statement they make about Domain Y should logically be able to extend to
Domain Z or Domain W, or Public Key X or Public Key F or any other sort of
dimension, since you're assuming that this Identity I == Applicant-Attacker
X, for any/all domains. The old model was that this presumption was given
by default - 3.2.2.4.1. Under the today's model, it's not possible - you
have to validate a binding of Domain Y and Domain Z and Domain W
"separately", as they're requested. Under this new model, the argument is
being made that the domain holder should be able to "opt-in" to skip
validation for Domain Z and Domain W, based on a WHOIS match, once they've
validated Domain Y. I'm sure the advocates might not call it "skipping"
validation so much as "introducing alternative validation", but such
alternative validation is the semantic equivalent to alternative facts - a
problematic renaming that hides the fact that you are, in fact, skipping an
explicit check for Domain Z and Domain W, on the basis of (at the time of
validation for Z/W) an unrelated Domain Y.

If we expect that the absolute minimum of validations is the expectation
that "The Domain Holder Y has explicitly authorized Applicant to issue any
certificate with any public key, for up to 825 days", then this fails to
achieve that minimum goal - because it's not an explicit authorization,
it's an implicit authorization. Further, as discussed previously on the
list - in the context of 4.2.1 in particular and Ballot 185/186 is general
- even that minimum bar is problematic, and we can/should do better, such
as "The Domain Holder Y has explicitly authorized Applicant to issue any
certificate with Public Key X, for up to 90 days" - to better reflect the
fundamental assertion that TLS clients rely upon - namely, the binding
between the Domain Y and Public Key X, based on the authorization of the
_current_ operator/owner of Domain Y.

This is important to note - this is why the BRs require Subscriber
Agreements to require the Domain Holder Y to notify CAs if they become "the
previous Domain Holder" (c.f. 9.6.3 (1), 9.6.3 (5), 4.9.1.1 (6), 4.9.1.1
(8), 4.9.1.1 (10) ).

This is the crux of why 3.2.2.4.1, in all forms, is problematic - because
it weakens the less-than-ideal-but-still-the-minimum-today level of
assurance (explicit authorization) into a notion of implicit authorization,
on the basis that we trust the Attacker-Applicant A more than the Domain
Holder Y, on the presumption that Identity I is authorized to speak for
Domain Y, Z, and W equally.


>
>
> That is, it's granting retroactive authorization based on unknown facts
> and details when the (previous) authorization was granted, so there's no
> way to be confident that the site operator intended for that authorization
> to be that broadly scoped. Every domain should be authorized through
> contact with the domain holder for that domain, and the authorization
> should be scoped only to that domain. We allow you to batch authorizations
> together (such as .2, .3, .4) in some cases, but that should not be seen as
> a forward grant for all future authorizations. This was part of the problem
> with .1.
>
>
>
> "there's no way to be confident that the site operator intended for that
> authorization to be that broadly scoped.”
>
>
>
> What we have heard from domain registrants is that there are domain
> registrants/contacts who actively do want this level of authorization
> scope.  This is very common for large organizations which have a central
> team that manages certificates for the whole organization but is distinct
> from the team that manages domain registrations.  The organization wants to
> avoid having the registrant team approving each new domain that needs a
> certificate.
>
>
>
> Yes, we have customers that manage a lot of domains and they don’t (yet)
> have the ability to programmatically implement domain validation using one
> of the automated methods for every domain.  It’s much easier for the Domain
> owner to be able to make the one “global” approval and have all new domains
> added to their managed account without being involved in the approval for
> everyone.
>
>
>
> If were to communicate to the Registrant and they said no, they do not
> permit the global forward approval of all domains (as I presume large
> enterprises like Google and Amazon would do), then we would verify each
> domain as they are supplied for validation.  For those that do permit
> approval for all domains, we would be sure that the address/value we used
> to obtain the approval (email/phone/sms/postal address) is the same on any
> future domains.
>

For the reasons above, I think we view this as fundamentally insecure and
an undesirable property compared to the level of assurance that TLS
certificates are minimally expected to provide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180315/d91380c3/attachment-0001.html>