Just to note that this has wandered off topic, but is a fine separate topic. Could be better on saag maybe but please change the subject if continuing here. Reason this is a different topic: this is about a new protocol and is not something that'd be covered by the proposed iesg statement until much later after it'd worked out well. Thanks, S. On 04/10/2014 12:51 PM, Phillip Hallam-Baker wrote: > On Wed, Apr 9, 2014 at 10:01 PM, Randall Gellens <randy@xxxxxxxxxxxxxxxx> wrote: >> At 9:12 AM -0400 4/9/14, Phillip Hallam-Baker wrote: >> >>>> To that end, I could imagine a requirement for some kind of roadmap. >>>> "The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and >>>> Z. After <date>, we require them to use Secure X, Secure Y, and Secure Z, >>>> and traffic originated by the IETF sites shall use such protocols." >>> >>> >>> This sounds like a good idea. >> >> >> To me it sounds like a knee-jerk reaction rather than an assessment of what >> we need to protect and what the costs are of various mechanisms. >> >> >>> But we currently have a big problem in >>> that the IETF has two email security standards, not one. And the two >>> sides don't talk and this has created a stalemate that has blocked >>> ubiquitous use of either. >> >> >> We actually have a few more email security standards, but regardless, I >> don't think the major barrier to deployment is that there is not a single >> standard. There are a number of reasons why email end-to-end encryption is >> rarely used, which include the difficulty of managing keys, but it's also >> worth pointing out that end-to-end encrypted email breaks a lot of the >> anti-spam, unless users share their private keys with their mail provider >> (which kind of defeats the point). > > As a meta-point, people can disagree with me over whether I have > solved all the problems but I am pretty sure that I already know most > if not all the problems that people come up with after thinking about > the problem for a few minutes. I have been discussing this for quite a > while now and I used to sell S/MIME as a main product for about ten > years. I have discussed the problem with Callas and Zimmerman. > > Too much security is a really easy problem to solve: allow people to use less. > > > There are many reasons why end-to-end is not the only model that a > message layer encryption system should provide. It actually doesn't > break as much anti-spam as is imagined. Content-analysis is not a > powerful anti-spam technique. But there are some situations in which > archiving is required for regulatory reasons. > > The end-to-end model should be an option, not a requirement. > > I am very comfortable with a model in which 95% of my mail is > encrypted to a key held by my mail provider and the 5% that I consider > to be sensitive is secured under an end-to-end key only I hold and > mail is only accepted under that key from pre-approved senders. > > > I go into a very full requirements analysis for making secure email work here: > > http://www.youtube.com/watch?v=06KyOCtjxLs > > > The end-to-end model is really not a useful one for security > discussions because the ends of the IP channel are not the same as the > ends of the conversation. The important part is being able to know > where the end-points are so that senders can make a decision on that > basis. > > S/MIME and PGP don't actually enforce an end-to-end model. But because > they assume that is all that is wanted they make end-to-end an all or > nothing proposition. > > Since my security concerns are a little different to most I would > probably end up with a three tier model in which mail from people I > don't know goes to the Gmail/Postini decryption key, most mail from > most people I have whitelisted goes to a decryption key that is on all > my machines I configure for mail and I also have a key for sensitive > stuff that is only on one or two machines or is in a smart token. > > I can make the two tier scheme transparent from a usability point of > view but when we get into three or more tiers it starts to demand more > of users which is why I would not make it default. >