Re: Welcome to the ietf-apps-tls mailing list
Chris Newman <[email protected]>
| Newsgroups | gmane.ietf.apps-tls |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 7 May 1997, Mike Macgirvin wrote: > Hmmm. Then you recommend that once we've gone through the trouble of > establishing a trust channel with the first MTA in the chain, that we then just > throw our message to the wolves once it's left that system. I'm typically not > too worried about the wire going from me to the nearest server. In most places > I've worked, I could physically inspect it if I wanted. I'm REAL worried about > the other 100 wires between that server and my message destination. The problem is that once the message gets to the other end of the wire, it's unencrypted. So the message is vulnerable at every node, it's only secure when in transit between nodes. It order to get a secure path, one has to trust every node, which is unlikely from a policy standpoint, especially considering lack of DNS security and MX fallback issues. It's dangerous to advertise something as secure when it really it's really less secure than users will assume. > Object security has a high cost in perceived delay time to the end user during > message retrieval. Certainly it's more secure and easier to maintain than a set > of trust/verify relationships, but it bites hard on dialups if your mailbox is > suddenly 90% base64. It also does not address security tunneling via the > message envelope and header; which often betray the contents. We're working on a proposal to do "application/batch-smtp" wrapped up in a multipart/encrypted to get MTA to MTA secure tunnelling. That allows one to pass the message through untrusted nodes, yet still decode it before dropping it in the recipient's mailstore.