[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

Hi Dimitris,

It doesn't seem you addressed my points, as I explained in the message
you're replying to that what you just described is not safe and not
reasonable. I'm not sure where the confusion is, so perhaps it'd be helpful
if you could highlight where you may not disagree, and we can see if there
was a misunderstanding in the points made?

On Fri, Mar 16, 2018 at 3:35 AM, Dimitris Zacharopoulos via Validation <
validation at cabforum.org> wrote:

>
> From the Validation WG Summit notes:
>
> --- BEGIN QUOTE ---
> All information in the Registrant Information (email, phone, postal
> address) is treated as "Authorized Representative". Even if the Contact
> Person is "IT Center", a call to this number and a dialog like the
> following should suffice for the verification and authorization.
>
> - CA: "I need to reach the IT Center to verify a Certificate Request"
> - Domain Owner: "Yes you have reached the IT Center"
> - CA: "We have received a Public Key (blah blah, hash of the key) for
> Domain example.com. Can you confirm the request and authorize issuance?"
> - Domain Owner: "Yes"
> That's all. Similar to email aliases where we don't know the exact Natural
> Persons in the recipient list, the same applies to the telephone number or
> if using the postal address.
>
> ...
> ...
> The only "true" source of information to be treated as "Valid" is the
> WHOIS (or Registrar/Registry information). This is true because the Domain
> Owner makes sure that the information listed in the Registration Entry is
> accurate and dependable.
>
> To summarize (Dimitris):
>
> - CAs must treat the Applicant as hostile.
> - CAs must trust the Domain Registrant information as the only accurate
> information related to the Domain.
> - CAs must treat the Domain Contact information as a way to contact the
> Authorized Representative that will approve the Request.
>
> - If the Registrant information in the WHOIS data by the Registrar is
> one-to-one with Organizations in a particular jurisdiction (as it happens
> for some ccTLDs), it is a reliable method to establish ownership for the
> Domain.
> - By using the Organization's "Registration Number" in the Domain
> Registrant information for a particular Domain, the CA can find "Authorized
> Representative" for that Organization by looking up Qualified Information
> Sources such as National Company Registries to contact the Domain Owner.
> - Since this is not a globally enforced requirement for Registrars, a
> possible improvement for this method to the level of assurance of methods
> 2, 3, 4, would be to require the Domain Owner to list Registration Number,
> Jurisdiction of Incorporation and address (as required for EV) IN THE
> DOMAIN REGISTRANT record. Therefore, this validation method would ONLY BE
> USED if an unambiguous representation of the Domain Owner was included in
> the Domain Registrant information. The CA would then need to contact the
> Domain Owner by using QGIS/QIIS/QTIS by using the Registration Number and
> Jurisdiction of Incorporation (one-to-one mapping with the Domain Owner)
> and use this information to contact the "Authorized Representative". This
> is an auditable criteria as CAs that use this method to validate domains
> will need to prove to their auditors how they ensure the one-to-one mapping
> between the Domain and the Domain Owner.
> --- END QUOTE ---
>
> While I think adding uniquely identifiable information in the WHOIS
> records is an improvement to the existing method 1 and protects against the
> attacks we discussed in Herndon, Peter proposed something new that could be
> introduced as a new method. Instead of relying only to the name "Stripe
> Inc.", let's match all contact information records to establish the Domain
> Owner.
>
> Whois record for domain example.com:
>
> Domain Name: EXAMPLE.COM
> Registrant Name: IT Department
> Registrant Organization: EXAMPLE LLC
> Registrant Street: 1234 my address,
> Registrant City: My city
> Registrant State/Province: CA
> Registrant Postal Code: 1234
> Registrant Country: US
> Registrant Phone: +123456
> Registrant Phone Ext:
> Registrant Fax: +123456
> Registrant Fax Ext:
> Registrant Email: emailaddress at example.com
>
> The CA uses the WHOIS information of example.com to contact the
> Authorized Representative (using phone, email, mailing address mentioned in
> the whois record).
>
> Now, consider an Applicant that requests a Certificate for example2.com.
> The Whois record for example2.com looks exactly the same as example.com.
>
> Domain Name: EXAMPLE2.COM
> Registrant Name: IT Department
> Registrant Organization: EXAMPLE LLC
> Registrant Street: 1234 my address,
> Registrant City: My city
> Registrant State/Province: CA
> Registrant Postal Code: 1234
> Registrant Country: US
> Registrant Phone: +123456
> Registrant Phone Ext:
> Registrant Fax: +123456
> Registrant Fax Ext:
> Registrant Email: emailaddress at example.com
>
> We can reasonably assume that the Domain Owners of example.com and
> example2.com are the same. I see no reason for an organization/individual
> that seriously wants to properly protect/control their Domain, to include
> bogus information in the Registrant records.
>
> Taking this one step further, once we've established Domain Validation by
> using WHOIS information to contact the Domain Owner (phone, email, mailing
> address), if we do ADDITIONAL verification based on 3.2.5 to establish
> another Applicant Representative based on a QIIS (as Peter suggests for
> large organizations that have a central team that manages certificates for
> the whole organization), we could add a new email contact address (e.g.
> "certificate-authorizations at example.com"
> <certificate-authorizations at example.com>) to be the Authorized
> Representative for EXAMPLE LLC.
>
> Since we reasonably established that example.com and example2.com have
> the same Domain Owner (since whois contact information for both domains are
> the same in all aspects), this means that the CA could use
> "certificate-authorizations at example.com"
> <certificate-authorizations at example.com> as an Authorized Representative
> contact for example2.com.
>
> We are not saying CAs should automatically issue a certificate for
> example2.com to an unknown Applicant. In the scenario I just described,
> an Applicant for example2.com would need to positively respond to an
> Authorization e-mail sent to "certificate-authorizations at example.com"
> <certificate-authorizations at example.com> which looks reasonably safe.
>
>
> Dimitris.
>
>
>
>
>
> On 16/3/2018 5:13 πμ, Ryan Sleevi via Validation wrote:
>
> 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.
>
>
>
>
> _______________________________________________
> Validation mailing listValidation at cabforum.orghttps://cabforum.org/mailman/listinfo/validation
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/7ac884bd/attachment-0001.html>