> The environment has changed a great deal. I don't know why people > thought MITM attacks weren't feasible in 1996 -- Joncheray published a > paper on how to carry them out in 1995 -- but they're now trivial. There are some meta-problems with this thread. (Aside: John K has raised his own perspective on some of them and I'd like to try to raise mine. I don't see them as conflicting with John's, but rather I'd like to treat them as separate just to avoid having to worry about synchronization. If they overlap with his, fine. If not, well, that's fine too.) This draft BCP touts some basic practices to improve the accountability of mail systems that are injecting messages into the global Internet. It cites a range of specifics, for performing those practises, notably with respect to some security functions. Mostly, it cites those specifics in order to make give body to the higher-level recommendations it is making. It does not particularly recommend one over the other, nor do I believe it should. Notably it does not invent any technologies or practices. Rather it tries to document and recommend some broad operations practices that are established and that result in some general improvements in the email service. The line of discussion about a particular algorithm reflects the rather unfortunately tendency to have every system-level effort involving security get dragged into low-level debates about basic algorithms and about the current views of various experts in the security community. That's no way to run a standards effort. First, if the algorithm in question is so terrible, surely the large number of folks using it would be experiencing some problems by now. It is not as if we are lacking in attackers exploiting easy holes in Internet services. And surely there would have been global alarums raised about this algorithm, given its widespread use and it weakenesses. The current reality is that the ops and apps areas get to play a guessing game, in the sure and certain knowledge that they will guess wrong. The security community will always find fault with our choices. Unless and until the security community can provide the applications and operations community some common "packages" to use, just as transport, network management and routing do, then we are never, ever going to make serious progress using meaningful security. Yes, I know the arguments for why this is difficult. And yes, I know that security folk claim it is impossible because every service is unique. That's not good enough. If the security is going to press for use of good security, then it needs to provide far more turn-key solutions to those developing services. Simply requiring that every service be developed with security expertise and solutions that are unique to the service is a model that clearly does not... scale. Having debates about what is currently in vogue among various experts is a fine thing to do... among the experts. But it is entirely inappropriate to have these spontaneous debates in the middle of pursuing a document specifying current practises. If there is consensus among the security community that particular, established practises are no longer viable, then please go through the usual IETF processes for documenting community consensus about it. At that point, it will make sense for the operations and development community to adjust what it specifies. Until then we are stuck with the vagaries of individual opinions and as I recall, that's not what the IETF is supposed to be driven by. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf