address prefixes allowed for domain control validation

[Kathleen Wilson]

After reading this:
https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html

I'm thinking we need to update our wiki page:

https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
~~~
For domain-validated SSL certificates, many CAs use an email
challenge-response mechanism to verify that the SSL certificate
subscriber owns/controls the domain to be included in the certificate.
Some CAs allow applicants to select an address from a predetermined list
to be used for this verification.

Offering too many options for the email address prefix increases the
risk of issuing a certificate to a subscriber who does not own/control
the domain. Therefore, the list of email address prefixes should be limited.

Mozilla's recommendation is to limit the set of verification addresses
to the following.

admin@domain
administrator@domain
webmaster@domain
hostmaster@domain
postmaster@domain
Plus any address listed in the technical or administrative contact
field of the domain's WHOIS record, regardless of the addresses' domains.
~~~

What do you all think?

Kathleen

(Note this is also in Baseline Requirements section 11.1.1)

[Peter Bowen]

On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> admin@domain
> administrator@domain
> webmaster@domain
> hostmaster@domain
> postmaster@domain
>

> What do you all think?
>

> (Note this is also in Baseline Requirements section 11.1.1)

It is hard to know which to remove without any data on how customers
are using these today. I would guess that admin & administrator are
the more problematic ones, as they are not covered in any RFCs. The
other three are in http://tools.ietf.org/html/rfc2142.

I wonder if some CAs who use email authentication could provide
statistics on what percent of customers choose each option. If they
don't want to publicly disclose that they are releasing the data, but
are willing to have it shared, maybe they could sent it to Kathleen to
be posted. That would help determine whether any of these email
addresses are rarely being used for validation.

Thanks,
Peter

[Kurt Roeckx]

On 2015-03-23 00:18, Kathleen Wilson wrote:
> admin@domain
> administrator@domain

I've seen a few stories like this. I think they all used either admin
or administrator. So I recommend not to allow those. They also don't
show up in a default /etc/aliases file while the other 3 do.

> Plus any address listed in the technical or administrative contact
> field of the domain's WHOIS record, regardless of the addresses' domains.

If I look up my own domain, there is a "Registrar Technical Contacts",
or just "Technical" which is also about the registrar, but no details
about the registrant (me), unless you go to the website. I do not
expect the registrar to have the ability to create a certificate for my
domain. For some other domains in .com, .org or .net what you wrote
makes sense, but the whois information you get really depends on the
TLD. So I think you need to be careful how you word it.


Kurt

[Ryan Sleevi]

On Sun, March 22, 2015 4:18 pm, Kathleen Wilson wrote:
> After reading this:
> https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html
>
> I'm thinking we need to update our wiki page:
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
> ~~~
> For domain-validated SSL certificates, many CAs use an email
> challenge-response mechanism to verify that the SSL certificate
> subscriber owns/controls the domain to be included in the certificate.
> Some CAs allow applicants to select an address from a predetermined list
> to be used for this verification.
>
> Offering too many options for the email address prefix increases the
> risk of issuing a certificate to a subscriber who does not own/control
> the domain. Therefore, the list of email address prefixes should be
> limited.
>
> Mozilla's recommendation is to limit the set of verification addresses
> to the following.
>

> admin@domain
> administrator@domain
> webmaster@domain
> hostmaster@domain
> postmaster@domain

> Plus any address listed in the technical or administrative contact
> field of the domain's WHOIS record, regardless of the addresses' domains.

> ~~~

>
> What do you all think?
>

> Kathleen

>
> (Note this is also in Baseline Requirements section 11.1.1)

Hi Kathleen,

I'm slightly concerned with the wording, because it seems to reinforce the
notion that this is a Mozilla policy-specific requirement, rather than the
Baseline Requirements, as you note. It also reinforces the notion of
"Domain-validated" SSL certs, which are simply a marketing term that CAs
have created for BR-complying certs that don't contain organizational
information (which the BRs list as optional, but, if present, must comply
to certain requirements)

