-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 2013-08-23 at 11:21 -0600, Peter Saint-Andre wrote: > I think we're all in -- or we *will* be when DANE/DNSSEC is widely > deployed, which unfortunately won't happen for years (IMHO) because of > all the dependencies on making it work.
The problem is that if you start doing CA verification without this in place, then more and more XMPP server operators will find themselves being pushed to "buy" a certificate from a commercial CA, for little actual verification benefit, and there will be little incentive later for the big players to bother supporting the independent operators. We've already seen with Google's XMPP the problems of getting a behemoth to care about protocol features that enable federation between many independent autonomous server operators (ie the open Internet). The time to bake in "you can expect this to work" is before almost everyone is part of a captive audience. So even though it won't help 80% of folks now, the 20% who could use DNSSEC/DANE if they so chose should explore doing so, to make sure the option is realistically there later. As a server operator, with an existing certificate in place, should visit <http://www.dnssec-tools.org/> and look at figuring out the TLSA records which they need to publish. The people who want folks to be able to verify them can publish these records, and look into getting their DNS zones signed. If you're using ISC bind, then version 9.9 onwards will let you use `auto-dnssec` and `inline-signing` statements together so that there's no operational overhead to _keeping_ the zones signed and the signatures current, so that after setting up the key glue, things revert back to the usual low maintenance overhead of DNS (when not under attack ;) ). <http://dnsviz.net/> is great for debugging DNSSEC. That's it for the connection-acceptor side of the equation. No code changes. It's a matter of configuration and running modern DNS software. For the connection initiator, you should have a validating DNS resolver (which is "any current maintained DNS resolver software", with unbound being a good choice for dedicated resolvers, else ISC Bind as the other default open source choice). That's a software deployment. You can choose to not do this, if the application client embeds DNS validation logic: some apps do this. The code change for the connection initiator is to be able to get the trust anchor information out of DNS, ensure it's valid (most easily by delegating responsibility to validating resolver on localhost and check the AD bit), and splice the trust anchor details into the TLS certificate/hostname verification logic. > In the meantime, something like POSH can help: It reduces the number of places that your trust chain depends upon the commercial PKIX infrastructure while not solving either the market capture or the untrustworthy CA problems; like most uses of TLS where an end-user is not the one controlling the connection, it fails by forcing server operators to accept untrustworthy CAs to "make it work, because it must be your problem, because it works for X" where X is someone who blindly trusts anyone. So it's good for getting "some kind" of TLS verification logic into the path, but is baking in a very poor trust model for S2S operators as part of the chain. It's a neat hack, but it's "crypto, with some verification", for the sake of having "crypto, with some verification" without regard to the trust model or the impact on how the trust will actually function in the real world (pressure to accept the least trustworthy CAs). - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlIXoDkACgkQQDBDFTkDY395IgCePcoDOxxHKT+x2xR5iosDZ2e7 GyUAnjx0rbC0lnPrBU/nCS2gbS5bOrIc =dNx+ -----END PGP SIGNATURE-----
