> Hmmm. I do not see broad concern. I do see persistent expression of concern from you about this being done > without sufficient something (care, seriousness, whatever). I also see some folks saying that we should just > publish and get it done. That is all in addition to the good and constructive discussion, involving you and others, > with which the above is intertwined, so for me at least, its not a big deal really, just some more mail to get through. I think we should just "publish and get it done." The draft has a very simple function: tell the community that it is OK to do some form of encryption even if in situations where we cannot do the perfect negotiation of really secure and authenticated keys. In fact, tell the community that is not OK to just fall back to plain text when one particular check was missed in the perfect negotiation. Watching the discussion, I see three forms of objections: 1) Objection to the particular name that was chosen to designate this "design pattern." 2) Objection to the whole idea that we should settle for better than plaintext when we cannot do perfect. 3) Objection to the particular wording of Viktor's draft. Stephen just pointed the archives of the SAAG discussion that eventually converged on the "opportunistic security" term. Nobody is in love with that term. It was chosen as a second best after "opportunistic encryption," which was somehow conflicting with a particular usage of IPSEC. But we also got convinced that the name is good enough. The "better than plaintext" consensus is obviously rough. There are two classes of objections. One is the "false sense of security" argument, which is really an argument about the design of user interaction, and which is addressed in the draft. The other is the "middle box" argument, which says that if more traffic stays in plain text middle boxes can do a better job of analyzing or transforming the data in flight. But then, there was a clear consensus at Vancouver to do as much encryption as possible despite these middle boxes, and to evolve middle boxes towards an explicit relation with the end-to-end senders and receivers. So, that part of the consensus is going to remain rough no matter what. Viktor's draft is basically fine. It is short and clear. The various rounds of edits tend to make it "different," but not better. IMHO, it is time to ship it. -- Christian Huitema