[cabf_validation] Using 3.2.2.4.2/.3 for future domains
Dimitris Zacharopoulos
jimmy at it.auth.gr
Fri Mar 16 05:06:11 MST 2018
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.
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.
> ...
> ...
> 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?
>>
>> 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.
>
This is a different topic but as long as Public Key X arrives at a
future step with a high level of assurance that it comes from the
already validated and authorized Applicant Representative for Domains Y
and Z, then we should be fine.
>>
>> 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.
>>
>> 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 was confirmed as a possible improvement in Herndon as well.
>> 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 :)
>> .
>>
>> 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.
>> 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.
>>
>> 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" 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") for
Domain Z and Domain W.
>> 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.
>
We should not depend on just any Applicant but verify the authority of
that Applicant by using Authorized Representative information, just like
we would do with other methods. The only difference here is that it
would be safe to use Authorized Representative information for
previously validated Domains that belong to the same Domain Owner (i.e.
"the same" in the sense that all Registrant Information is equal in the
WHOIS Domain Z and Domain W record).
>>
>> 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.
>
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.
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/ef069148/attachment-0001.html>
More information about the Validation
mailing list