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

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Jul 2020 12:00:43 -0400

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?

Regards,
Brian

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Jul 2020 22:26:52 +0300

> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

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.

Types that are not data RRtypes might be more mixed bag. Those may
have side effects, and also contains the infamous TYPE *. The reason
that TYPE is infamous is that its semantics are not quite sensible,
and especially that it tends to cause large answers.

Then there are CLASSes. The data CLASSes (1-127 and 32768-57343) need
to be safe. The other defined classes are NONE and *, which have no
sensible semantics in QUERY. Also unlike unknown TYPEs, unkown CLASSes
can be refused (REFUSED is sensible for authoritative, and NXDOMAIN for
recursive).

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).

-Ilari

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 22 Jul 2020 15:45:15 -0400

On Wed, Jul 22, 2020 at 3:37 PM Ilari Liusvaara <[email-masked]>
wrote:

> completely compromise the query contents.

The "near-resolver" attacker you're describing can already compromise the
query contents of any query that misses the cache, so I think this
vulnerability is unavoidable, and we should not regard it as in-scope.
ADoT upgrade would be a suitable mitigation, but restricting 0-RTT is not
sufficient.

---

From: [email-masked]
Date: Thu, 23 Jul 2020 12:57:02 +0100

> 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'm not against removing the list btw, though I guess it would be helpful to
hear from people who disagree on why they disagree.

> 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.

Cheers

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Jul 2020 16:36:27 +0300

> 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). 

> 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.
 
> 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

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Jul 2020 02:58:29 +0100

> 2) The queries can be really slow compared to other types.

Yes. From an implementation perspective, RRSIG queries work in a very
similar way to ANY queries. They have the advantage that no-one is likely
to think an RRSIG query is useful, so it's reasonable to NOTIMP them.
If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth: Variable 4 or less, becoming east 3 to 5 for a time. Smooth or
slight becoming slight or moderate. Fair. Good.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 29 Jul 2020 22:13:59 -0400

> If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too.

I don't see the connection with early data.  TLS 1.3 early data is
address-validated (no amplification-reflection), and slowness seems
entirely orthogonal.

Tony.
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 31 Jul 2020 22:29:37 +0200

> If QTYPE=ANY is forbidden for early data then QTYPE=RRSIG should be too.

NOTIMP tells the client 'I do not support the QUERY opcode'. That is
not a message you want to send out, unless you want people to just stop
querying you.

(PowerDNS has picked REFUSED as the response to RRSIG queries).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 31 Jul 2020 22:32:17 +0200

> and the responses were mixed.

Looking at the list of types, I can't even guess why these types would
be safe and others would not be. If you're going to have a list, it
would be good to explain why those types are on it and the rest is not.

> hear from people who disagree on why they disagree.

I'm no expert on 0-RTT, but I suspect a list of types does not make a lot of sense here. Either early data is safe (for the QUERY opcode), or it's not, unless I'm missing something.
 
Kind regards,

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 31 Jul 2020 13:41:54 -0700

> would be good to explain why those types are on it and the rest is not.

You still need an explanation even if there's not a specific list
(vs. just "all types are allowed").  An application profile allowing the
use of TLS 0-RTT data needs to identify which messages are safe to use
with 0-RTT and I'm quite willing to put up a Discuss point if such guidance
is not backed by compelling reasoning.

-Ben