3 ms·

SMTP can be protected just as easily as HTTP. Look, I'm not saying DNSSEC is perfect. I don't like it. I just don't see a practical alternative to solving down

by nly 12y ago

SMTP can be protected just as easily as HTTP. Look, I'm not saying DNSSEC is perfect. I don't like it. I just don't see a practical alternative to solving downgrade attacks in the face of such a plethora of crappy Internet protocols.

tptacek 12y ago
So what you're saying is DNSSEC isn't finished yet. They need to standardize some equivalent to HSTS that will actually work with browsers on real-world networks, and also some kind of record that prevents SMTP TLS downgrade. When they do that, maybe I'll re-evaluate DNSSEC. In the meantime: the more people who deploy DNSSEC, the harder it gets to fix the broken crypto, so we should just stop.
- nly 12y ago
  The DANE TLSA record already provides the complement to HPKP. The SRV record already provides a complement to HSTS, a convention just needs to be standardized. These HTTP header equivalents are providing a protocol-specific partial solution to a solved problem. This is much like HTTP/2 introduces a protocol specific solution to broader problems with TCP/IP. Nobody seems to care about solving problems thoroughly any more. The choice of crappy ECC isn't really a technical problem, but a political one. The IETF are wrangling as we speak about the introduction of safe curves in to TLS. djb is lamenting the process. Btw, I'm all for radical overhaul of the Internet stack, from TCP up, but history tells us radical changes struggle to see adoption. DNSSEC is here and it's easy to deploy (really, it is). It sucks, but it has momentum now and it isn't going away. Killing it without a political push behind a better full-stack solution is just a step backwards. You're probably correct however in that adopting DNSSEC will reduce the chances of a better alternative making headway, just like adopting HTTP/2 is going to further reduce the chances of SCTP (or something better) adoption ever picking up.
  - tptacek 12y ago
    First, I wasn't talking about HPKP, I was talking about HSTS. And TLSA is a complement to HPKP only if "the NSA and DOJ are allowed to override your pin" is an acceptable concession. It of course is not. Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things. You're also wrong about the "technical" versus "political" nature of DNSSEC's ECC problem. The technical problem with DNSSEC ECC is that every additional DNSSEC resolver that gets deployed without a modern ECC signature record type makes it harder to roll out that record type in the future. Once again: even the (bad) ECC that DNSSEC already supports breaks fully 1/3rd of the DNSSEC installed base. No part of my argument involves Daniel Bernstein's opinion of the CFRG. I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of. In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it. Virtually nobody uses it. If DNSSEC stopped functioning today, no Fortune-500 company would notice. I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.
    - nly 12y ago
      > Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things. Wrong, an SRV record for HTTPS already exists[0]. The problem is that the current recommendation is not to publish both "_https._tcp" and "_http._tcp", but to publish only the latter and let the client negotiate HTTPS using redirects and pinning. This recommendation is dumb as it doesn't solve the introduction mitm attack I originally described about 10 posts up. Browser vendors could make a statement on their SRV behaviour and agree to favour https if such a record exists. > I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of. HTTP/2s primary achievement is to work around head-of-line blocking in TCP. SCTP already solved that problem. There is now less incentive to push HTTP/1.x streams over SCTP. The parallels are clear with DNSSEC and DNScurve. We have authentication now, it can be done (inefficiently) end-to-end. The added incentive of confidentiality weighed against the cost of a new round of redeployment isn't great. I think DNSSEC has already gone over the tipping point in the circles that ultimately matter. > In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it. s~DNSSEC~HTTP/2~ > I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not. I'm not hearing a coherent plan B from you or anyone else to solve these cross-protocol problems. HSTS and HPKP do not solve the problem of shitty CAs, DNSSEC opens to the door to a free alternative that, in the very least, means there are fewer entities we have to trust (hundreds -> a handful). HSTS and HPKP do not solve the introduction problem, DNSSEC adds some hope of helping there. What are your suggestions? [0] http://dns-sd.org/ServiceTypes.html http://dns-sd.org/ServiceTypes.html

