On Tue, Sep 03, 2013 at 09:13:32PM -0700, Ian Fette (????????) wrote: > I'm not sure that I agree with everything in that draft, particularly the > bit about not using certificate usage 0/1, as this is precisely what we > would do for Gmail most likely (we operate our own CA, and for instance in > Chrome and via http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we > typically pin google.com to a set of CA certificates, not leaf > certificates, as the leaf certificates can rotate more frequently based on > operational needs but our CA cert changes much more rarely.)
Do not confuse non-support of 0/1 with not supporting CA-anchored certificate chains. In my SMTP draft the latter are fully supported via usage 2. The difference is that the SMTP client is *not expected* to have any prior knowledge of a set of CAs trusted collectively to authenticate the entire Internet. Any such set of CAs is either incomplete (mail delivery to some sites fails) or contains CAs one should generally trust (one can't be sure exactly which ones those are). Think of this as a variant of Goedel's incompleteness theorem to trusted CAs as a set of axioms for Internet security. :-) Furthermore, since sites are allowed to publish self-issued certificate associations (e.g. to a 3 1 1 leaf public key, or to a 2 1 1 domain issued CA), any attacker who compromises a domain's DNS can substitute any TLSA records that require PKIX (usage 0 or 1) with records that don't (2 or 3). In fact since you observed the trivial downgrade attacks on SMTP without DANE, if such an attacker can also MITM the client, he can simply suppress the TLSA records, an not send STARTTLS. The client then sends mail in the clear. Most MTAs do not ship with a complete (inconsistent) set of CAs. Since unlike a browser there is no interactive user to click "OK" when PKIX verification fails, requiring PKIX would lead to degradation in reliability of service. Some MTAs are configured with a short of lists CAs the administrator actually trusts (incomplete), they use this for manually configured PKIX validated delivery to selected partner sites, but this does not scale to the Internet, and is not dependent on DANE. Non-support of certificate usages 0/1 in the SMTP incarnation of DANE is key to the interoperability of the protocol with existing systems and flows naturally out of a thoughtful security analysis of the protocol. If you publish usage 0, you will not interoperate with Postfix, which accounts for a large fraction of the MTAs on the Internet. Google is of course free to configure its own SMTP clients with prior knowledge of Google's CA, so that mail delivery internal to Google is protected by additional client-side security policy. Nothing in my draft precludes this, but no such prior configuration scales to the Internet at large. You should perhaps have a chat with Warren Kumari (one of the chairs of the DANE working group, and a Google employee I believe). If you want to include me in the conversation, let me know and I may be able to join you in a conference call. > It's not clear > to me why requiring PKIX validation in that case would be an unreasonable > expectation. Indeed, most of the certs I see from a random inspection of > servers offering STARTTLS (google, t-online, web.de etc) include a full > certificate chain to a public CA. Other than that nit though, I would love > to see that draft advance. You've only looked at the major providers. The majority of domains that offer SMTP STARTTLS have self-signed certificates. In any case SMTP clients (even at large Fortune 500 companies that pay for certs issued by public CAs) almost never check the CAs of other SMTP servers except by bilateral prior arrangement. When I worked for Morgan Stanley, we were pretty much the only company that actually went beyond enforcing mandatory use of TLS and configured verification of the peer certificate. Most of our business partners were content to require "encryption" without any authentication. Doing PKIX with SMTP is hard in any case because MX indirection (sans DNSSEC) makes it impossible to robustly determine what names are acceptable in the peer's certificate. So bottom line, my draft is carefully thought out, and the requirement to NOT publish usage 0/1 is very unlikely to change. This is not a draft built in a vacuum, hoping for eventual adoption by some implementor. Rather this is a draft that adheres to an actual implementation in Postfix, and soon (when the relevant Exim developer is able to take time to make it happen) also in Exim. The draft documents a basis for interoperability with *existing* implementations, and the core features should not be changed without compelling reasons to do so. On Wed, Sep 04, 2013 at 02:38:01PM +0200, Ond?ej Sur? wrote: > > > I'm not sure that I agree with everything in that draft, > > particularly the bit about not using certificate usage 0/1, as this > > is precisely what we would do for Gmail most likely (we operate > > our own CA, and for instance in Chrome and via > > You need certificate usage 2 for your own CA and the mapping > 0->2, 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your > DANE record with certificate usage 0 SHOULD be used even in case > that you use a well established CA. The Postfix mapping of usage 0 to 2 is necessarily incomplete! In particular "0 x [12]" are unsupported, and "0 0 0" is too large to fit into DNS without fragmentation. Even "0 1 0" is too large with 2048-bit RSA keys. Only ECDSA keys make "0 1 0" usable, but most clients don't support EC. So in effect only the downgrade of 1->3 works. Usage "0" is essentially not supported at all (best effort support leaves most of it unusable). > > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we > > typically pin google.com to a set of CA certificates, not leaf > > certificates, as the leaf certificates can rotate more frequently > > based on operational needs but our CA cert changes much more rarely.) > > It's not clear to me why requiring PKIX validation in that case > > would be an unreasonable expectation. > > I guess this comes from operational experiences, currently the > SMTP servers don't do any validation on the certificates and it > would be a great leap to take, so it's better to start with > opportunistic TLS than enforcing the users to do full PKIX. > > This might change in the future in some future draft, but Viktor's > draft would be a huge leap for SMTP encryption. This is very unlikely to change. I can't subject Postfix users to the consequences of requiring PKIX (reduced service availability when CA lists are incomplete, or mandating trust in CAs they've never heard of). Adding CA trust in SMTP with DANE adds no security, the protocol is critically dependent on DNSSEC. So PKIX for SMTP (internet scale with no prior bilateral agreement, ... see the draft) only gives us additional failure modes with no security benefit. There will be no PKIX support in the Postfix DANE implementation. Servers publishing usage 0 will find that clients simply enforce mandatory TLS and skip authentication. The right thing to do is to choose between publishing "2 1 1" or "3 1 1". The remaining 22 combinations of DANE parameters can be ignored for SMTP. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
