On 2013-03-27 at 12:33 +0000, Tony Finch wrote: > Our response (as MTA authors) to a site with incomplete TLSA deployment > should be, finish deploying it if you want proper security. That is where > the effort should be applied. > > I should perhaps make the reasoning in the security considerations section > clearer.
Your viewpoint seems reasonable and I think I'm persuaded. (And the section update would be helpful). > > I'm inclined to provide a mode which says "if some of the entries are > > DNSSEC validated, but not all, then this is equivalent to no network > > connectivity to the unsigned entries and they should be skipped, just as > > if there were no route to the host". > > This is likely to have unhappy consequences if a site's third party backup > MX gains TLSA records but its primary does not. If that would lead to unhappy consequences, why are they advertising that host as being acceptable to handle deliveries for them? But you're winning me around. That, and the fact that it's simpler to not reorder, so it's less work for me, as long as we think we're doing the right thing for our userbase. > Why do you think "dane" needs to be an option? Can't it be supported by > default? I'm trying to write the specs so that it should just work from > the point of view of the user/admin of client software. Because changing what software does from one release to the next such that it makes changes to how systems interoperate in the real world leads to folks refusing to deploy it, because deploying the new version causes breakages. Too many people don't read README.UPDATING as it is. For a new feature like this, even without any MX reordering, we have to make it explicit-enable at first, even if in a later version we switch it to be on-by-default. > I don't think making it a generic security= option fits the style of the > existing TLS / AUTH options, which are fairly specific. So if you have to > have a dane option it should look like dane=flag/flag/flag. Oh, back towards my original design. :) [ cert-only ] > That is probably OK for an early prototype, but full TLSA support will be > necessary. Absolutely. I could just make libval a dependency, but I'm trying to avoid having all of the DNSSEC validation happen inside Exim itself. > > If we suddenly are requiring CA conformance for any host which does not > > have an independent trust-anchor, then this creates bad social pressures > > on postmasters, to trust CA Foo just because BigImportantRecipient uses > > CA Foo for their certs, even though CA Foo may have some "unfortunate" > > practices. > > Agreed, to some extent. This isn't too bad if the context is limited to > just SMTP+DANE since the DNS restricts which CAs are trusted to > authenticate a particular server. You are perhaps right to worry about the > second-order effects, though they are dwarfed by the effects of which CAs > browsers choose to trust. Browsers are horribly insecure by default, they're waking up to it, and each individual user of a computer (absent enterprise controls to the contrary) can override decisions, so the impact can be limited. When I visit https://www.paypal.com/ in my browser, I can click on the browser area that gives information about the certificate and glance at which CA is issuing it. Most people don't, but those who know enough can do so. By contrast, once an email leaves the MUA, it's out of the user's control, and they mostly just care about the mail getting through. Postmasters who stop business proposals going through just because the remote site has decided to require everyone to trust Incompetent Big CA Foo (TooBigToFail), will find themselves seeking new employment. Usage=0 or usage=1 in TLSA making their way into a store-and-forward system leads to backpressure blackmail and a losing game for everyone except those trying to extract rent from the security ecosystem. > I think this is a bad idea. It sounds like it would introduce tricky error > cases that could lead to spoofing, especially for usage=0. If the server > wants usage=2 then they should say so. I am willing to have a mode that does what you suggest here, but of all the areas up for discussion, this is where I am most firm: I will not knowingly create a system that creates such obvious backpressure blackmail opportunities to have CAs make themselves ever more Too Big To Fail, with postmasters faced with Hobson's Choice. As long as TLS only allows one CA to be the anchor for a trust chain (or forces clients to divulge an entire list of who they trust), the PKIX interaction with TLS creates monopolistic tendencies which only barely _almost_ managed to be usable for web-browsers. Still failed. Actively aiding blackmail by designing support for it into a product we maintain is a betrayal of the trust placed in us by our users. So: by default we either reject and ignore usage=0/usage=1, or we treat them as equivalent to usage=2/usage=3 (if the full certificate is present). The latter approach has better security properties, since we can at least verify that the certificate is the one the end host intends to be available. What do we _lose_ by mapping usage=0/1 to usage=2/3 ? We stop jumping through hoops that have no bearing upon whether or not the remote site's certificate (and thus public key) are the correct ones for the connection. What does a PKIX check here _add_, to the benefit of the sending site? A trust anchor for being willing to check CRLs or OCSP ourselves (as opposed to OCSP stapling)? We don't check those now. OCSP stapling still works with usage=2 and is the only mode that doesn't add significant single points of failure or other vulnerabilities to the communication path models. Perhaps I'm missing something important. I seriously am not seeing any reason to check in PKIX given a certificate in TLSA/DNSSEC, other than "the specification says we should". That part of the specification should go the same way as SEND/SOML/SAML from RFC 821. Perhaps we can avoid ambiguity and create stronger pressure by only implementing usage=2/usage=3, ignoring usage=0/1 entirely as Unusable? My current design tries to salvage something from them, for those poor sods forced by corporate policies to only ever use CA systems. We do have meaningful data that can be used, provided the certificate is present, and throwing away a valid security trust anchor for a Cause is not to our users' benefit. Thus my intent to map 0/1->2/3. -Phil
pgp92IZ1jHUYv.pgp
Description: PGP signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
