I know that the feedback was due last Sunday, but here comes mine
anyhow, after looking at the latest iteration of the draft.
The draft makes a number of recommendations, which seem all reasonable,
but what struck me was the weak tie between these recommendations and
the security considerations. What also strikes me is the absence of
any consideration relative to secure transports such as DoT or DoQ.
I would love to see a document that addresses the future target, in
which secure transports are use in most or all transactions between stub
and recursive, or between recursive and authoritative. I think that in
such scenarios, the threat model changes quite a bit.
In the old model, we are very concerned about third parties spoofing
responses and polluting resolver caches. In a secure transport model,
the only parties that can spoof responses are the resolvers themselves:
authoritative resolvers abusing their authority to add falsehoods in
additional sections, recursive resolvers abusing the client trust to
send false responses.
I do think that DNSSEC is still useful, even in a secure transport
world. But the focus changes. For example, if we consider that "spoofing
by recursive server" is a threat, then having the recursive set bits to
affirm that the response is verified is not much of a protection -- the
emphasis should move to verification by the client. I would love to see
this discussed.
-- Christian Huitema
On 6/7/2023 10:38 AM, Florian Obser wrote:
On 2023-06-07 13:08 -04, Tim Wicinski <[email protected]> wrote:
Just a reminder we're looking for any feedback on continuing work on this
document. The Chairs/OverLord Warren feel significant work on this
document is needed, but that may not be relevant.
The document seems to have a rather pessimistic view on running a
validator. It has this huge list of things that an operator has to do
and does not assign any importance to them - everything seems to be
equally important.
If I were to read this as the person responsible for running the
recursive resolver at an enterprise or at an ISP I'd think: That sounds
like effort and incredibly fragile, it's probably best to not enable
validation.
It would be nice to have an informational RFC on the topic, but I'm not
convinced this is it. Maybe Andrew's suggestion to split this up is the
way forward. Maybe have one document with minimum requirements (correct
time, stuff like that) and take it from there.
We're wrapping this feedback up this Sunday 11 June.
(and Thanks Andrew for your comments)
tim
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
