Hi, I have just drafted a secure transport and a security considerations section, that I believe provide sufficient guidance to a DRO. I expect to further review these sections and publish a new version very soon. As always, comments are welcome.
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-ietf-dnsop-dnssec-validator-requirements.mkd Yours, Daniel On Thu, Jun 15, 2023 at 8:00 PM Daniel Migault <mglt.i...@gmail.com> wrote: > Hi Christina, > > Thanks for the review and the suggestions. Please see my comments inline. > > Yours, > Daniel > > On Wed, Jun 14, 2023 at 11:56 AM Christian Huitema <huit...@huitema.net> > wrote: > >> 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. > > I agree that we should reconsider that section. My initial version of the > security consideration section was in my opinion too long and I > considered it as too repetitive with the main body. I then focused on the > security where the DRO is the vector of attacks/vulnerabilities. I suppose > I have been a bit too far in that direction and this is too limitative. I > will reconsider this, and your comment on the threat model gives a good > insight on what could be added. I agree that we should add some text on the > threat models current and long term. > > What also strikes me is the absence of >> any consideration relative to secure transports such as DoT or DoQ. >> > That is correct. This is something that we did not consider and probably > have to mention. I think this will be a section on its own - and not a > security consideration. > >> >> 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. >> > > I tend to think that future direction might be a bit beyond the scope of > the document, but I do tend to think that a threat model discussion can be > useful for an operator. > > 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. >> >> I agree that would become useful in giving insight into what threat the > DRO is addressing. > > >> -- 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 >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
