I'm sorry I'm late, this thread was in my backlog. On 12.03.2011 19:48, Dean Willis wrote: > On a related note, we've developed what we think is a secured mail > protocol suite. Yet we don't use it, instead subjecting our list members > (and more so the administrators) to having to deal with an endless barrage > of spam. We probably don't use our secured mail protocol because it is too > cumbersome. Maybe that should be a wake-up call for us to develop a better > way to secure mail. What secured mail suite? I have some difficulty in recognizing whether you're talking about SMTP + Submission + DKIM + whatever else or some other messaging system. I agree that current Internet mail, with its one-figure legitimate traffic percentage, is a conspicuous representative of IETF's hall of shame. > Most critically, we've recognized that Internet users may have needs for > privacy [...] And having recognized these principles, we need to start > taking much more aggressive steps in protocol design to assure that they > are actually being met in a useful way. I also heartily agree with this, and with all the motivations that inspired this thread. However, I have difficulties resolving my feelings on this point: Freedom activists in my country bring out a whole load of grievances every time Berlusconi attempts to restrict usage of wiretapping. In facts, this tool is a requirement for carrying out investigations at a sustainable cost. I think the IETF must substantiate its position against wiretapping by providing alternative practical means to counter crime. Failing to do so would recast ourselves as proposers of Utopian designs. And, yes, after more than a decade of spam supremacy, email would certainly be a convincing test-bed for our ability at providing such alternative means. > We can start by: > > 1) deprecating the non-secured variant of every core protocol that has > both secure and non-secure variants Among SMTP variations, RFC 4409 is the more promising requisite for solving a number of authentication issues. Note that it conflicts with peer-to-peer visions à la mondonet, though. > 2) not writing any more protocols with secured and non-secured variants > > 3) analyzing existing protocols that are fundamentally non-secured and > determine which, if any, security enhancements should be made normative While these are certainly correct, ensuring implementation and deployment is also fundamental. I accept and respect the limits of IETF's action, and consider non-enforcement a key feature in the volunteer-oriented design that is being carried out. However, we should pay more attention to the full protocol life cycle. > 4) Doing a much better job of really analyzing the security considerations > of new work, taking fully into account the principles of privacy, > integrity, and obscurity. Keep in mind that every protocol has the "good > citizenship" responsibility not just of addressing these principles > itself, but of also helping its fellow citizens meet them. I understand this as a recommendation to provide means for users of a protocol --either another protocol or the "end" user-- to discover in some meaningful way what are the relevant characteristics of the current communication. By "meaningful" I mean the opposite of those audible but unidentifiable beeps that all too frequently infest work rooms :-) > 5) Incorporating the principles of Privacy, Integrity, and Obscurity > directly into our core mission statement, into the very fabric of our > belief system, just as "Liberté, égalité, fraternité" became the driving > motto of the Third Republic of France, ending much of the abuse of > Privilege that preceded the revolution. Yes, and, like for points 2-3 above, we must take care of how these principles are understood by the community at large. Skepticism, opportunism, and thoughtlessness have spread too much. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf