Internet Draft: SMTP Strict Transport Security • Hacker News Board

Re: Internet Draft: SMTP Strict Transport Security

#81

Post by tptacek » Sun, Mar 20, 2016, 3:12 PM UTC

xorcist wrote: post #80

tptacek wrote: post #17

Earlier quoted context omitted.

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.

The fact that DNSSEC is not universally deployed, yet secures important infrastructure in big organizations, would suggest your argument is false. In practice it is a bit more complex as DNSSEC is globally deployed and widely available, and that's a large part of the reason you can trust it. Any global initiative takes a full ten years to deploy as we've repeatedly seen.

What is the most important resource secured today by DNSSEC?

I can name thousands of critically important resources that do not use DNSSEC. For instance: any credit card transaction you make on the Internet will not, at any step in the process, involve DNSSEC. The same is true of any stock order at any retail brokerage, or any FIX connection between an exchange and a broker/dealer.

Re: Internet Draft: SMTP Strict Transport Security

#82

Post by tptacek » Sun, Mar 20, 2016, 3:12 PM UTC

AndyMcConachie wrote: post #71

tptacek wrote: post #46

Earlier quoted context omitted.

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…

DNSSEC adoption is actually doing pretty well. And there are reasons beyond DANE to deploy it.

Please share.

Re: Internet Draft: SMTP Strict Transport Security

#83

Post by tptacek » Sun, Mar 20, 2016, 3:14 PM UTC

AndyMcConachie wrote: post #72

tptacek wrote: post #58

Earlier quoted context omitted.

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…

STS information is stored in DNS records. Why would you not want to secure those? 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.

It has taken two decades to get to this point. The protocol has been substantially revised four times, and, after each of those four revisions, DNSSEC proponents said "now, we've got it right, and it's ready for universal deployment".

It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.

Re: Internet Draft: SMTP Strict Transport Security

#84

Post by tptacek » Sun, Mar 20, 2016, 3:18 PM UTC

xorcist wrote: post #79

tptacek wrote: post #35

Earlier quoted context omitted.

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…

Your arguments does not make sense as a coherent whole. Any one may not be wrong in itself, but the problems described are either not inherent to secure DNS, or are something that is much worse with every other proposal (including keeping today's system). 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…

I don't think many people want to read this deep into a tangent thread, so I'm going to keep my response very terse.

1. It's not my main argument, but, no: when a CA misbehaves, it is blacklisted (Google's done this). Google can't blacklist .com.

2. No. See FAQ.

3. No. See FAQ.

4. They can't do that if the certificate they're after is pinned. All they'll accomplish is getting the CA killed.

5. The thing DNSSEC secures simply doesn't need to be secured, any more than the IP options header does.

Re: Internet Draft: SMTP Strict Transport Security

#85

Post by AndyMcConachie » Sun, Mar 20, 2016, 4:07 PM UTC

tptacek wrote: post #83

AndyMcConachie wrote: post #72

Earlier quoted context omitted.

STS information is stored in DNS records. Why would you not want to secure those? 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.

It has taken two decades to get to this point. The protocol has been substantially revised four times , and, after each of those four revisions, DNSSEC proponents said "now, we've got it right, and it's ready for universal deployment". It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.

DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't the best thing going for us in terms of securing the DNS. Like it or not it's important to be able to trust DNS responses.

I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't worth taking.

DNSSEC and TLS are unrelated. They're trying to solve different problems.

Re: Internet Draft: SMTP Strict Transport Security

#86

Post by AndyMcConachie » Sun, Mar 20, 2016, 4:16 PM UTC

tptacek wrote: post #82

AndyMcConachie wrote: post #71

Earlier quoted context omitted.

DNSSEC adoption is actually doing pretty well. And there are reasons beyond DANE to deploy it.

Please share.

I don't have good numbers for signing of zones. Although we do know that these numbers are increasing. Cloudflare recently turned on DNSSEC for all of their clients.

Geoff Huston at APNIC does some good work at measuring validation. Check out slide 2 and 24 of this preso. https://meetings.icann.org/en/marrakech55/schedule/wed-dnsse...

Again, I'm not arguing that DNSSEC adoption has been easy and fast. But it's being adopted steadily.

Re: Internet Draft: SMTP Strict Transport Security

#87

Post by tptacek » Sun, Mar 20, 2016, 4:31 PM UTC

AndyMcConachie wrote: post #85

tptacek wrote: post #83

Earlier quoted context omitted.

It has taken two decades to get to this point. The protocol has been substantially revised four times , and, after each of those four revisions, DNSSEC proponents said "now, we've got it right, and it's ready for universal deployment". It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.

DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't the best thing going for us in terms of securing the DNS. Like it or not it's important to be able to trust DNS responses. I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't wo…

There is no point to securing the DNS. There are only downsides.

Re: Internet Draft: SMTP Strict Transport Security

#88

Post by yuhong » Sun, Mar 20, 2016, 5:42 PM UTC

tptacek wrote: post #87

AndyMcConachie wrote: post #85

Earlier quoted context omitted.

DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't the best thing going for us in terms of securing the DNS. Like it or not it's important to be able to trust DNS responses. I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't wo…

There is no point to securing the DNS. There are only downsides.

*using DNSSEC

Re: Internet Draft: SMTP Strict Transport Security

#89

Post by tptacek » Sun, Mar 20, 2016, 5:50 PM UTC

AndyMcConachie wrote: post #86

tptacek wrote: post #82

Earlier quoted context omitted.

Please share.

I don't have good numbers for signing of zones. Although we do know that these numbers are increasing. Cloudflare recently turned on DNSSEC for all of their clients. Geoff Huston at APNIC does some good work at measuring validation. Check out slide 2 and 24 of this preso. https://meetings.icann.org/en/marrakech55/schedule/wed-dnsse... Again, I'm not arguing that DNSSEC adoption has been easy and fast. But it's being…

No, I'm asking about the reasons to deploy it.

Re: Internet Draft: SMTP Strict Transport Security

#90

Post by tptacek » Sun, Mar 20, 2016, 6:09 PM UTC

AndyMcConachie wrote: post #70

tptacek wrote: post #16

Successful deployment of STS would bring to zero the number of real-world use cases for DNSSEC/DANE, which would be a very good thing.

Read the draft dude. STS is designed to interoperate with DANE. Also, if you deploy your STS info via DNS you'll need DNSSEC validation to to ensure that what you read in DNS is actually what the zone holder put there. Without DNSSEC how does a sending SMTP daemon trust the STS policy of the recipient zone. STS policies are stored in DNS TXT records, or their own new RR.

Pleaee don't be rude. STS doesn't preclude DANE, but it doesn't require it either. Meanwhile, this use case was the last remaining one motivating DANE at all.