Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session

[Eric Rescorla <[e-mail]>]

On Tue, Mar 22, 2022 at 2:24 AM Kathleen Moriarty <
[e-mail]> wrote:

> Mark,
>
> Sent from my mobile device
>
> > On Mar 21, 2022, at 10:17 PM, Mark Nottingham <[e-mail]> wrote:
> >
> > I'm not going to be at SECDISPATCH, so I'll make my comments here.
> >
> > First, a general comment. Andrew, you seem to be forming a habit of
> relying on 8890 to get air time for your arguments. That RFC's focus is on
> encouraging the IETF community to consider the impacts of its actions
> elsewhere. The only place it privileges those already active here is when
> it talks about civil society organisations' ability to act as a channel for
> engaging the broader Internet community. I don't believe you're acting in
> that capacity here.
> >
> > I.e., your arguments should stand on their own -- invoking 8890 doesn't
> reinforce them.
> >
> > Now, regarding the draft -- draft-campling-ech-deployment-considerations
> seems to assume that the *only* viable way to scan for viruses, impose
> parental controls, or control access to resources is by having a network
> element impose it without coordination. Your draft supports this by noting
> that transparent proxies are used because they're easier to administer than
> on-endpoint software -- a viewpoint which privileges administrator
> convenience and cost over user safety,  and ignores other options.
>
> No hat -
>
> Are there more options than Safe Browsing and endpoint solutions? There
> are DNS based solutions, but if DoH forces you to go to a dedicated DNS
> server you don’t get that filtering. It’s more helpful if the alternative
> options are spelled out as well as how solutions are used. Closing a
> security gap before other solutions are viable or in place will only
> exacerbate the very real problems faced by organizations and their users
> experiencing attacks including random ware.
>

I think it's a mistake to locate the incompatibility with DNS-based
filtering in DoH. Rather, it's a question of resolver selection.

Specifically, the case of interest is the one where the client uses a
different DNS server (DoH, DoT, or otherwise) than that proposed by the
network. And that disagreement happens when the network does not have
practical control over the client (because otherwise it can force the
client to use its preferred server). IOW, I don't think the question is the
technical means by which said filtering happens, but whether the network
can unilaterally impose filtering on the client.

-Ekr