On Sun, 17 Aug 2014, Dave Crocker wrote:
> 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.
I hope you will forgive my confusion, but I'm not sure what confusion my
statement is supposed to be an example of. My best hypothesis so far is
that this is supposed to refer to your question about whether the term
"design pattern" concerns basic functional differences or specific
functional differences, but I'm not entirely sure.
> There is nothing in the document that clarifies the point.
I do not dispute that the draft could make this point in a much clearer
fashion; I have not gone over it with a fine-enough-toothed comb to make
the claim that it contains "nothing" to clarify the point, though.
> 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.
I would say that the term "design pattern" can apply to either basic or
specific differences, depending on the context in which it is being
applied. In this specific case, I would like it to actually apply to both
(in that I see the optimistic security family of protocols including both
general recommendations ("use encryption") and specific ones ("if you can
use DANE as a trust anchor, attempt to do so, but fall back if there is no
record").
-Ben