Re: address prefixes allowed for domain control validation
Peter Bowen wrote: On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson kwil...@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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
On Tue, Mar 24, 2015 at 8:52 PM, Kathleen Wilson kwil...@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/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: address prefixes allowed for domain control validation
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% Regards Robin Alden Comodo smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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 `hostmas...@live.fi`. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: address prefixes allowed for domain control validation
Robin said.. 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% Gerv said.. 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? Yes, exactly so. Of all email-based DCV we do, 69.4% use an email address on the same domain as the certificate is being purchased for (allowing for pruning, too). Of those 69.4%, most use one of those 5 email addresses mentioned in the BRs as detailed above which add up to 61.3% of the total. The difference, being (69.4% - 61.3% =) 8.1% of the total use an email address on the same domain as the certificate but not one of the above 5. This is only permitted when that email address is sourced from WHOIS. #6 on the list is info@ with ~0.5% The rest, being (100% - 69.4% =) 30.6% use email addresses on a different domain, and these are only permitted when that email address is sourced from WHOIS. Do the above percentages include some where the email is sourced from WHOIS but happens to match the permitted five? I think they must include some, yes. I'll see if we have some data to give a ballpark figure as to how often that is the case. Robin smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: address prefixes allowed for domain control validation
On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson kwil...@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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
