Linked by Thom Holwerda on Thu 12th Apr 2012 08:59 UTC
Internet & Networking I would honestly serve at the altar of the person that did this. Keep the debugging information, but for the love of god, make your email client do something pretty and useful with it.
Thread beginning with comment 513875
To view parent comment, click here.
To read all comments associated with this story, please click here.
Laurence
Member since:
2007-03-26

TLS transmission on SMTP between mail servers really doesn't make much sense. What's the purpose of TLS? To add confidentiality and security. Mail servers don't care about that, the end users do. OpenPGP and S/MIME serve just this purpose and are in wide usage because of it.

It's analogous to paper mail. If I want to transmit confidential data, I sure as hell don't trust my mailman and the whole mail delivery chain to keep my secrets. I encrypt my messages at home and all I require the mail service to do is deliver them.


The problem there is that confidential information is frequently transmitted via e-mail. In fact it's pretty standard for things like Passwords and user IDs to be sent this way. Let alone more confidential data sent by users who don't understand the protocol.

Furthermore, it would make a great deal more sense to encrypt as standard at the protocol level rather than add another layer of abstraction at the user level

Reply Parent Score: 2

zztaz Member since:
2006-09-16

You're both right, and you're both wrong.

Keeping messages confidential requires encryption at the endpoints. That means clients need to handle it. Servers are not involved. In my opinion, not only should clients make this easy, it really needs to be available for all files regardless of method of delivery. It doesn't matter if you e-mailed it to me, I downloaded it from a web site, or you gave me a thumb drive, we need some way to prove who we are and keep the file secret from everyone else.

TLS does have a role in e-mail, and it's not encryption. TLS provides authentication. Authentication is arguably the largest problem with e-mail. The original protocol simply trusted clients and servers not to lie about who they were, and that's why we have spam. If our servers only accept mail from servers authenticated with certificates, then blocking spam is easy.

Reply Parent Score: 3

Alfman Member since:
2011-01-28

"TLS does have a role in e-mail, and it's not encryption. TLS provides authentication. Authentication is arguably the largest problem with e-mail."

I agree that this is one of email's bigger problems, and though there are solutions, the fact that we cannot depend on them working even a fraction of the time make them somewhat useless. What good is authentication if it doesn't work reliably with my current contacts? If we allow any exceptions for others to contact us without authentication, then email remains vulnerable. I doubt we'll see a massive roll out to fix SMTP's problems. We're more likely to see people adopt a new service that has security built into it from version 1.

"The original protocol simply trusted clients and servers not to lie about who they were, and that's why we have spam. If our servers only accept mail from servers authenticated with certificates, then blocking spam is easy."

I disagree, authentication won't stop spam. Spam will just be authenticated like any other mail. Not all spammers use forged headers.

Reply Parent Score: 2

Soulbender Member since:
2005-08-18

TLS does have a role in e-mail, and it's not encryption. TLS provides authentication.


The authentication that TLS provides is only of limited use to end-users though.
S/MIME and GPG/PGP is really the only real option today to verify senders and to ensure encrypted end-to-end delivery. It's really sad that major clients like Thunderbird and Outlook only supports S/MIME out of the box and you have to go through insane hoops, especially with Outlook, to get PGP/GPG working. All we need is realyl there already, it's just that we're not using it.

Reply Parent Score: 4

0brad0 Member since:
2007-05-05


TLS does have a role in e-mail, and it's not encryption.


The vast majority of TLS usage with an e-mail system is FOR encryption NOT authentication. Authentication is done via SASL for SMTP or the existing authentication mechanisms with POP3/IMAP.

Reply Parent Score: 3

saso Member since:
2007-04-18

In my opinion, not only should clients make this easy, it really needs to be available for all files regardless of method of delivery. It doesn't matter if you e-mailed it to me, I downloaded it from a web site, or you gave me a thumb drive, we need some way to prove who we are and keep the file secret from everyone else.


OpenPGP features file-based encryption and authentication as well (in fact, the e-mail stuff is just a particular application of the signature and encryption algorithms, which work with any digital data).

TLS does have a role in e-mail, and it's not encryption. TLS provides authentication. Authentication is arguably the largest problem with e-mail. The original protocol simply trusted clients and servers not to lie about who they were, and that's why we have spam. If our servers only accept mail from servers authenticated with certificates, then blocking spam is easy.


Who would issue these certificates? How would you check a certificate's validity exactly? Who would be authenticated by it (sender, recipient, both)? Remember, we're talking server to server SMTP here, not client to server - that's a given, STARTTLS has been in use here for years.

Reply Parent Score: 2

saso Member since:
2007-04-18

The problem there is that confidential information is frequently transmitted via e-mail. In fact it's pretty standard for things like Passwords and user IDs to be sent this way. Let alone more confidential data sent by users who don't understand the protocol.

Yes, exactly my point! Why then would you trust your post boy (mail server) not to take a peek inside the envelope if it carries sensitive information? That's actually an argument *for* end-to-end encryption!

Furthermore, it would make a great deal more sense to encrypt as standard at the protocol level rather than add another layer of abstraction at the user level


Because TLS is necessarily two-way and hop-by-hop. You can't establish a TLS session via e-mail itself, the round-trip for salt exchange and other protocol setup would be just terrible. That's why we have things like S/MIME and PGP.

Reply Parent Score: 2

Laurence Member since:
2007-03-26


Yes, exactly my point! Why then would you trust your post boy (mail server) not to take a peek inside the envelope if it carries sensitive information? That's actually an argument *for* end-to-end encryption!

I know it is - I was arguing in favour of encryption the whole time *facepalm*


Because TLS is necessarily two-way and hop-by-hop. You can't establish a TLS session via e-mail itself, the round-trip for salt exchange and other protocol setup would be just terrible. That's why we have things like S/MIME and PGP.

I'm aware of that, but even just TLS is a huge step up from where we currently are. However I wasn't saying the encryption method had to be TLS, I just said it should be a requirement in the protocol / specification rather than an addon provided by the client.

At least with enforced TLS, it means that even lazy developers are forced to encrypt communications and it prevents any interception. It "just" doesn't account for hacked mail relays.

Reply Parent Score: 2