[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 8:06 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

> On 16/3/2018 11:43 πμ, Ryan Sleevi wrote:
>
> 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 tried to summarize in order to avoid a very long response. I will try to
> explain further so forgive me for the long e-mail.
>
> The main arguments against method 1, as documented in the minutes and from
> the discussions at the F2F, were that a hostile Applicant listed in a QIIS
> as representative of a Company named "Example LLC", located at "Example
> Street, City, Country" could potentially establish a connection with a
> Domain "example.com" that contains Registrant Information Organization
> "Example LLC", located at "Example Street, City, Country" and claim to be
> the Domain Owner. Is this an accurate representation of the main problem of
> method 1?
>
> If this is true, then adding "at a minimum" unique information in the
> Registrant information, bringing it similar to the case of Norway which you
> said would be unambiguously one-to-one between the Registrant and the
> National Registry of Companies in Norway, would be a positive step forward.
>

Yes, but I addressed why that wasn't sufficient, even if we had it.


> Peter proposed something new, that also aligns with the requirement to
> disambiguate legal entities with domain names and re-use the Authorized
> Representative information of the Domain Owner. This is what I described in
> my previous message.
>
> 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?
>
>
> I'll do my best to answer inline.
>
> 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.
>>
>>
> This was a very critical clarification moment at the last F2F. For Domain
> Validation purposes, we clarified what the "Authorized Representative" is
> expected to be, for the Baseline Requirements. Does the description in the
> minutes accurately represent the current expectations of the Baseline
> Requirements? I think it is a fundamental issue for this discussion to
> clarify these expectations.
>

We haven't published (accepted) minutes yet, so I'm cautious to keep citing
minutes here as authortative.


>
>
>
> ...
>> ...
>> 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.
>>
>>
>>
>>
> [...]
>
>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>
>>
> There is general consensus that the Applicant should be treated as hostile
> until proved to be either in control of the Domain or to be the Domain
> Owner. I fully support that the Applicant should be treated originally as
> unauthorized.
>
>
>
>> 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.
>>
>>
> There are reasonable measures we can take to avoid repeating unnecessary
> steps to improve the domain validation process without risking security. In
> your example:
>
> If the Applicant is authorized to assert Public Key X for Domain Y and the
> CA has taken ADDITIONAL validation steps (via 3.2.5) to acquire an
> Authorized Representative for all Certificates that this Organization owns,
> then that same Authorized Representative could approve an assertion of
> Public key X for Domain Z IF-AND-ONLY-IF Domain Z contains the exact same
> Registrant information (organization, address, email contact, phone) as
> Domain Y. Do you think this is reasonably safe?
>

I explained why that weakens the DV model


> 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.
>>
>>
> That was exactly the main problem with method 1 that both proposals
> (adding unique identifiers in a particular jurisdiction and using the
> entire Registrant information) are trying to address.
>

... That's what I said. :)


> 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
>>
>>
> We should remove the affiliations :)
>

And I address why that's not sufficient :)


> 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"
>>
>>
> When I first read the proposal, I had the same first impression but from
> yesterday's discussion at the Validation WG call, it was clear that
> additional requirements were necessary. That's what I tried to highlight in
> my email. If I understood correctly, the intent is that in order for an
> Identity I for Domain Y to be able to authorize issuance for Domain Z, all
> Registrant Information of Domain Z must be equal to the Registrant
> information of Domain Y. I believe this is equally secure as contacting the
> Domain Contact information of Domain Y. You would end up to the same
> Applicant Representative because Domain Contact Y == Domain Contact Z.
>

While you could, I tried to explain why you won't necessarily, and why that
assurance is weaker than all other methods today.


> 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.
>>
>>
> I don't think this is the intended behavior and you are correct
> highlighting the risks. If I understood the proposal correctly, the intend
> is to definitely validate Domain Z, Domain W separately but if Domain Z and
> Domain W have exactly the same Registrant Information as Domain Y (i.e. the
> same Domain Owner), use the Applicant Representative information of Domain
> Y who is effectively the same for all three domains. This means that for
> each new Domain (Domain Z and Domain W), the Applicant Representative would
> get Authorization emails to complete the Domain Validation for Domain Z and
> W.
>

Correct - the Applicant must be contacted to ensure that W and Z are
authorized. Among other reasons, because it triggers legal obligations to
report if that DNS information changes - thus you *must* have the DNS team
involved, since if they change anything, the Certificate team is
responsible for reporting it to the CA. So the entire argument that you can
separate out the DNS and Certificate is a bad argument, because they're
still coupled (via the Subscriber agreement)


> 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.
>>
>>
> I fully agree with the statement that the _current_operator/owner of
> Domain Y must authorize Domain Z and Domain W for a Certificate to be
> issued, if they are owned by the same Owner. If this _current_owner has
> established a secure communication with a CA and has authorized Mr. Foo
> with e-mail address "certificate-authorizations at example.com"
> <certificate-authorizations at example.com> for all Domains owned by that
> Organization, then the CA that matched all the Registrant Information to
> the same Domain Owner could send Authorization e-mails to Mr. Foo (at
> "certificate-authorizations at example.com"
> <certificate-authorizations at example.com>) for Domain Z and Domain W.
>

This is where we disagree. You cannot presume that the previous
authorization for certificate-authorizations at example.com for Domain Y is
able to be extended to Domain Z or Domain W. That implicit assumption is a
weaker security statement than an explicit authorization - least of all
because of the trigger for domain changes.

The distinction here is that while you've asserted the same corporate
identity, you haven't asserted that the Representative you determined for Y
is also valid to be a Representative for Z or W. You can't trust the
Representative to say "Trust me", and you can't treat the existence of the
WHOIS information as a foregone authorization. Even if you have a letter
saying "I authorize all future domains", that's still based on a model of
Applicant-Attacker self-authorizing for future domains, which is a strictly
weaker validation assurance.


> I tried to explain my understanding of the proposal as best as I could :-)
> There are ways to improve the security of processes (and we must continue
> to do so) as long as we are aware of the threats and vulnerabilities of
> existing processes. For example, we talked about route leaks and email
> hijacking as threats and there are so many other threats out there that
> should be re-evaluated. Reasonable compromises must be made to keep the
> balance, and this is always the hardest part.
>

Right, but that doesn't mean that because there are risks to other methods,
we should further regress the level of validation assurance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/1007d54b/attachment-0001.html>