Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Internet Draft: SMTP Strict Transport Security

tools.ietf.org

Post reply on HN
Print view View original

11–20 of 104 posts

Re: Internet Draft: SMTP Strict Transport Security

#11

Post by sarthakjain »

vonklaus wrote: post #5
zokier wrote: post #2

Very interesting, seems like this would have potential to improve email transit security quite a bit. It is encouraging to see Google, Microsoft, Yahoo and Comcast in the authors, that would indicate that this has good chance of being applied to large portion of internet email. Of course email at rest security remains an issue, but that another story.

> encouraging to see Google, Microsoft, Yahoo and Comcast For all intents and purposes this is most of the English speaking internet. If you swap Yahoo for Verizon and Apple you'd be pretty close. So, yeah encouraging to get this standard applied, less so if you think it is good for the internet to offload an outsize share of control to 5-10 corporations.

Google, Yahoo, Gmail each have more than 300M active email accounts. Ships sailed hit the iceberg and they made a movie about it.

Re: Internet Draft: SMTP Strict Transport Security

#12

Post by randomusr »

jakobdabo wrote: post #8
randomusr wrote: post #7

do the same for the fucking DNS protocol, which is clear-text, it's the weapon of choice for all surveillance/censorship freaks and nobody cares about. And by 'nobody' I am not referring to actual random Joe users, but you - the fucking mastermind developers who create stuff that nobody cares about, hosted on .io domains just because it is cool and looks like some start-up that's about the be the next big thing. Plea…

DNSCurve - https://en.wikipedia.org/wiki/DNSCurve

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.

Re: Internet Draft: SMTP Strict Transport Security

#13

Post by jakobdabo »

Natanael_L wrote: post #4

Those who have taken a close look, how comprehensive is this? Any risk of downgrade attacks, etc?

"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC."

Also, can be used with DANE for additional security.

Re: Internet Draft: SMTP Strict Transport Security

#14

Post by AaronFriel »

vonklaus wrote: post #5
zokier wrote: post #2

Very interesting, seems like this would have potential to improve email transit security quite a bit. It is encouraging to see Google, Microsoft, Yahoo and Comcast in the authors, that would indicate that this has good chance of being applied to large portion of internet email. Of course email at rest security remains an issue, but that another story.

> encouraging to see Google, Microsoft, Yahoo and Comcast For all intents and purposes this is most of the English speaking internet. If you swap Yahoo for Verizon and Apple you'd be pretty close. So, yeah encouraging to get this standard applied, less so if you think it is good for the internet to offload an outsize share of control to 5-10 corporations.

Is there anything about IETF standards that creates an outsize share of control for a limited number of corporations?

Re: Internet Draft: SMTP Strict Transport Security

#15

Post by icebraining »

randomusr wrote: post #12
jakobdabo wrote: post #8

Earlier quoted context omitted.

DNSCurve - https://en.wikipedia.org/wiki/DNSCurve

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.

Then you must ask the OS vendors to include it, not startup developers.

And in any case, encrypting DNS won't solve the surveillance issue, since the HTTPS handshake sends the domain in clear-text, so that the server knows which certificate to send (https://en.wikipedia.org/wiki/Server_Name_Indication)

Re: Internet Draft: SMTP Strict Transport Security

#17

Post by tptacek »

randomusr wrote: post #12
jakobdabo wrote: post #8

Earlier quoted context omitted.

DNSCurve - https://en.wikipedia.org/wiki/DNSCurve

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.

Re: Internet Draft: SMTP Strict Transport Security

#18

Post by devit »

It would be nice to also consider completely dropping support for non-TLS SMTP.

Unlike HTTP where connecting to abandoned non-TLS websites can be useful, e-mail is only useful if someone is reading it, and if they are reading it they can take action to enable TLS.

Re: Internet Draft: SMTP Strict Transport Security

#19

Post by malka »

icebraining wrote: post #15
randomusr wrote: post #12

Earlier 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.

Then you must ask the OS vendors to include it, not startup developers. And in any case, encrypting DNS won't solve the surveillance issue, since the HTTPS handshake sends the domain in clear-text, so that the server knows which certificate to send ( https://en.wikipedia.org/wiki/Server_Name_Indication )

One could use a single certificate that is valid for all domain on the server

Re: Internet Draft: SMTP Strict Transport Security

#20

Post by tptacek »

jakobdabo wrote: post #13
Natanael_L wrote: post #4

Those who have taken a close look, how comprehensive is this? Any risk of downgrade attacks, etc?

"SMTP STS relies on the certificate authority (CA) system and a trust-on-first-use (TOFU) approach to avoid interception. The TOFU model allows a degree of security similar to that of HPKP [RFC7469], reducing the complexity but without the guarantees on first use offered by DNSSEC." Also, can be used with DANE for additional security.

If, like me, you believe the only real-world adversary for large-scale mail transport between places like Google and Yahoo is state-level actors and dragnet surveillance, then deploying DANE reduces your security, by tying you to trust anchors controlled by world governments.

DANE is generally a bad idea, and it's great that STS is explicitly proposed as an alternative to it, not an application of it.

Post reply on HN