Early Review of draft-ietf-dance-architecture-06
review-ietf-dance-architecture-06-dnsdir-early-cunat-2024-07-19-00

Hello.  While reviewing I focused on DNS aspects, though I didn't find much of
that, mainly utilizing some properties of DNS that were there already.  (And I
sent some typos directly as a pull request.)

I'd prefer some parts around DNSSEC better clarified.  The 5.2 integrity
section mentions (twice) a compromise of servers that *host* a zone.  I
consider "host" a misleading word here, as the important part for integrity is
only the server that signs the zone.  (servers that serve the zones would be
more about 5.3 availability)

Similarly, in 5.3 a connection is made between key revocation/rotation and TTL.
 But it should be noted that TTL values are not really secured, so e.g. a MITM
can keep serving old records until their *signatures* expire.  This tradeoff
around expirations is somewhat similar to the one around TTLs, though.

> In these cases it is important to consider the architecture of the
> DNS zone and when possible use a tree-like structure with many
> subdomain parts, much like reverse DNS records or how telephone
> numbers are represented in the ENUM standard (RFC 6116).
> [...] We may want to have a discussion [...]

I don't have any real data at hand, but from what I've heard this splitting up
into not-too-huge zones can help with speed of updates in some server
implementations.  So this "adding of dots" into the proposed naming schemes can
be an aspect to consider; a particular zone owner can then choose whether to
split zones at some dots or not.

Note that this tradeoff will surely increase the total number of queries from
resolvers, be it for QNAME minimization or to obtain the DNSSEC chain that got
longer by inserting zone cuts.  Various large zones do exist in the wild
already, say signed ccTLDs with million(s) of records and update time within
several minutes.

> If an authoritative resolver were configured to respond quite slowly
> (think slow loris [XXXrefereceXXX]), is it possible to cause a DoS on
> the TLS server via complete exhaustion of TCP connections?

Nit: I'd say this is tangential.  There are many ways of attempting DoS, with
risks increasing for public servers and/or resolvers.  I fail to see why single
out this one particular attack approach in this RFC.  (BTW, what's
"authoritative resolver" anyway?)

Wes> Hopefully earlier than a month, but we'll see.

I'm sorry about the timing; I didn't notice this context early either.  Please
CC me <vladimir.cunat@nic.cz> with follow-ups.

--Vladimir