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