[ Resending, as this is not in the list archive, and Google does not seem to find it anywhere. Perhaps this never made it to the list. I am hoping someone from Comcast will read past the TL;DR to the end of the message and deploy real keys for their MX hosts. ]
On Thu, Nov 13, 2014 at 02:59:04PM -0500, Paul Wouters wrote: > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks > > "In recent months, researchers have reported ISPs in the US and Thailand > intercepting their customers' data to strip a security flag?called > STARTTLS?from email traffic." > > > Thanks to Viktor, properly configured postfix clients deployed with DANE > should > detect this and refuse to send the email unencrypted. Thanks for the nod in my direction. Note however, that we still need a lot more MTAs to adopt DNSSEC and publish TLSA RRs. Please encourage server operators to move forward. However, my curated list stands at 337 domains, with: * 1 with expired RRSIGs * 2 with DS RRs that don't match the zone keyset * 1 with an incorrect TLSA RR post key rotation * 1 with an incorrect TLSA usage (2 instead of 3). [ FWIW, since Nov 13th the working domain count has reached 441. ] In addition I've run into 8 domains with PKIX-EE(1) TLSA RRs which are not "usable" for SMTP. Therefore, I'd like to suggest that while system operators should adopt SMTP with DANE, they should not do so as "fashion statement". Do it right, or don't do it at all. Having a bunch of published broken domains discourages others from deploying and creates headaches for those who've enabled verification. The error rate would have been higher, were it not for some successes in notifying most of the problem domains of their mistakes, with almost all fixing the problem as a result. Once the new testing site is up and running, I'm hoping we can successfully "market" it to would-be SMTP with DANE operators, and avoid most mistakes in the future. The site will support testing of live systems (catch mistakes after the fact) and testing of planned configurations (catch mistakes before they happen). A Cable operator in Germany with ~500K users has enabled DANE. IIRC a Comcast engineer was present at the DANE meeting yesterday. Since the comcast.net zone is signed, I was hoping that a good step in the same direction might have been. _25._tcp.mx1.comcast.net. IN TLSA 3 1 1 3D0CE5F401FE33EFA5ADB136D1E6EDAFBD72DB82FEC50E3CB69CF0943ACBA8D4 _25._tcp.mx2.comcast.net. IN TLSA 3 1 1 3D0CE5F401FE33EFA5ADB136D1E6EDAFBD72DB82FEC50E3CB69CF0943ACBA8D4 Sadly the certificates in question appear to be from a stock keypair: Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Sample, Inc., OU=IT Team, CN=CA Validity Not Before: Nov 18 14:58:26 2010 GMT Not After : Nov 15 14:58:26 2020 GMT Subject: C=US, O=Sample, Inc., OU=IT Team, CN=Server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: Sample server certificate, do not use on production systems! ... Likely same key previously noted in: http://markgamache.blogspot.com/2014_01_01_archive.html https://community.virginmedia.com/t5/Email/Sample-server-certificate-do-not-use-on-production-systems/td-p/2142440 So we still have some way to go. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
