On Fri, Aug 15, 2014 at 01:26:39PM -0700, Dave Crocker wrote: > > While you seem to be saying opportunism is "In absence of > > mandated authenticated encryption, try to use unauthenticated > > encryption". > > My definition: > > Opportunism is the flexibility to use less-stringent protection, > when stronger protection is not possible. This is a definition of something else. That something is not the subject of the draft. > > > What Viktor is saying is that the parapraph in question makes sense > > using his interpretation of the definition, and does not make sense > > with your interpretation of the definition. > > > > Clearly we have work to do to ensure there is only one interpreation of > > the definition. > > Yup. Insisting that the draft should be defining something else is not progress towards helping more readers arrive at a convergent interpretation of the subject matter. This sub-thread will become more productive, once the subject of the definition or exposition (as imperfect as that might be) is accepted as a starting point, and what we're discussing is how to improve the clarity. The subject is introducing the OS design pattern. The OS design pattern as introduced, is to set a least common denominator baseline (crypto)security policy (that might well be cleartext) and from there do better whenever possible for each peer. For some unathenticated encryption is the best one can do. For other peers authentication can be signalled and enforced. The somewhat clumsy phrase "opportunistically employed" attempts to capture this, without running into terminology trouble by talking directly about "opportunistic encryption" or "opportunistic authentication", at least the first of which is a booby trap due to conflicting usage. If someone can help improve the text that uses that construct, that would be great. Constructive comments will help to clarify the exposition of the idea that can be casually summarized as: "spring forward" not "fall back". Another key pillar of the draft, is that OS designs need to not create obstacles to communication. In any OS design, whatever security mechanisms are enabled based on peer signalling need to be much more operationally reliable than present state of the art. If an OS design cannot be enabled by default, and constantly pops up dialogues for users to approve exceptions, then that design is a failure. -- Viktor.