Subject: [DNSOP] questions about Signaling Cryptographic Algorithm Understanding (RFC 6975)

From: Petr Špaček <[email-masked]>
Date: Wed, 3 Jun 2020 11:40:42 +0200

Hi dnsop,

it seems that OpenDNS is the first to implement RFC 6975:
https://lists.dns-oarc.net/pipermail/dns-operations/2020-June/020219.html

This reminded me of its existence so I looked at definition for validating recursors:

4.2.1.  Validating Recursive Resolvers

   A validating recursive resolver sets the DAU, DHU, and/or N3U
   option(s) when performing recursion based on its list of algorithms
   and any DAU, DHU, and/or N3U option lists in the stub client query.
   When the recursive server receives a query with one or more of the
   options set, the recursive server MUST set the algorithm list for any
   outgoing iterative queries for that resolution chain to a union of
   the stub client's list and the validating recursive resolver's list.
   For example, if the recursive resolver's algorithm list for the DAU
   option is (3, 5, 7) and the stub's algorithm list is (7, 8), the
   final DAU algorithm list would be (3, 5, 7, 8).

   If the client included the DO and Checking Disabled (CD) bits, but
   did not include the DAU, DHU, and/or N3U option(s) in the query, the
   validating recursive resolver MAY include the option(s) with its own
   list in full.  If one or more of the options are missing, the
   validating recursive resolver MAY include the missing options with
   its own list in full.

What is your opinion on:
a) Sending RFC 6975 EDNS options with queries which target zone cuts which are not signed (DS provably not present in parent)?
 That sounds like waste of bytes, but maybe it is not worth optimizing. Opinions?

b) It is not clear if/how authors took into account deduplication of queries:
   the recursive server MUST set the algorithm list for any
   outgoing iterative queries for that resolution chain to a union of
   the stub client's list and the validating recursive resolver's list.

Multiple queries from stubs can translate to a single upstream query. Typically this happens for very frequently asked names on cache miss event. E.g. many stubs ask "www.google.com AAAA" but recursor can optimize traffic upstream and send only single query to auth.
Of course stub queries will likely not arrive simultaneously so the first query to auth (possibly with union of algo sets) is already in flight when second stub query (possibly with diffent set) arrives. Now what?

(Section 7. Traffic Analysis Considerations shifts the problem to oneone else, but I think deduplication trick + interaction with DNS cache should be pointed out because it significantly complicates analysis.)

c) Is union of sets even a good idea? Why not copy ENDS options from stub and append _another_ "instance" of options so the auth can see there are multiple parties with different set of options?

d) Is there a risk of inflating queries too much/new attack vector? What about stub sending EDNS option with all alg fields present (700+ bytes)? Should there be a limit on number of algs? (I cannot see any in the RFC.)

e) What should happen if multiple options are present? Answer with FORMERR? (But see questions c,d above.)

Thank you for opinions!

P.S. Sorry for opening this topic again, but this seems like another example of RFC which would benefit from more implementation experience prior publication.

-- 
Petr Špaček  @  CZ.NIC

---

From: Brian Somers <[email-masked]>
Date: Thu, 4 Jun 2020 09:02:05 -0700

> That sounds like waste of bytes, but maybe it is not worth optimizing. Opinions?

The OpenDNS/Cisco implementation doesn’t optimize for this.
If a nameserver does EDNS, it gets these codes.  I don’t yet
know if this is a naive approach - we’ve already had to turn it
all off due to www.qq.com nameservers returning SERVFAIL
(It has since been fixed).

> (Section 7. Traffic Analysis Considerations shifts the problem to oneone else, but I think deduplication trick + interaction with DNS cache should be pointed out because it significantly complicate…

The OpenDNS/Cisco implementation doesn’t remember downstream
option codes in any way once the client is answered.  An upstream
query to a nameserver will include client codes & algorithms if
present, but only for the client being “charged” for the upstream query.

> c) Is union of sets even a good idea? Why not copy ENDS options from stub and append _another_ "instance" of options so the auth can see there are multiple parties with different set of options?

That would certainly be easier in the resolver.

> d) Is there a risk of inflating queries too much/new attack vector? What about stub sending EDNS option with all alg fields present (700+ bytes)? Should there be a limit on number of algs? (I canno…

I explored behaviours, including inflating the packet size to >512
bytes and sending the query over TCP.  After a bit of
experimentation I discovered that dig (9.11.5-P4-5.1-Debian)
already made a call on this by limiting the # algorithms to 122.

So I introduced a configuration option in our implementation that
allows values between 0 (off) and 122, defaulting to 15.  If we
end up with more than the configured number of algorithms for
any of DAU, DHU or N3U, we drop the client data for that code.
If we’re still over with our own algorithms, we drop the code
altogether.

This allows us to limit ridiculous client data and to turn it all off
quickly If required.

> e) What should happen if multiple options are present? Answer with FORMERR? (But see questions c,d above.)

We answer FORMERR.

> P.S. Sorry for opening this topic again, but this seems like another example of RFC which would benefit from more implementation experience prior publication.

—
Brian