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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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 <[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
>


-- 
Daniel Migault
Ericsson