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

[Brian Somers <[e-mail]>]

On Jun 3, 2020, at 2:40 AM, Petr Špaček <[e-mail]> wrote:
> 
> 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?

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

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

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 cannot see any in the RFC.)

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.

> 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

—
Brian