Re: [dane] Behavior in the face of no answer?

[Andrew Sullivan <[e-mail]>]

I know, replying to myself. 

On Tue, May 15, 2012 at 10:55:06AM -0400, Andrew Sullivan wrote:

> In the DANE case, as you point out, what we're doing is adding to the
> DNS supplementary data about a different data path.  That's the reason
> that, when you get an error or don't get a response, you need to draw
> a conclusion.  This is an unusual thing to do with the DNS.

An off-list conversation with Paul Hoffman (thanks, Paul) leads me to
try to make this more precise.  What we are doing in the DANE case,
with uses 0 and 1, is to add constraints to the operation of another
protocol.  That is, use 2 and 3 provide a full-blown change to another
protocol.  E.g., 3 says "use this cert or key" so you don't end up
following an X.509 chain of trust when doing your TLS negotiation.
But 0 and 1 don't do that; instead they say, "Do your PKIX work as
normal, but here's an additional constraint." 

This adding of constraints is the thing that is unusual to do with the
DNS.  Paul convinced me pretty quickly that this is not the first time
we've done it, but it's unusual enough that when we do it we may not
realise what we're doing.  (On reflection, for instance, I think that
SPF, when used with a mail server that rejects the mail at EHLO due to
SPF failure, amounts to a case like this.)

I am currently calling these cases "constraint assertions in the DNS"
because I don't have a nicer name.  I think those calling for funny
handling of normal DNS conditions like error messages have identified
a fundamental need in constraint-assertion cases, because if one
cannot receive a message about the existence of such a constraint
assertion, one has a problem.  

This doesn't leave me more certain of what to say in the draft, but at
least I have a clearer idea of what's at issue.  Does anyone else
think this way of thinking about the difference is helpful?

Best,

A

-- 
Andrew Sullivan
[e-mail]