Something something DANE cook: Microsoft pledges to wrap its email systems in secure anti-snooping protocol Microsoft will add DNS-based Authentication of Named Entities (DANE) and DNSSEC to its email systems by the end of the year, the software giant has pledged. “Today we are announcing that Exchange Online will be adding support for two new Internet standards specific to SMTP traffic," Microsoft's Exchange Transport Team said in …
You do away with the whole PKI infrastructure and you check that a DNNSEC signed cert is verified by by the top level DNS servers and use this certificate to setup a TLS connection over which your usual SMTP type hello traffic goes over?
So nothing really changes in so far as MS GOOGLE and other NSA data providers are concerned because you don't encrypt the content but only encrypt the channel still. It's a bit a of as shame that eMail cannot use the certificates to encrypt the content so that only the domain owner can read it, but rather still encrypts only to the MX.
If you just wanted to verify the MX, which is all that you are doing, you could just check that the certificate it presents you is signed for the right host name, and you could still use the PKI.
I was never happy with the revocation thing in certs, but if you use short TTLs you can achieve that same without adding that complexity.
Agreed. I well know that part of my thought process is tainted by excessive cynicism due to my old age, however, I read "Office 365 will finally get DNSSEC-based protection *later this year*" as "As soon as we have been notified that U.S. spy agencies have well and properly cracked DNSSEC and DANE."
It's just as likely that the US TLA's have told Microsoft that they require DNSSEC for email, so MS are adding it to try and get a big, juicy, DoD contract for Office 365.
Plus they don't need to crack the encryption on the emails in transit when they can just grab them at rest.
Exactly. It's not encrypting emails from MS GOOG et al.
I think that DANE is quite good. If you read the wiki page "It is proposed in RFC 6698 as a way to authenticate TLS client and server entities without a certificate authority (CA)."
Not necessarily a bad thing. Why have 100's of CAs based in Iran China Turkey etc when you can trust the global Verisign DS records for the root domain and thats it. Also, why bother checking for revocation which is leaking information about which cert you are attempting to verity?
No, actually the customer demand for DANE came from Europe, which is also where you'll most of the existing adoption. Netherlands, Germany, Sweden, Czech republic, Denmark, Norway, Belgium, ...
Of course for privacy of your own stored email you might self-host (mailinabox.email) or choose a provider that specifically serves privacy-oriented users (protonmail, tutanota, posteo, ...).
Note of that means that mail transport should be unprotected, there's plenty of sensitive metadata even in end-to-end encrypted email, when sender, recipient and headers are in the clear.
It makes to protect transmission, and as appropriate also take the convenience cost of encrypted storage. For most users, encrypted storage fails cost/benefit analysis, but transparently encrypted transmission is not a burden.
DANE is a new one on me to be honest, but I like the idea.
As I understand it, and see the explanation below by KalF, it's not replacing the existing PKI. That still exists and has the same weaknesses explained in the article - namely that ANY root CA can issue a cert for ANY name. So a state actor can approach one of the CAs using their "you do what we say, tell no-one, otherwise we make life problematic for you" laws and obtain a CA for any name. They can then use that certificate to impersonate the target site (whether web or mail or ...) and the client simply checks the cert, sees that it has the appropriate chain of trust back to a root CA cert it knows about, and trusts it.
What DANE is adding is the ability to put in your DNS a record that basically says "if contacting foo.example.org, expect a certificate with these characteristics". With that in place, when teh client connects to the server, it does the TLS handshake as before, but now the certificate it sees from the fake server doesn't match what's in the secure DNS - instead of seeing a trust chain back to GoodCA, it sees a trust chain back to BadCA. The client can now identify that the "valid" certificate is not in fact the correct one for the server, refuse to connect, and you've blocked the MITM attack.
And the beauty of this is that for clients or servers not supporting DANE, it makes no difference. If there's no DANE DNS record (i.e. it's not configured for the server) then the client simply doesn't check that, and if the client doesn't support DANE then it just never looks for the record in the first place. Wow, a security upgrade that doesn't break anything - what's not to like !
The reasons why WebPKI is a poor fit for email are explained in section 1.3 (and subsections) of the SMTP DANE RFC:
https://tools.ietf.org/html/rfc7672#section-1.3
As for end-to-end email encryption, it will remain as impractical 10 years from now as it has been for the last 20. Encrypted email is difficult to search, difficult to protect from malware and spam, and most users really would not want to use it. A few OS releases ago Apple have disabled S/MIME support in Mail.app for lack of interest. I can still read the handful of encrypted messages in my mailbox, but can't send any new ones, and mostly would just make life harder for the reader...
Until browsers support DANE/TLSA and show status and errors, no amount of publicity will make people adopt it.
Cloudflare may have made DNSSEC available to all customers for free, but nobody bothers to configures their domain to use it due to (see above).
The one browser extension there was that let you see the status of the domain and cert is no longer possible with the current API access.
Mind you, using it just made you miserable as it showed how few site admin either give a crap, or have heard of it.
Cloudflare may have made DNSSEC available to all customers for free, but nobody bothers to configures their domain to use it due to (see above).
Methinks that that's more because people don't trust Cloudflare than because they don't think it's a good idea.
I mean: Cloudflare are doing this for free ... what's the catch?
@bige TLSA doesnt remove PKI to replace it with DNSSEC and root level authority. It uses your proven control of your own domain to tell the client mail server what to expect from the certificate the remote mail server will present _after a secure connection is established_. Bear in mind that all public certificates already rely on proof of domain control in order to issue you that cert. So this is not weaker or stronger, its simply more practical for SMTP. RFC7672 does contain a good intro into why SMTP secure connections dont match the HTTPS paradigms. go check it out if you want to dive into the details.
There is a DNS record that can help with email encryption, but client tools are probably lagging (OPENPGPKEY). The MS announcement doesnt make this easier or harder.
@DrFlay, you may have conflated adoption of mail security with adoption of all possible DANE records. Until browsers come to the party web TLSA records are a novelty. This has no impact on smtp TLSA adoption.
I'm sorry, but Microsoft adding DNSSEC to its infrastructure is like adding go faster stripes to a 20 year old car that needs its doors closed gently because it otherwise falls apart from rust. It still won't be credible.
I'm going to stay anonymous here, but let's just say that your problem as an Office365 user is not going to be be DNS security. If you need confidentiality, running your own Exchange server is reasonably OK, but I would not trust their cloud if I was paid to do so.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
