Thunderbird:Autoconfiguration:Security review General

The security review was a constructive and fruitful discussion

Central db or ISP fetch has precedence?

 I think ISP should have precedence
   because I dislike central octopussy authorities,
   because they always fire back in the long term.
 bwinton preferred MozillaMessaging to control things. 
   His suggestion was to add a "redirect" element feature to the
   config file format. The central database uses this to refer to the
   ISP for all domains for which we have no entry (or even for those
   for which we have an entry). If we dislike the ISP, we remove
   the redirect.
 Advantages (central):
 - able to change URL (but unlikely once deployed)
 - able to override in case it goes wrong for one ISP
 Disadvantages:
 - central authority, power question
 - downtime case
 - bug 537649
 - implementation: redirects are recursive and not trivial in combination
   with async network fetches.

Is SSL critical for config lookup?

DNS MX: Mail delivery between domains happens via DNS MX lookups,
 which are insecure. In other words, an attacker can already
 re-route and intercept new mails. The risk of interception during
 account setup is not larger than that. More importantly:
Guessed configs: An attacker can easily *prevent* connections,
 making the ispdb lookup (via https), isp fetch (via https) and
 heuristics for IMAP SSL servers and IMAP servers with secure auth mechs
 all fail, making us fall back to plaintext auth, and that's it, game over.
 Therefore, lookups via http don't add risk.

Domain hosters and SSL Domain hosters and mail service providers which allow customers to buy their down domain and use that for email. Example: 1und1.de, fastmail.fm, Dreamhost, schlund.de etc. They want to set up an autoconfig server for their customers (incl. customers with their own domain). If we require SSL, we'd need to require that the cert domain matches the email domain, otherwise we'd rely on insecure steps like DNS MX lookups and can just as well drop the SSL requirement. However, it's not feasible for a domain hoster to get a cert for each customer domain. (Not feasible 1. because of verification processes and costs and 2. because of the SSL requirement to have one IP address per cert. Neither domain-wildcard certs nor certs listing several domains are applicable here.)

So, we don't see a way to both support domain hosters and enforce the SSL requirement (and it being meaningful). Given that we think that domain hosters are an important case, and attackers can circumvent SSL anyways (see above), we'll drop SSL and allow http for ISP config looksup. I don't like it at all, but I don't see an alternative.

(Note that trying SSL first and then falling back to http is snake oil / false sense of security, because an attacker can always prevent the https-connection, and there's no sensitive information in the config file either.)

However, dropping the SSL requirement allows us to include other mechanisms like DNS SRV or MX records which could prove very useful (but not part of this bug). E.g. if a domain has a DNS SRV entry for _imap, we use that. Or if a MX for bucksch.com points to mx.fastmail.fm, we could restart config lookup with fastmail.fm as domain. References: Bug 342242, <http://tools.ietf.org/html/draft-daboo-srv-email>

re http[s]://autconfig.<domain>/ and philor's concern that somebody at a subdomain hoster (e.g. dreamhost handing out benbucksch.dreamhost.com to me) might grab autoconfig.<domain>: I already argued that we have the same problem with imap.<domain>. philor responded that imap. is a well-known name and is hopefully blocked for registration. I think that autoconfig can just as well become such a well-known block, but philor didn't buy that. However, Microsoft Outlook does exactly the same, they use http://autodiscover.<domain>/... . I am not aware of any incidents. Blake suggested that we use autodiscover.<domain>, given that this should be a well-known domain for hosters now, too. I think that's a good idea. (But I still don't think the original problem philor mentioned is real. If a domain hoster gives out autoconfig.dreamhost.com, that's their problem, and also easily rectified.)