Re: [dns-privacy] Registry framework for draft-ietf-dprive-early-data

[Ilari Liusvaara <[e-mail]>]

On Thu, Jul 23, 2020 at 12:57:02PM +0100, [e-mail] wrote:
> On Wed, Jul 22, 2020 at 10:26:52PM +0300, Ilari Liusvaara wrote:
> > On Wed, Jul 22, 2020 at 12:00:43PM -0400, Brian Haberman wrote:
> > > Hi all,
> > >      I have a proposal for the working group that I would like some
> > > feedback on. https://tools.ietf.org/html/draft-ietf-dprive-early-data-00
> > > calls out the need for an IANA registry to track which RR Types are
> > > allowed to be carried as early data during the TLS session establishment
> > > process. Rather than creating yet another IANA registry, I propose that
> > > we add a column to the current RR Type registry that indicates whether
> > > the RR Type is allowed as early data. For reference...
> > > 
> > > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
> > > 
> > > Thoughts on this?
> > 
> > I think this is a Bad Idea.
> > 
> > The fact that RRTYPE is data RRtype (1-127, 256-61439) already
> > establishes it is safe to send as QTYPE in QUERY. Having any unsafe
> > things there would already cause major security issues, as DNS
> > specifications are very clear that servers MUST NOT refuse
> > requests by data QTYPE. Yes, some data TYPEs are special (especially
> > NS, CNAME and some DNSSEC stuff), but it is still requirement to not
> > have any harmful effects.
> > 
> > However, this does not make any of them safe, only that none is
> > specially unsafe. With recursives, bad things happen if network
> > attacker can replay 0-RTT data after cache expiry. At worst, this can
> > completely compromise the query contents. It looks that one could
> > check the ticket age with fairly tight tolerances (failing is only
> > one (likely fast) extra RTT) to prevent this from happening.
> 
> Are you saying we shouldn't have a list of allowed RR types at all and just
> limiting to QUERY messages is enough? I asked this question at the last meeting
> and the responses were mixed.

I was thinking QUERY messges with data TYPE and data CLASS. Which is
subset of QUERY messages.

Looking at the minutes, I see mention of needing to be idempotent.
Actually, I think one wants a stronger property that is analogous to
"safe" in HTTP. And I think all data QUERY are meant to satisfy that
stronger property. More specifically, "safe" roughly means "no state
change", while "idempotent" roughly means "indepdent of order".

And when it comes to problematic behavior, I do not expect the esoteric
types to be the problem, I expect problems to lie in the well-known
types. This is because unless authoritative or recursive server
specifically supports some TYPE, it treats it as plain data. And there
are limited oppurtunities for anything to go wrong with that. And
esoteric types are unlikely to be specially supported. Furthermore,
DNS pretty strongly constrains what recursives can do.

And the types that worry me the most for potential of special handling
are A and AAAA. There are CDNs, which definitely do some very special
stuff with A and AAAA records. Then I have seen some servers that do
special things with TXT records. None of these behaviors is anything
really dangerous (as that would be a major security issue), but could
leak data if requests are replayed.

Then there is RRSIG, which seems bit alarming. While direct queries
should not do anything special, I noticed two troublesome properties:

1) The answers can be pretty large (amplification hazard with UDP).
2) The queries can be really slow compared to other types.

I don't think anything legimately uses direct RRSIG queries. DNSSEC
sends partial RRSIG answers as needed (AFAIK, this is the only case
where DNS data rrsets are not atomic).

And when it comes to early data profiles, I think most define
specicial error code meaning "not allowed in early data, try again"
(e.g., HTTP 425 status), instead of using generic parse error.
New error code in DNS would need EDNS tho (which should not be that
problematic requirement). 

> I'm not against removing the list btw, though I guess it would be helpful to
> hear from people who disagree on why they disagree.

Yes, I would very much like to hear if there are any more unpleasant
surprises lurking here.
 
> > However, there is a potential source of unsafety even in QUERY
> > with data QTYPE: EDNS extensions. The base EDNS is safe and essential.
> > However, EDNS extensions can do who knows what, and some of them might
> > be very much not safe. However, there are some that seem useful.
> > 
> > On useful end, there are various DNSSEC advertisment extensions (e.g.,
> > ??U and edns-key-tag). As well as Extended DNS Error. On dubious end
> > there are things like LLQ and UL (and potentially other stuff as well).
> 
> I guess we can add some text on EDNS to the draft as well.

I suspect coming up with what is useful and what is dubious would
actually need looking at what the various EDNS extensions do. Allow
all or deny all is not likely to be right thing to do.


-Ilari