Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson