[cabf_validation] Using 3.2.2.4.2/.3 for future domains
Dimitris Zacharopoulos
jimmy at it.auth.gr
Fri Mar 16 06:25:15 MST 2018
On 16/3/2018 2:27 μμ, Ryan Sleevi wrote:
>
>
> On Fri, Mar 16, 2018 at 8:06 AM, Dimitris Zacharopoulos
> <jimmy at it.auth.gr <mailto: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
> <http://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
>> <mailto: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 <http://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.
I have already sent out the minutes
<https://cabforum.org/pipermail/validation/2018-March/000752.html> for
the Method 1 discussion that took place during the Validation Working
Group Summit. I don't know if other note takers will do the same for
other methods but I compiled the minutes for method 1 in order for this
discussion to take into consideration what was discussed at the F2F
during the Working Group day. This doesn't go through the approval
process of the CA/B Forum regular days.
>
>
>
>> ...
>> ...
>> 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 <http://example.com>:
>>
>> Domain Name: EXAMPLE.COM <http://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
>> <mailto:emailaddress at example.com>
>>
>> The CA uses the WHOIS information of example.com
>> <http://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 <http://example2.com>. The Whois record for
>> example2.com <http://example2.com> looks exactly the same as
>> example.com <http://example.com>.
>>
>> Domain Name: EXAMPLE2.COM <http://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
>> <mailto:emailaddress at example.com>
>>
>> We can reasonably assume that the Domain Owners of
>> example.com <http://example.com> and example2.com
>> <http://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"
>> <mailto:certificate-authorizations at example.com>) to be the
>> Authorized Representative for EXAMPLE LLC.
>>
>> Since we reasonably established that example.com
>> <http://example.com> and example2.com <http://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"
>> <mailto:certificate-authorizations at example.com> as an
>> Authorized Representative contact for example2.com
>> <http://example2.com>.
>>
>> We are not saying CAs should automatically issue a
>> certificate for example2.com <http://example2.com> to an
>> unknown Applicant. In the scenario I just described, an
>> Applicant for example2.com <http://example2.com> would need
>> to positively respond to an Authorization e-mail sent to
>> "certificate-authorizations at example.com"
>> <mailto: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 <mailto:hostmaster at example.com>
>>> and say “Will you approve Bob to get a certificate for
>>> _any_ domain which has hostmaster at example.com
>>> <mailto: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
>>> <mailto: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
>>> <mailto:hostmaster at example.com> and ask them if
>>> they approve issuance for example.com
>>> <http://example.com>, and if they further
>>> approve issuance for future domains with a
>>> who-is contact listed as hostmaster at example.com
>>> <mailto: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 <http://example.com/>' could be
>>> interpreted as future authorization (for up to 825
>>> days) for 'example.net <http://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
>>> <http://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"
> <mailto: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"
> <mailto: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
> <mailto: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.
>
That sounds different to what I was trying to say. I said that the CA
would still need to send an authorization for each new Domain (Z and W)
to "certificate-authorizations at example.com". For Domain Y, the Domain
Contract information is the same as Domain Z and Domain W. They
practically represent the same Domain Owner that ultimately signs the
Subscriber Agreement and is bound by the Terms of Use.
> 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.
The "Applicant Representative" IS the same for all these Domains. They
share exactly the same Domain Contact information. They are
indistinguishable at DV level.
I still can't see a threat here, but I am merely stating my point of
view. I'm not saying that my interpretation is the correct one and yours
is not.
> 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.
+1.
One goal is to strengthen validation methods, another goal is to provide
similar level of assurance more efficiently for involved parties.
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/afed9bf7/attachment-0001.html>
More information about the Validation
mailing list