The other thing with your proposed wording is that it doesn't handle the
FQDN pruning permitted by 11.1.1 p4. That is, if I apply for
ryan.sleevi.example.com, then a CA is allowed to use {whitelisted
address}@ryan.sleevi.example.com, {whitelisted
address}@sleevi.example.com, or {whitelisted address}@example.com during
the application (as indeed, ryan.sleevi.example.com and sleevi.example.com
may not have MX records)

Because of this, perhaps it might be simpler to word

~~~
Mozilla's Root Inclusion Policy requires that CAs conform to the Baseline
Requirements in the issuance and management of publicly trusted SSL
certificates. This includes the Baseline Requirements' restrictions and
requirements on the use of email as a way of validating and authenticating
certificate requests.

CAs are expected to conform to Section 11.1.1, which restricts the email
addresses that may be used to authenticate the subscriber to information
listed in the "registrant", "technical", or "administrative" WHOIS records
and a selected whitelist of local addresses, which includes local-parts of
"admin", "administrator", "webmaster", "hostmaster", and "postmaster".

A CA that authorizes requests by contacting any other email addresses is
deemed to be non-compliant with Mozilla's Inclusion Policy, non-conforming
to the Baseline Requirements, and may have action taken upon it as
described in "Maintaining Confidence in Included Root Certificates".

CAs are also reminded that this policy extends to any certificates that
are technically capable of issuing SSL certificates and that are not
technically constrained; subordinate CAs that fail to enforce these
requirements reflect upon the issuing CA that certified it.
~~~

Or something to that nature.

I'm totally on board with spelling it out, but the fact is, this is a
Baseline Requirements requirement, and is perhaps the most basic. Any CA
not following this raises serious red flags for the rest of 11.1.1 (the
single most important requirement of the BRs), and raises serious
questions as to the competence of the CA.

[Kathleen Wilson]

Just to be clear... This is the wording copied as-is from the wiki page.
I have not proposed any changes yet -- I'm looking for your input on how
to update this wiki page, and I appreciate the input you all have
provided so far.

Thanks,
Kathleen

[Ryan Sleevi]

On Mon, March 23, 2015 8:36 am, Kathleen Wilson wrote:
> Just to be clear... This is the wording copied as-is from the wiki page.
> I have not proposed any changes yet -- I'm looking for your input on how
> to update this wiki page, and I appreciate the input you all have
> provided so far.
>
> Thanks,
> Kathleen

Right; thanks for pointing that out, as I missed it in the first pass :)

I think the concern would be that it still (presently) reads as
descriptive best practice, rather than proscriptive requirement; that is
"Mozilla's recommendation" seems far less forceful than the reality that
it's part of the Baseline Requirements.

