Re: [dnsext] Practical question about backwards compatibility and new proposals

[Brian Dickson <[e-mail]>]

On Thu, Sep 16, 2010 at 4:19 AM, Andras Gustafsson <[e-mail]> wrote:

> Brian Dickson wrote:
> > RFC 3597 is about "handling" unknown RR types, but I presume that to be
> > rather narrow, in that the new RR type/class is the qtype/class, not
> > something that shows up in an answer as "extra stuff" in the answer, or
> in
> > the "additional" section.
> >
> > Is this (caching of new RR types in answer to questions that *aren't* the
> > new RR type) something that is specified, one way or the other, anywhere
> > yet?
>
> There was some discussion related to this last year, starting with
>
>
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02683.html
>
> To reiterate what I said then, I think the concepts of "RRs of unknown
> type" and "unexpected RRs appearing in some section of a message"
> should be treated as orthogonal.  For example, a type MX record
> occurring in the answer section of a response to a type A query is an
> unexpected RR, but it is not of unknown type.
>
> RFC 3597 deals with unknown types, but I don't think the treatment
> of unexpected RRs is currently specified anywhere.  Existing
> implementations tend to ignore them when they occur in the answer
> section of a response, and may or may not cache them when they occur
> in the additional section depending on spoofing defense strategy.
>
> If we end up specifying the treatment of unexpected/unsolicited RRs,
> I think whatever treatment we specify should be the same whether the
> type is known or unknown.
> --
> Andreas Gustafsson, [e-mail]
>

Excellent point.

This, and the discussion regarding DTLS in another thread, suggest that
(a) there is a problem with introducing new types, generally,
and (b) changing what should be expected is also a problem, particularly
for caches and middleboxes.

I think the gist of 3597-bis, and the discussion around it, is that changes
to what is "expected", introduce a potential security problem.

I think the answer comes from DNSSEC.

DNSSEC provides the means to validate RRsets, even if the type/class is not
known.
The signature algorithm is well defined, as is the proof mechanism, for
validating
from a known trust anchor.

This provides two paths through a middle box.

First is have the middle box validate the unexpected or unknown RR.

The second is to have the middle box not validate, but to only provide
cached
RRs that are unknown/unexpected, if the CD bit is set. In this case, CD
means
not only does the client do validation, but the client may understand better
than
the middle box, what the unexpected stuff is and how to deal with it.

In both cases, the end-to-end path from the authority server to the client
is authenticated,
which means that the security issue is no worse than, and probably better
than, the case
where the RR types are known and expected.

What do folks think?

Brian