by nly 12y ago

tptacek 12y ago

So what you're saying is DNSSEC isn't finished yet. They need to standardize some equivalent to HSTS that will actually work with browsers on real-world networks, and also some kind of record that prevents SMTP TLS downgrade. When they do that, maybe I'll re-evaluate DNSSEC. In the meantime: the more people who deploy DNSSEC, the harder it gets to fix the broken crypto, so we should just stop.

nly 12y ago
The DANE TLSA record already provides the complement to HPKP. The SRV record already provides a complement to HSTS, a convention just needs to be standardized. These HTTP header equivalents are providing a protocol-specific partial solution to a solved problem. This is much like HTTP/2 introduces a protocol specific solution to broader problems with TCP/IP. Nobody seems to care about solving problems thoroughly any more. The choice of crappy ECC isn't really a technical problem, but a political one. The IETF are wrangling as we speak about the introduction of safe curves in to TLS. djb is lamenting the process. Btw, I'm all for radical overhaul of the Internet stack, from TCP up, but history tells us radical changes struggle to see adoption. DNSSEC is here and it's easy to deploy (really, it is). It sucks, but it has momentum now and it isn't going away. Killing it without a political push behind a better full-stack solution is just a step backwards. You're probably correct however in that adopting DNSSEC will reduce the chances of a better alternative making headway, just like adopting HTTP/2 is going to further reduce the chances of SCTP (or something better) adoption ever picking up.
- tptacek 12y ago
  First, I wasn't talking about HPKP, I was talking about HSTS. And TLSA is a complement to HPKP only if "the NSA and DOJ are allowed to override your pin" is an acceptable concession. It of course is not. Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things. You're also wrong about the "technical" versus "political" nature of DNSSEC's ECC problem. The technical problem with DNSSEC ECC is that every additional DNSSEC resolver that gets deployed without a modern ECC signature record type makes it harder to roll out that record type in the future. Once again: even the (bad) ECC that DNSSEC already supports breaks fully 1/3rd of the DNSSEC installed base. No part of my argument involves Daniel Bernstein's opinion of the CFRG. I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of. In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it. Virtually nobody uses it. If DNSSEC stopped functioning today, no Fortune-500 company would notice. I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.
  - nly 12y ago
    > Second, there is no DNSSEC equivalent to HSTS. Saying that there could be one is not a very compelling argument. There could be a lot of things. Wrong, an SRV record for HTTPS already exists[0]. The problem is that the current recommendation is not to publish both "_https._tcp" and "_http._tcp", but to publish only the latter and let the client negotiate HTTPS using redirects and pinning. This recommendation is dumb as it doesn't solve the introduction mitm attack I originally described about 10 posts up. Browser vendors could make a statement on their SRV behaviour and agree to favour https if such a record exists. > I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of. HTTP/2s primary achievement is to work around head-of-line blocking in TCP. SCTP already solved that problem. There is now less incentive to push HTTP/1.x streams over SCTP. The parallels are clear with DNSSEC and DNScurve. We have authentication now, it can be done (inefficiently) end-to-end. The added incentive of confidentiality weighed against the cost of a new round of redeployment isn't great. I think DNSSEC has already gone over the tipping point in the circles that ultimately matter. > In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it. s~DNSSEC~HTTP/2~ > I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not. I'm not hearing a coherent plan B from you or anyone else to solve these cross-protocol problems. HSTS and HPKP do not solve the problem of shitty CAs, DNSSEC opens to the door to a free alternative that, in the very least, means there are fewer entities we have to trust (hundreds -> a handful). HSTS and HPKP do not solve the introduction problem, DNSSEC adds some hope of helping there. What are your suggestions? [0] http://dns-sd.org/ServiceTypes.html http://dns-sd.org/ServiceTypes.html