It also omits the "registrant" bits of the WHOIS record, which is valid
under 11.1.1 (and I'm not aware of a reason to restrict it).

There's a separate effort of evangelism; the reality is that this is the
second occurrence in as many weeks (live.fi was a similar case). The
Baseline Requirements have normalized this set of addresses to be
protected since 2012. The CA/B Forum Validation WG is working to provide
similar whitelists (e.g. to restrict the set of file paths on a Web Server
that may be used to induce issuance)

However, for this FAQ, my main advice would be to emphasize that this
isn't a Mozilla recommendation, but a Baseline Requirement, and that
non-compliance of a root (*or* it's subordinates) is reason for action.

There's still plenty of misleading info on resellers' pages, for example:
-
http://account.buyhttp.com/knowledgebase/753/Which-email-address-can-approve-SSL-certificate-order.html
-
http://www.webfusion.co.uk/support/answers/how-can-i-purchase-an-ssl-certificate-633/
- http://www.domainpurpose.com/ssl-faqs.htm#faq11
-
https://www.secure128.com/support-resources/frequently-asked-questions.aspx#q17
(see "What if the WHOIS info for my domain is not right?)

[Gervase Markham]

On 23/03/15 15:50, Ryan Sleevi wrote:
> I think the concern would be that it still (presently) reads as
> descriptive best practice, rather than proscriptive requirement; that is
> "Mozilla's recommendation" seems far less forceful than the reality that
> it's part of the Baseline Requirements.

I think that may be historical, due to the fact that we had this
requirement before the BRs did. But I could be remembering wrong.

> There's a separate effort of evangelism; the reality is that this is the
> second occurrence in as many weeks (live.fi was a similar case). The
> Baseline Requirements have normalized this set of addresses to be
> protected since 2012. The CA/B Forum Validation WG is working to provide
> similar whitelists (e.g. to restrict the set of file paths on a Web Server
> that may be used to induce issuance)

As a historical note, here's a previous time this happened:
https://bugzilla.mozilla.org/show_bug.cgi?id=556468

At that time (2010), we were pushing for a restricted list to be
published by the CAB Forum, and it eventually was published in the BRs -
the five addresses which are accepted today were part of the very first
public draft of the BRs.

Gerv

[Gervase Markham]

On 22/03/15 23:18, Kathleen Wilson wrote:
> I'm thinking we need to update our wiki page:
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs

Well, the current list is in the BRs, so we either need to update the
BRs, or we need to decide that we want to be more stringent than the
BRs. (Which we can do; I'm just enumerating the options.)

The current list is a big improvement on what was possible pre-BRs
(ssladmin@, ssladminstrator@, www@, noc@, root@, ...), and was the
result of Mozilla (and perhaps others; I'd have to check my old email)
pushing for a change after incidents like:
https://bugzilla.mozilla.org/show_bug.cgi?id=556468

It's fairly clear webmaster, hostmaster and postmaster are OK on the
list because they are historic and in RFCs - the question is whether we
need to remove admin@ and/or administrator@. I believe these were added
because they are more Windows-y, but my memory could be failing me.

I wonder if the current publicity will lead all webmail providers to do
a review, and then we won't see any further problems...

Gerv

[Gervase Markham]

On 23/03/15 16:41, Robin Alden wrote:
> That would be nice!

Wouldn't it? :-)

> Of all email-based domain control validation we perform those email
> addresses (on the same domain being applied for) are used as follows:
>
> admin@ 33.9%
> hostmaster@ 7.8%
> webmaster@ 7.6%
> administrator@ 7.5%
> postmaster@ 4.5%

I'm sure there's an obvious reason, but why doesn't this add up to 100%?
Is it because the other validations use an email address sourced from WHOIS?

Do the above percentages include some where the email is sourced from
WHOIS but happens to match the permitted five? Or not?

Gerv

[Peter Bowen]

On Mon, Mar 23, 2015 at 9:41 AM, Robin Alden <ro...@comodo.com> wrote:
>> I wonder if the current publicity will lead all webmail providers to do a
>> review, and then we won't see any further problems...

> That would be nice!
>
> Pertaining to Peter Bowen's suggestion that "some CAs who use email

> authentication could provide statistics on what percent of customers

> choose each option.", Comodo finds that those 5 options are very popular
> with applicants for SSL certificates.

> Of all email-based domain control validation we perform those email
> addresses (on the same domain being applied for) are used as follows:
>
> admin@ 33.9%
> hostmaster@ 7.8%
> webmaster@ 7.6%
> administrator@ 7.5%
> postmaster@ 4.5%

Given that this total is only 61.3%, I assume the other 38.7% are
other mailboxes found in whois data?

Any idea how often admin@ is used without being in whois?

Thanks,
Peter

[Matt Palmer]

On Mon, Mar 23, 2015 at 09:40:08AM +0100, Kurt Roeckx wrote:
> On 2015-03-23 00:18, Kathleen Wilson wrote:
> > admin@domain
> > administrator@domain
>
> I've seen a few stories like this. I think they all used either admin or
> administrator. So I recommend not to allow those. They also don't show up
> in a default /etc/aliases file while the other 3 do.

It has been reported that the `live.fi` mis-issuance involved confirmation
sent to `hostm...@live.fi`.

- Matt

[Kathleen Wilson]

On 3/23/15 8:36 AM, Kathleen Wilson wrote:
> Just to be clear... This is the wording copied as-is from the wiki page.
> I have not proposed any changes yet -- I'm looking for your input on how
> to update this wiki page, and I appreciate the input you all have
> provided so far.
>
> Thanks,
> Kathleen
>
>
> On 3/22/15 4:18 PM, Kathleen Wilson wrote:
>> After reading this:
>> https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html
>>
>>
>>
>> I'm thinking we need to update our wiki page:
>>
>> https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
>>
>>

Thanks to all of you who contributed to this discussion, and thanks to
Ryan for providing the text that the following proposal is based on.

I did not see a lot of support to remove admin@ and administrator@, so
the proposal is to simply point to the BRs as follows.

https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
~~~Proposed Text~~~
Mozilla's CA Certificate Inclusion Policy requires CAs to conform to the
Baseline Requirements (BRs) in the issuance and management of publicly
trusted SSL certificates. This includes the BR restrictions on the use
of email as a way of validating that the certificate subscriber owns or
controls the domain name to be included in the certificate. CAs are
expected to conform to BR Section 11.1.1, which restricts the email

addresses that may be used to authenticate the subscriber to information
listed in the "registrant", "technical", or "administrative" WHOIS
records and a selected whitelist of local addresses, which includes
local-parts of "admin", "administrator", "webmaster", "hostmaster", and
"postmaster".

A CA that authorizes certificate subscribers by contacting any other
email addresses is deemed to be non-compliant with Mozilla's CA
Certificate Inclusion Policy and non-conforming to the Baseline

Requirements, and may have action taken upon it as described in

Mozilla's CA Certificate Enforcement Policy. CAs are also reminded that
Mozilla's CA Certificate Policy and the Baseline Requirements extend to

any certificates that are technically capable of issuing SSL

certificates, and subordinate CAs that fail to follow these requirements

reflect upon the issuing CA that certified it.

~~~~

Thanks,
Kathleen

[Anne van Kesteren]

On Tue, Mar 24, 2015 at 8:52 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> ... which includes local-parts of "admin", ...

Perhaps better as "which are limited to" or some such? Includes makes
it sound non-exhaustive.


--
https://annevankesteren.nl/

[Michael Ströder]

Peter Bowen wrote:
> On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>> admin@domain
>> administrator@domain
>> webmaster@domain
>> hostmaster@domain
>> postmaster@domain
>>
>> What do you all think?
>>
>> (Note this is also in Baseline Requirements section 11.1.1)
>
> It is hard to know which to remove without any data on how customers
> are using these today. I would guess that admin & administrator are
> the more problematic ones, as they are not covered in any RFCs. The
> other three are in http://tools.ietf.org/html/rfc2142.

Sorry for the late reply.

But the main problem in the cases mentioned before was that one of those local
parts could be freely chosen for the domain. So the really hard requirement
is: The domain owner must blacklist all those white-listed local parts when
users can choose their e-mail address for a domain. The CA cannot do much
about it.

If one thinks about removing some of the local parts from the white-list the
hope is to raise the *likelihood* that the local part is already blocked by
the true domain owner and cannot be freely chosen. Ideally if a CA sends a
challenge to such an administrative e-mail address a cautious admin could
notice a possible fraud and additionally inform the CA what's going on.

Hmm, relying on one admin e-mail alias seems to be not really sufficient. So
how about sending separate validation challenge e-mails to more than one of
those white-list addresses? This would also raise the likelihood of hitting a
reserver mailbox.
How about requiring three challenge mails to admin mailbox addresses?
Or how about an even broader weighted list and a minimum treshold?

Being domain owner I would not mind the extra work grabbing more than one
e-mail from my domain admin catch-all mailbox.

Ciao, Michael.