Hi, Please find the new version that addresses Christina comments. It includes a secure transport section and the security considerations section has been consolidated by adding a trust model section. As always, comments are welcome!
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-validator-requirements-06 Yours, Daniel On Thu, Jun 22, 2023 at 4:27 PM Daniel Migault <mglt.i...@gmail.com> wrote: > 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 > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
