On 06. 07. 26 21:51, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-structured-dns-error-24: Discuss
As a dnsdir reviewer reponsible for parts of the this ambiguity I feel
obliged to respond:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Questions around the use of clear-text DNS and EXTRA-TEXT:
-- Section 5.3
1. If the integrity of the DNS response is not guaranteed, the DNS
client MUST NOT act upon data in the EXTRA-TEXT field, as the
data is vulnerable to modification by an on-path attacker.
What provides an adequate guarantee of integrity to act upon the data?
DNS has number of integrity protection mechanism: TLS, TSIG, SIG(0), to
name few. Do you envision mandatory subset?
> What> happens if the stub resolver uses DOH, but the recursive
resolver does not?
EDNS is hop-by-hop so EDE option is always generated by 'first hop'.
What happens upstream of the first hop is irrelevant because EDE options
would not be passed verbatim to the end client.
-- Section 10.1, “This specification assumes the use of authenticated,
integrity-protected DNS transports (e.g., DoT, DoH, or DoQ). Such transports
MUST be based on TLS 1.3 [RFC8446] or later.” This seems ambiguous. Is
“assuming the use of” the same thing as requiring the using of “authenticated,
integrity-protected DNS transports” when the EXTRA-TEXT field is use? If so,
please be explicit. I ask because a few sections later (Section 10.4 note
below) the text is unambiguous on the need for “encrypted DNS transport”.
-- (not DISCUSS feedback, here for reference) Section 10.4, “This specification
requires the use of an encrypted DNS transport (e.g., DoT, DoH, or DoQ), which
protects both the DNS query and the structured error response from passive
observers.” This is unambiguous. Thanks.
I agree 'assumes the use of' might be weird and a MUST is in order here.
Having said that, the same argument about protocol agility as above
applies. This document should not mandate one specific integrity
protection when there's multiple standardized options for DNS.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
