[cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi]

On Tue, Jan 23, 2018 at 5:10 PM, Ryan Sleevi <sleevi at google.com> wrote:

> The issue Geoff highlighted only manifests to the extent you've already
> performed the domain validation.
>
> If you use Methods 2 through 10 to perform the domain validation, then
> you've already ensured that the domain is authorized to a minimal level.
> The only extent then to which 3.2.5 matters is whether or not it can permit
> OV issuance, since we've already met the bar for DV issuance.
>
> However, when you use 3.2.5 with DV, as 3.2.2.4.1 does, all of this falls
> apart as terribly insecure.
>

To clarify: Using 3.2.5 to validate domain authorization (as 3.2.2.4.1
does). That is, regardless of DV, OV, or EV certificate types, if 3.2.2.4.1
was used to validate the domain in conjunction with 3.2.5, then it provides
a weaker level of assurance than all other methods about the actual
authorization of the request.


>
> That's the fundamentally different level of assurance that .1 provides (or
> more aptly, doesn't), compared to the other methods (ignoring .5)
>
> The hierarchy is such that it's something like
> .5 (Completely inadequate)
> .1 (Mostly inadequate, modulo the case permitted by 218 - but in this
> case, completely)
> .6, .8, .9, .10 (Problematic in some identified scenarios, not full proof
> of domain authorization as written, although it's possible to improve
> and/or mitigate)
> .2 (Potentially problematic in the postal mail and fax usage)
> .7
> .3, .4
>
> In terms of determining that the domain administrator has authorized the
> request and has ability to ensure that the request is authorized.
>
> On Tue, Jan 23, 2018 at 5:00 PM, Bruce Morton via Public <
> public at cabforum.org> wrote:
>
>> Please note that BR 3.2.5 needs to be performed for all OV certificates
>> regardless of the domain validation method. I am not sure that your attack
>> is Method 1 specific as it could be used against Methods 2 through 10 as
>> well.
>>
>> I am open to improving BR 3.2.5, but we have found that using the
>> verified phone number for the Applicant is a Reliable Method of
>> Communication.
>>
>> Bruce.
>>
>> -----Original Message-----
>> From: geoffk at apple.com [mailto:geoffk at apple.com]
>> Sent: January 23, 2018 4:44 PM
>> To: Jonathan Rudenberg <jonathan at titanous.com>; CA/Browser Forum Public
>> Discussion List <public at cabforum.org>
>> Cc: Bruce Morton <Bruce.Morton at entrustdatacard.com>
>> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and
>> Domain Authorization Document
>>
>>
>>
>> > On Jan 23, 2018, at 12:50 PM, Jonathan Rudenberg via Public <
>> public at cabforum.org> wrote:
>> >
>> >
>> >> On Jan 23, 2018, at 14:36, Bruce Morton <Bruce.Morton at entrustdatacard.
>> com> wrote:
>> >>
>> >> Hi Jonathan,
>> >>
>> >> Please note that the domain validation methods under BR 3.2.2.4 are
>> introduced as follows:  "This section defines the permitted processes and
>> procedures for validating the Applicant's ownership *or* control of the
>> domain."  There is no requirement of proving both domain ownership and
>> control, and proving only domain control has its own security
>> vulnerabilities.
>> >
>> > The method you’ve described does not establish domain ownership either.
>> All it establishes it that you asked for an attacker-controlled name at a
>> phone number from a potentially attacker-controlled third-party database
>> record that matches some fields in the WHOIS data.
>> >
>> >> Finally we do 3.2.5, the authorization to issue check. We do not use
>> the information from WHOIS to perform this check. The reason is most
>> information is provided by the Registrant, so using it would be considered
>> allowing self-validation. This information may be OK to use to show domain
>> control, but should not be used for authorization to issue. As such, we
>> call the Applicant, which also owns the domain to confirm authorization to
>> issue. You say that the Applicant Authorization Contact does not control
>> the domain and you are probably right. Actually, we think that the
>> Applicant Technical Contact controls the domain. We don't want to contact
>> the Applicant Technical Contact as again, this would be self-verification.
>> Also, in many cases, the Applicant Technical Contact is a contractor or
>> hoster and should not verify authorization to issue. We use a phone number
>> found in a QIIS to contact the Applicant. This verifies that the Applicant
>> Authorization Contact is employed by the Applicant and the CA relies on
>> their authority.
>> >
>> > There are a lot of assumptions being made here that don’t fit the
>> adversarial threat model of the WebPKI. Just because someone is routable
>> via an arbitrary phone number does not indicate that they are the domain
>> owner or even employed by the entity that you believe is associated with
>> the phone number.
>>
>> Yes.  Many companies have publicly accessible phones which can be reached
>> from their central switchboard—emergency phones, publicly accessible
>> conference room phones, that kind of thing.  So all you have to do is get
>> to one of them, call up the switchboard, and say “I’m expecting a call from
>> XXX, and I’m here in this conference room, can you put it through?”.
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180123/c2679af8/attachment-0003.html>