Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> Jay Daley <[e-mail]> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Yes, but as ekr pointed out, injecting fake DANE RRs can only
> > > cause the connection to fail, it won't result in the client
> > > connecting to a bogus server.   That's why it's RECOMMENDED
> > > instead of REQUIRED.
> >
> > That's still potentially a devastating DOS attack if done well and
> > against an important target.  Worthy of a REQUIRED for that alone.
> >
> > There is also the layer 9 interpretation issue here - if we say that
> > DANE in its entirety requires DNSSEC then that message can be shouted
> > loud and clear, reinforced and hopefully entrenched.  If we say that
> > only some parts need it then people, for entirely fallible reasons,
> > get confused, doubt DANE, can use this to attack DANE and so on.
> 
> I think this is an important consideration. However a relevant
> question for a 2119-level MUST seems to be whether we wish to have
> this data rejected if not DNSSEC signed.
> What's your view on that?

I'm much less worried about false positives resulting in DoS, which
can be more easily achieved attacking at the network layer (IP, TCP).

What worries me is the false negatives resulting from a
"successful verification" of an unsigned DANE RR.

The prerequisite for a "successful DANE validation" is that the
DANE TLSA record has been DNSSEC validated.  And my concern is that
some GUIs might get that wrong unless the spec is crystal clear
what constitutes a successful DANE validation (DNSSEC required)
and what not.

I'm OK with interpreting even an unsigned TLSA validation failure
as "something is goofy here, abort the connection", but that causes
the DANE validation result to have 3-states "good/not-obviously-bad/bad"
rather than a boolean "good/bad", and a 3-state may get mapped incorrectly
to binary UI indicators (icon present/absent).

-Martin