Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Warren Kumari <[e-mail]>]

On Fri, Oct 13, 2023 at 4:05 AM, tirumal reddy <[e-mail]> wrote:

> On Thu, 12 Oct 2023 at 21:37, Tommy Pauly <tpauly=[e-mail].
> org> wrote:
>
>>
>>
>> On Oct 11, 2023, at 3:17 PM, Warren Kumari <[e-mail]> wrote:
>>
>>
>>
>>
>>
>> On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone <
>> Gianpaolo-Angelo.Scalone=[e-mail]> wrote:
>>
>>> I really love this draft and would like to see browser side
>>> implementation for the benefit of customers user experience. Today several
>>> services are implemented on top of DNS to filter malicious or unwanted
>>> traffic in an effective way, but customers cannot distinguish the blocking
>>> from a network error. This led to frustration or even worst put them in
>>> danger: a quick solution to the "network error" is to disable the
>>> protection and so be infected, or change browser. The server side
>>> implementation provides all the needed information to build a great user
>>> experience: in the example below I see at least 2 options
>>>
>>> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987 flags: qr rd ra;
>>> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS:
>>> version: 0, flags:; udp: 512
>>> EDE: 17 (Filtered): ({ "c": [https://blocking.vodafone.com/
>>> blockpage?list=malwarecc], "s": 1,"j": "Malware C&C", "o": "Vodafone
>>> Internet Services" }) QUESTION SECTION: malw.scalone.eu. IN A
>>>
>>> Option 1 - better user experience, some complexity to avoid security
>>> risks
>>>
>>> if the contact URI is trusted it is possible to present in the GUI a
>>> real blocking page. The problem is that untrusted providers could use this
>>> method as an attack vector. Potential solutions could be:
>>> Browsers accept Exte4nded DNS Errors only from DoH servers. URI domain
>>> has to be covered by DoH server certificate. There could potentially be a
>>> vetting process e.g. through IANA, whereby filtering providers would need
>>> to register. Only registered and approved providers would then be permitted
>>> to use this method
>>>
>>> Option 2 - Sub-optimal user experience; however, a significant
>>> improvement over today's user experience.
>>>
>>> <Browser name> cannot open <filtered domain, not clickable> because it
>>> has been filtered by <name of the filtering service, "organization" field>
>>> Blocking reason: <blocking reason, " justification" field>
>>>
>>>
>>>
>> Erm, can't a large amount of this already be accomplished using RFC8914
>> Extended Errors. E.g:
>> https://www.rfc-editor.org/rfc/rfc8914.
>> html#name-extended-dns-error-code-15-
>> —-
>> "4.16. Extended DNS Error Code 15 - Blocked
>> The server is unable to respond to the request because the domain is on a
>> blocklist due to an internal security policy imposed by the operator of the
>> server resolving or forwarding the query.
>>
>> 4.17. Extended DNS Error Code 16 - Censored
>> The server is unable to respond to the request because the domain is on a
>> blocklist due to an external requirement imposed by an entity other than
>> the operator of the server resolving or forwarding the query. Note that how
>> the imposed policy is applied is irrelevant (in-band DNS filtering, court
>> order, etc.).
>>
>> 4.18. Extended DNS Error Code 17 - Filtered
>> The server is unable to respond to the request because the domain is on a
>> blocklist as requested by the client. Functionally, this amounts to "you
>> requested that we filter domains like this one."
>> ---
>>
>> Yes, it doesn't give you the HTML page, but I personally view that as a
>> feature, not a bug.
>> You *know* that if my coffee-shop/hotel/car-dealer has the ability to
>> respond to every N-th DNS query with:
>> "({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({
>> "c": [https://www.example.com/free-donut-with-every-pumpkin-spice-latte
>> .]})"
>> they will.
>>
>> Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers,
>> but with captive-portals and similar many people do…
>>
>>
>> Yeah, the existing error codes are quite good (and iOS and macOS natively
>> support them now!), but having more details would allow this to replace
>> more fully the cases where redirection occurs.
>>
>> I also am concerned about someone just putting advertisements or worse in
>> the contact information, so there should be some control on it.
>>
>
> The above attack and possible mitigation is discussed in the security
> considerations section of the draft, please see the snip below:
> </snip>
>
>    A client might choose to display the information in the "c", "j", and
>    "o" fields if and only if the encrypted resolver has sufficient
>    reputation, according to some local policy (e.g., user configuration,
>    administrative configuration, or a built-in list of respectable
>    resolvers).  This limits the ability of a malicious encrypted
>    resolver to cause harm.  For example, an end user can use the details
>    in the "c" field to contact an attacker to solve the problem of being
>    unable to reach a domain.  The attacker can mislead the end user to
>    install malware or spyware to compromise the device security posture
>    or mislead the end user to reveal personal data.  If the client
>    decides not to display all of the information in the EXTRA-TEXT
>    field, it can be logged for diagnostics purpose and the client can
>    only display the resolver hostname that blocked the domain, error
>    description for the EDE code and the suberror description for the "s"
>    field to the end-user.
>
> </snip>
>
>
> -Tiru
>
>

<no-hat>
Yes, I read that — but I still (personally) think that the risks outweigh
the benefit. Knowing that a site is unreachable because it is "Extended DNS
Error Code 17 - Filtered" seems helpful and safe. Having additional shiny
pages saying "Vodafone Internet Services has protected you from 'Malware'.
Hooray!  Click here [https://www.vodafone.com/blockpage?list=malwarecc] for
more info, and a cute upsell bundle 5G with your DNS Blocking needs"
doesn't.

Note that this is my personal view only — it's possible / likely that the
WG consensus differs from mine.
</no-hats>

W



>
>
>> Tommy
>>
>>
>> W
>>
>>
>>
>> Thank you
>>>
>>> Gianpaolo
>>>
>>> C2 General
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>