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