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

[Petr Špaček <[e-mail]>]

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