same here, I'm late, but I support this draft and will review and contribute.
CLASSIFICATION:CONFIDENTIAL ________________________________ From: DNSOP <dnsop-boun...@ietf.org> on behalf of Christian Huitema <huit...@huitema.net> Sent: Wednesday, June 14, 2023 11:55 AM To: Florian Obser <florian+i...@narrans.de>; Tim Wicinski <tjw.i...@gmail.com> Cc: dnsop <dnsop@ietf.org>; dnsop-chairs <dnsop-cha...@ietf.org> Subject: [EXT] Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements 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 <tjw.i...@gmail.com> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
