[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