Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Brian Dickson <[e-mail]>]

On Wed, May 12, 2021 at 12:28 PM Eric Orth <ericorth=
[e-mail]> wrote:

> I have no strong opinions on any of the discussions regarding escaping in
> presentation mode because I don't have much involvement in dealing with
> presentation mode of DNS records.  The client I work with parses wire
> format directly into its internal structures.
>
> From my wire-format-only perspective...
>
> I strongly oppose breaking out the key/value pairs of the current proposal
> into separate records within an RRSet.  The "independently meaningful"
> records argument in favor of per-endpoint records isn't just some small
> nice-to-have but is actually rather crucial to avoiding
> inconsistent/missing-data issues that could easily become security issues.
> Per-key/value records opens things up to too much error-proneness where the
> separate records get cached separately (with potentially differing TTLs),
> so there's a lot more room for clients to end up receiving/handling only
> some parts of endpoint data without a clear indication that other parts are
> missing.  Could be much more problematic than just getting a partial view
> of the endpoint options.  Easily becomes a security issue, e.g. when a
> client gets most of the records for an endpoint but misses the record
> containing the ECH config.
>

Sincere apologies in advance for any offense you may take from this.

However...

You are completely mistaken in this concern.

The DNS RFCs collectively, and in their entirety, forbid any of the
following:

   - Breaking up RRSETs
   - Having RRSETs with Resource Records that do not have identical TTLs
   - Servers sending anything that does not comply with this
   - Clients accepting responses with any of these problems (clients are
   required to ignore such responses)

In short, none of the things you present as concerns can occur if the
resolvers or authority servers are at all RFC-compliant.
There is no need to design your protocol to defend against these issues, at
all.
(This is documented clearly in RFC2181, and further referenced for clarity
purposes in the DNS Terminology RFC, RFC8499.)

Responses including partial RRsets are as unlikely (and as illegal) as a
response to a query for SVCB being a TXT record saying "I'm a teapot".

Please take it as read that queries for an RRTYPE will always return an
RRSET which is complete and has uniform TTL values.

Concerns over MITM tampering of results can be addressed by use of DNSSEC,
where the RRSIG (signature) is over the complete RRSET and included with
the RRSET itself. It is literally impossible for a MITM to tamper with a
signed response which will pass the validation by the recipient.

A MITM can just as easily modify the singular RR containing all the
key/value pairs together, so the concern is either moot or invariant
regarding single vs multiple records.

IMNSHO, the wire-format discussion should not be excluded as a result of
your concerns, if the RRSET integrity is your only concern.

Sincerely,
Brian