Earlier quoted context omitted.
Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with this cert, but you can only know the cert is OK to begin with because of a CA, or DANE).
Because the only remaining reason to deploy DNSSEC is to exploit DANE to allow SMTP MTAs to force TLS. All the other uses of DNSSEC are already DOA. It's a little tricky to explain why this is the case without getting into a lot of gritty detail. A shorthand answer is that browser vendors have, pretty much as a group, decided not to adopt DANE (the DNSSEC-based alternative to the X.509 CA system), and DANE is the onl…
Internet Draft: SMTP Strict Transport Security
71–80 of 104 posts
Re: Internet Draft: SMTP Strict Transport Security
#72Earlier quoted context omitted.
Is SSHFP not a legitimate use case for DNSSEC? (Genuinely curious.)
No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing it does that you can't do (better!) with some other system. It makes sense if you already have a secure DNS. But that begs the question of why you would need a secure DNS. You don't need a secure DNS for the web. You don't, with STS deployed, need a secure DNS for email. Is publishing SSH key fingerprints so important that we should do a f…
Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.
Re: Internet Draft: SMTP Strict Transport Security
#73Interesting to see the list of contributors from the various companies: Google, Inc, Yahoo!, Inc, Comcast, Inc, Microsoft, Inc, LinkedIn, 1&1 Mail & Media Development & Technology GmbH . One of my goals is to contribute to an RFC.
Re: Internet Draft: SMTP Strict Transport Security
#74Is there a TL;DR version of how adding SSL will make it a whole lot better? Sorry to be dumb on this subject but my understanding of how email works (in particular SMTP) seems like the whole model is busted to begin with. Are we still sending basically plain text unsigned messages using something akin to the pony express? Does it matter that the pony express carriers communicates securely so no bad guys can snoop the…
Here is my vague attempt at ELI5: Email is sent via a protocol called SMTP. SMTP goes over port 25 between major senders (there are other ports but forget that for now). Since it uses a single port, you can't distinguish between encrypted and plain text communication until you know each end supports encryption. A dated philosophy but people don't upgrade their email servers as often as they do their web browsers so i…
Discovering if someone supports Protocol++ if the fallback to Protocol is insecure is a hard problem.
Re: Internet Draft: SMTP Strict Transport Security
#75Can't we pretty much please make it reasonably generic and not SMTP-specific? There are a lot of protocols (say XMPP, IRC or IMAP) around that have opportunistic encryption with STARTTLS-like semantics. Surely, they could all benefit from a similar solution.
There are a lot more protocols that would benefit from the more generic and much simpler solution of "define a standard port where the service listens over TLS". IRCS has settled on 6697: https://tools.ietf.org/html/rfc7194 IMAPS uses 993.
That said, dedicated SMTPS port would still be beneficial by cutting down at least 2 RTTs (HELO/EHLO + STARTTLS) from overall transaction time.
Re: Internet Draft: SMTP Strict Transport Security
#76Earlier quoted context omitted.
Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with this cert, but you can only know the cert is OK to begin with because of a CA, or DANE).
DNSSEC however has its own problems. I have been thinking of a DNSSEC2 proposal for a while now that for example would use online signing only.
Re: Internet Draft: SMTP Strict Transport Security
#77Why do we need to add support for protocols individually for this? Can't we just introduce a TLS extension and an API for detecting these "always use TLS" requests in OpenSSL etc.?
SMTP starts in cleartext. That's the problem. You upgrade to TLS later. But only if the server says it can do that. A MITM attack can easily say that the receiver can't do TLS and thus can see everything that passes. This RFC specifies a way to prevent this, assuming clients abide by the requirements. It will be a long and slow roll out to get this done. But it is worth it.
This kind of bureacratic busywork is really, really frustrating. SMTP is nice and simple and does not benefit from this proposal except in the most abstract checklist-compliance sense.
Re: Internet Draft: SMTP Strict Transport Security
#78Earlier quoted context omitted.
SMTP starts in cleartext. That's the problem. You upgrade to TLS later. But only if the server says it can do that. A MITM attack can easily say that the receiver can't do TLS and thus can see everything that passes. This RFC specifies a way to prevent this, assuming clients abide by the requirements. It will be a long and slow roll out to get this done. But it is worth it.
This seems like the slowest possible way to make no useful change. Literally every SMTP-capable software package on earth supports SMTPS on a dedicated port, which requires no changes to protocol. Why not just formalize and mandate this, instead of clinging to a braindead design that requires SMTP to munge the transport level? STARTTLS is a hack. It is not something to be preserved. If the goal is 100% TLS coverage,…
Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it may not be trusted for the domain.[1]
So I think unfortunately we're not anywhere near a world where we could actually just drop email on the floor if TLS-with-a-valid-cert isn't present ("valid" not being clearly defined here, of course). I do think we're slowly moving in that direction[2].
It's certainly true that retrofitting security makes the whole thing more complicated, of course. That's a strong argument for ensuring that any retrofitting we do is itself forward-compatible with what we want to do in 30 years. Or for inventing time machines.
1. http://static.googleusercontent.com/media/research.google.co... 2. e.g. http://arstechnica.com/information-technology/2016/02/gmail-...
Re: Internet Draft: SMTP Strict Transport Security
#79Earlier quoted context omitted.
I don't know where to begin. > Arguments like this presuppose that the TLS security system is exactly as it was in 1999 For the majority, it is. The % of sites that deploy all of the latest HTTPS bells and whistles, even just looking at the minority of sites that actually enable TLS, is in the low single digits. Only 8% of sites surveyed by Qualys SSL Labs... sites that are presumably run by people who care about sec…
TLSA records do not have that capability, and, more importantly, the root of trust for TLSA records are organizations controlled by the government . The "Five Eyes" partnership can replace signatures for any DNSSEC domain in .COM, .NET, .ORG, .EDU, .UK, .AU, and .IO. It seems crazy to me that, after years of hyperventilating about the implications of the Snowden disclosures, anyone could take DNSSEC seriously. But pe…
1. Your main argument is that the NSA and its cohorts have control over a handful of many top level domains available. But the same control that would allow them to take control over domains and generate valid DNS signatures for them does allow them to generate valid certificates in every proposed global PKI system, including today's. There is literally zero difference in attack space here.
2. Several of the current CA institutions are under government control. Any one can generate a valid certificate for any domain. It can be done without a trace of evidence. The same active attack against a DNSSEC signed TLD would by necessity be much more visible.
3. Given that DV PKI is what TLS relies on, any adversary that can modify DNS packets in-flight can also create a valid TLS certificate today. We know these attacks are taking place from the Snowden documents.
4. An attacker can choose which CA to attack, and pick the one that is easiest to fool, does not participate in Certificate Transparency etc. There are literally hundreds to choose from. You can mount an attack in advance. Stuxnet suggests this is routine.
5. There are no alternatives that solves what secure DNS does. Key pinning and HSTS is important, but offer a trust-of-first-use model that can at best be complementary to a PKI. It is also important to note that HSTS shares the same deployment problems DNSSEC does. One mistake and your web server and domain is inaccessible. That is the reason none of the banks offer neither HSTS nor DANE. At least my bank sign their domain, so their step should be small.
The smoke-and-mirrors argument that DNSSEC gives governments control over "their" top level domains, when in fact it makes the scope of their control much smaller and more well defined, would be expected from someone who wants to maintain status quo as long as possible.
Re: Internet Draft: SMTP Strict Transport Security
#80Earlier quoted context omitted.
you do realize that not even 0.001% of people use that, right? DNS has to be encrypted by default for everyone. As in client -> recursor. Without any 3rd party software.
Unlike DNSSEC (which does not solve the problem the root comment complains about), DNSCurve/DNSCrypt doesn't require universal deployment to function. The 0.001% of people who use DNSCurve get most of the benefits of DNSCurve, despite being in a tiny minority.