On 8/16/2014 8:17 PM, Benjamin Kaduk wrote: > On Sat, 16 Aug 2014, Phillip Hallam-Baker wrote: >>> DANE isn't opportunistic security. It is authenticated security >>> policy and keys. Thats the opposite of opportunistic. > There is a protocol design pattern that involves optimistically > checking for and using DANE records where they exist, This is an example of confusion about the meaning of the term design pattern. It is, equally, an example of the draft's limitation in carefully documenting the concepts it is attempt to teach. There is nothing in the document that clarifies the point. By my reading of the current draft, it discusses the distinction between authenticated and unauthenticated encryption. However it does not indicate that there is an important difference between one kind of authenticated versus another kind of authenticated. In other words, does the term design pattern concern basic functional differences (eg, authenticated vs. not authenticated) or does it concern specific functional differences (CA-based authenticated vs. DANE-based authenticated)? My own view is that the utility of the term offered in the current draft concerns only very basis differences, and such details as which kind of exsternal authentication 'anchor' is used is of less import. Well... perhaps the difference between a TOFU and an "anchored" authenticated matter. But I do not see what significant utility is achieved by distinguishing between different types of anchored (independent, fixed, ...) authentication is used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net