[dns-operations] DNS-over-TLS in public resolvers

[Phillip Hallam-Baker]

On Tue, Mar 7, 2017 at 8:28 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr>
wrote:

> On Tue, Mar 07, 2017 at 02:12:06PM +0100,
>  Ralf Weber <dns at fl1ger.de> wrote
>  a message of 28 lines which said:
>
> > increase that cost a lot for no benefit for them
>
> The IETF has many stakeholders, not just the ISP. For instance, the
> users...
>
> > (I assume they can protect their networks from illegal spying).
>
> I assume they actively participate to some forms of surveillance.
>

​That is actually a showstopper concern for deployment of some protocols by
some parties. I don't think it affects DPRIV but it very definitely does
affect some TLS deployments.

Right now, one of the biggest drivers behind the push for deployment of TLS
everywhere is to prevent ISPs deploying ad blockers and anti-malware
blockers. I don't think those should be in conflict but I know that any
proposal I make that is designed to enable users to keep their ad and
malware blockers is going to have to be able to deploy without help from
those stakeholders.

If you want a protocol to be deployed, you have to consider the interests
of the stakeholders you need to act whether or not they are at the table.

If those stakeholders have technical constraints, then you have to design
the protocol to meet them.

If the proposal is going to seriously damage the commercial interests of
the stakeholders then you are going to have to work out some way to coerce
them (government regulation takes ten years in the US/EU) or redesign the
protocol so that you don't need them at all.

It is all part of engineering a solution, just like checking for patent
encumbrance, meeting performance requirements, etc. The designer of a
toaster oven isn't rated on the performance of the product, they are rated
on what it costs to produce. That is called design for manufacturing. If
IETF wants to be influential, it has to start designing for deployment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170307/0516a5c8/attachment.html>