Agreed, but! Let us drop the end to end ideology in the dustbin and accept that email is an MTA to MTA protocol, or to be more precise it is three protocols:
MUA -> MTA: SMTP/SUBMIT or HTTP MTA -> MTA: SMTP MTA -> MUA: POP / IMAP or HTTP Note the presence of HTTP. People have been discussing email as if SMTP == email. In fact a huge proportion of email travels over HTTP instead of SUBMIT or POP/IMAP and quite a bit flows over HTTP alone (all email from one gmail account to another, or hotmail, yahoo, yadda yadda). For Alice and Bob there are many possible paths: I very often start writing an email message on one machine and continue on another. In the course of a typical day I use a minimum of one PC, one Macbook, one iPhone and my work iPad. So for me it is actually quite usual for me to start writing an email on the Mac and continue on the PC. I typically read the messages on whichever one of the four machines is close at hand. So the arity of the relationships is: MUA -> MTA: Many -> 1 MTA -> MTA: 1 -> 1 MTA -> MUA: 1-> Many Now a good email setup should of course have multiple MTAs. But they should have a setup that makes them look like a single logical unit. There are many mail servers for example.com but only one logical mail service. So now we see why security policy driven by MUA published security policy is going to fail: there is no consistency in the MUA loop. I read mail on four separate devices. They have no way to communicate between themselves to negotiate a common security policy and I certainly would not want them to. Conclusion: 1) Security policy is a property of MTAs and not MUAs and hence of domains and not accounts. 2) We need a security policy layer for the internet as a whole and not just for what people imagine to be the 'Web' or 'email' portions thereof. This is a problem caused by stovepipe thinking and non-my-problemism. A SUBMIT MTA should tell the MUAs that it serves how to connect to it. That is the port, protocol, use of TLS and certificate chain. An SMTP server should likewise tell MTA clients what its security policy is (use of STARTTLS, use of certificate chain, availability of SMIME/PGP), authentication requirements. The MTA -> MUA loop is interesting in that the directionality of the protocol changes. The data has been flowing from client to server, now it flows from a server to a client: Client -> [Server : Client] -> [Server : Server] -> Client So the POP or IMAP service would again publish policy telling clients to connect. Not that this is also a usability win. No more check boxes to tick in order to get the configuration params right. Add the capability for MTAs to publish policy and we can establish a hop-by hop security mechanism that covers each of the three mail interactions in three separate end-to-end sessions. Getting back to the bigger problem, no this is not solving all the problems we are seeing in the Web space. But it is solving a pretty big one there. Web security is harder to improve than email security because we already have quite a bit of Web security and very little email security. On Thu, Feb 9, 2012 at 12:35 AM, Nico Williams <[email protected]> wrote: > E-mail is not an online protocol between two MUAs. When you send an > e-mail your MUA is not talking directly to the recipient's MUA, and > there are no automated replies except for vacation replies. > > Thus in a cold-call e-mail send you have no knowledge about the > recipient's MUA's capabilities. You can only sign your e-mail and > hope that the recipient can validate the signature. > > If you know the recipient's public key and can derive some knowledge > about the recipient's MUA's capabilities from that public key and > surrounding material, such as a certificate or other metadata, then > you can send signed and encrypted e-mail to them. The required > metadata -the recipient's MUA's capabilities- are found where the > recipient's public key is found. That metadata has to be somewhere, > but e-mail headers isn't that somewhere. This limits your and your > correspondents' ability to switch to other MUAs: they'd better support > the capabilities that you've advertised with your keys. > > Sure, we could build a TLS-like protocol out of e-mail, if MUAs knew > how to speak to each other the mail network. You'd say you want to > send e-mail to [email protected] and your MUA could send a > specially crafted e-mail that Joe's MUA understands as a ClientHello > (and which Joe wouldn't see, as it would do Joe no good to see it), > responding with ServerHello and so on, and then you have a session key > that you can use to send encrypted mail to Joe. And then we'd need to > negotiate cipher suites and such just like TLS. But that's not how > e-mail works. You send an e-mail, and hopefully it gets there, and > there's no automatic ping-pong until keys are established, there's > only that one e-mail. > > That's why S/MIME and PGP work the way they do. There are reasons why > S/MIME and PGP haven't become killer apps (and someone who knows much > more about them than I can lay them out), but lack of a header by > which to communicate MUA capabilities is not one of them -- we would > have solved that long ago if it had been. > > Nico > -- > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
