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

41–50 of 104 posts

Re: Internet Draft: SMTP Strict Transport Security

#41

Post by rubyfan »

Is 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 carriers bag of messages At least in the old days you could put a wax seal on the letter to know the letter was legit and not tampered with. With email the entire system is flawed from the get go.

Re: Internet Draft: SMTP Strict Transport Security

#42

Post by yuhong »

jimktrains2 wrote: post #40
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.

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

#43

Post by nxzero »

rubyfan wrote: post #41

Is 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…

Agree, idea that the carrier should be trusted or for that matter responsible for the security of a message is dated and largely meaningless security measure. As long as the message is able to be read by anyone other than the sender and intended recipient the message should be assumed as being insecure.

Re: Internet Draft: SMTP Strict Transport Security

#44

Post by baudehlo »

rubyfan wrote: post #41

Is 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 it made sense at the time.

Since the plain text receiving server says "yes I can do STARTTLS", this is easy to man in the middle intercept and say "no encryption here" and the mail goes through anyway.

Even if the receiving end says all mail must arrive over TLS the man in the middle can currently circumvent that by receiving in plain text and forwarding onwards via TLS

This is an RFC to try and prevent that happening.

This stuff is hard, and email nerds (via MAAWG and various other places) have been working on this for years. We don't want to break your current email service, and bringing things up to speed without breaking a ton of eggs has been hurting email for a long time, but we spent too long stopping spam instead of thinking about these problems. Sorry!

Re: Internet Draft: SMTP Strict Transport Security

#45

Post by MichaelGG »

zanny wrote: post #23
devit wrote: post #18

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.

Well, we missed out on mandatory encryption in HTTP/2, despite that requiring the webserver to turn it on, so for some reason we still have a lobby for unsecured communications.

Except browsers won't implement non-TLS HTTP2. So for all the use cases that matter, it's fine. Another good example of implementation trumping "standards".

Re: Internet Draft: SMTP Strict Transport Security

#46

Post by tptacek »

jimktrains2 wrote: post #40
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.

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 only reason anyone cares about DNS security on an Internet where everything is going to be encrypted (usually with TLS) by default.

Re: Internet Draft: SMTP Strict Transport Security

#47

Post by newman314 »

rubyfan wrote: post #41

Is 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…

You are right in that it's kind of lipstick on a pig. TLS encrypts inflight email, not at rest nor does it adequately protect associated metadata.

BUT, it's better than not doing anything.

Re: Internet Draft: SMTP Strict Transport Security

#49

Post by mned »

yuhong wrote: post #42
jimktrains2 wrote: post #40

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

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.

Having no support for offline signing in and of itself isn't a selling point. What else does your approach have to offer?

Re: Internet Draft: SMTP Strict Transport Security

#50

Post by colanderman »

tptacek wrote: post #46
jimktrains2 wrote: post #40

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…

Is SSHFP not a legitimate use case for DNSSEC? (Genuinely curious.)
Post reply on HN