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

[Eric Orth <[e-mail]>]

On Wed, May 12, 2021 at 4:28 PM Brian Dickson <[e-mail]>
wrote:

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

Agreed that there is no such issue with either wire format if all parties
in the ecosystem are bug-free and RFC-compliant.  But with all the many
layers and implementations caching DNS, I have a low level of trust that
everyone has read and understood all applicable RFCs and is capable of
applying it all correctly in an implementation.  Thus I still stand by my
point that one wire format here is much more susceptible to potential
caching bugs than the other, and that such issues, while arguably just as
"illegal", are way more likely than receiving a spurious teapot record
(that would be a very impressive bug).


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