Subject: Re: [Add] Requirements drafts

From: "Scalone, Gianpaolo Angelo, Vodafone Italy" <[email-masked]>
Date: Mon, 3 Aug 2020 07:58:12 +0000

Hi,
I think that Same Provider Auto Upgrade could be the best path: this guarantees that the encrypted  DNS is under the same policy that the customer already knows .
I also think that if we follow the path of potentially upgrading to a different DNS the discovery process should take into consideration (and pass during the process) also other parameters, such as GDPR compliancy,
So that in this case the customer could upgrade to GDPR compliant encrypted DNS, Edge/Core/Central DNS

Gianpaolo

[Vodafone]

Gianpaolo Scalone
Senior  Engineer
Service Applications Centre of Excellence
Group Technology, Networks
Mobile: +39 348 0001806
Email: [email-masked]<mailto:[email-masked]>
Address: Via Bisceglie 73 20147 Milano

C2 General
From: Add <[email-masked]> On Behalf Of Chris Box (BT)
Sent: 31 July 2020 19:35
To: ADD Mailing list <[email-masked]>
Subject: [Add] Requirements drafts

CYBER SECURITY WARNING: This email is from an external source - be careful of attachments and links. Please follow the Cyber Code and report suspicious emails.
All,

My take on the conclusion of this week's meeting (notes at https://codimd.ietf.org/notes-ietf-108-add?view) was that the next step should be to step back and write some new drafts that clearly define the problem statement and requirements to be met.

Assuming there is more than one of these drafts, how would you define the subject area for each one?

Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka "discovering potential upgrade information for the current resolver".

Eric also suggested "networks communicating what their preferred resolver is". If the current resolver is the one automatically learned from the network, this is identical to the above. If it is not, because there's manual configuration, presumably we always/nearly-always honor the manual config? But are there cases where it's still helpful to know the network's preference?

Within SPAU, I think a useful distinction is Ekr's "steering which generic resolver will be used". This allows for the current provider to have multiple possible resolvers (e.g. edge vs core), and communicating the nature of the differences between those options.

Finally we have Domain Designated Resolvers, where domains tell you what their preferred resolver is.

Any thoughts on the scope of each draft, and how many should be created in time for the September interim?

Chris

P.S. In terms of content, one idea I've had is that each should also mention performance considerations, particularly as I'm now thinking that the larger the set of resolvers a client talks to, the fewer requests it sends to each, and the more likely it is that a query will require a new TLS setup. Jim also mentioned another, that they'll need to report on GDPR-type issues

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 3 Aug 2020 10:43:45 +0200 (CEST)

>     Il 01/08/2020 02:05 Tommy Pauly <tpauly=[email-masked]> ha scritto:
>      
>      
>     Hi Chris,
>      
>     Thanks for starting this thread. I think focusing the interim meeting on clarifying these use cases is a good idea.
>      
>     As I mentioned in my presentation, I think there are two clear categories we see repeated across the proposals for discovery. In the most abstract terms, these are:
>      
>     1. Given a known resolver, discover one or more associated/equivalent encrypted resolvers
>     2. Discover an encrypted resolver that is applicable to a limited domain
>      
>     Each of these has several specific use cases for *both* local network resolvers and Internet-accessible resolvers.
>      
>     Under (1), we have:
>     1a: Discover encrypted resolvers that are equivalent to the resolver given out by DHCP/RA
>     1b: Discover encrypted resolvers that are equivalent to a manually-configured resolver, which may be a public Internet resolver
>     1c: Discover encrypted resolvers that are equivalent to a VPN-configured DNS servers
> 
If we develop a mechanism that starts by the IP address of a resolver (either public or private) and gets to the equivalent DoH URI / DoT IP:port address, then it will work in all those cases. There are already several proposals for that, so I think we could progress relatively easily by setting down the requirements and then evaluating the various proposals.

>     ...
>      
>     Under (2), we have:
>     2a: Discover a mapping between a locally-hosted domain and an encrypted resolver
>     - Walled-garden content
>     - Locally-cached content
>     - Private enterprise names
>     2b: Discover a mapping between a public domain and an encrypted resolver
>     - Name hosted by CDN foo can use CDN foo’s resolver
>     …
> 
This (especially 2b) looks less immediate due to the architectural change that it implies and the policy issues it creates. But it makes sense to work on a requirements doc, it will allow clarification and hopefully agreement at least on the issues.

>      
>     I don’t think we need to cover the manual configuration case, other than to indicate that user preference should always take precedence. I don’t think there is a viable use for having a network claim a preference that should override manual user configuration.
> 
Dr. Vixie would disagree :-) and there's nothing bad in letting networks communicate policy requirements to clients, since clients will always be able to ignore them - and if they won't, because the network finds technical ways to force them, then it'd be better for clients to have a way to know what's happening.

In any case, this looks like a separate working item that could fall under the third bullet of our charter, but could also be accomplished as part of a broader network handshake and provisioning mechanism. So I'd see whether anyone wants to work on that topic here and propose a requirements draft, and in that case we'll discuss whether to adopt it.

>      
>     I think these two use cases could share one document, or be separate. They probably shouldn’t be broken down any further than that.
>      
>     Beyond use cases, I think any requirements document needs to primarily address the privacy, security, and authentication requirements of the architecture. I suggest using some of the conversation from Martin Thomson’s email thread titled “My principles for discovery”. We should have baseline standards for how trusted a given signal must be before a client should use it.
> 
This smells like an endless policy discussion: "how secure is secure enough?". I would already be satisfied if we documented the security issues connected with each approach, leaving it to implementers (and possibly to policy/regulatory discussions) to determine the best tradeoff between the technical risks, the non-technical risks (e.g. consolidation) and the market and regulatory demand for a certain model.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Neil Cook <[email-masked]>
Date: Mon, 3 Aug 2020 10:50:52 +0100

> On 1 Aug 2020, at 01:05, Tommy Pauly <[email-masked]> wrote:
> 
> Hi Chris,
> 

Given all the discussion and drafts on the existing situation with forwarders, for 1a I think we also need to explicitly spell out use-cases
involving forwarders, in terms of:

i) Discovering encrypted resolvers “behind” forwarders, and using them directly (thus bypassing the forwarder).
i) Discovering and using encrypted DNS running on forwarders (note that this could involve interactions with the encrypted resolver “behind” the forwarder)

I think we should also discuss the threat models for each of these use-cases.

Neil

---

From: Eric Orth <[email-masked]>
Date: Mon, 3 Aug 2020 12:44:55 -0400

On Fri, Jul 31, 2020 at 1:35 PM Chris Box (BT) <[email-masked]>
wrote:

> All,
>
> My take on the conclusion of this week's meeting (notes at
> https://codimd.ietf.org/notes-ietf-108-add?view) was that the next step
> should be to step back and write some new drafts that clearly define the
> problem statement and requirements to be met.
>
> Martin and Eric (Orth) both suggested Same Provider Auto Upgrade, aka
> "discovering potential upgrade information for the current resolver".
>
> Eric also suggested "networks communicating what their preferred resolver
> is". If the current resolver is the one automatically learned from the
> network, this is identical to the above. If it is not, because there's
> manual configuration, presumably we always/nearly-always honor the manual
> config? But are there cases where it's still helpful to know the network's
> preference?
>

I would anticipate most clients wanting to respect manual config as much as
possible, but that still doesn't rule out potential use for communicating
network preferences.  Some possible cases I can think of:

   1. Network configuration is in use, but the network wants to request
   different providers for classic vs encrypted DNS.  Eg, maybe the network
   wants to advertise some legacy resolver for Do53 that for whatever reason
   doesn't support any upgrade discovery, but the network still wants to say
   "if you support DoH, use this other provider instead".
   2. In client configuration UIs, it may be helpful to inform the user of
   current configuration or other network preferences as the user makes
   decisions.
   3. Respecting manual config gets more nuanced as more and more parties
   do DNS and potentially have their own configuration at different levels.
   E.g., I believe the current Firefox behavior is to respect manual
   configuration in Firefox, but generally ignore OS configuration (and
   Firefox may simply not know whether that OS config is manual or automatic
   config).  Firefox or other clients with similar behavior may then want to
   know more about network preferences while ignoring the OS-configured
   classic DNS resolver.  In fact, I would say that Firefox's current use of
   the use-application-dns.net canary domain would be a non-standardized
   example of such network-preference communication, and standardizing similar
   communication seems to me to be very in-scope for this WG.
   4. Even if clients don't want to respect network preferences at all, it
   could be helpful for the client to get signals about it if the network
   starts attempting to actively enforce its preferences.  Could be helpful in
   error messaging and such.  I believe a few people have brought up this case
   in the mailing list in the past few weeks.

>
> Within SPAU, I think a useful distinction is Ekr's "steering which generic
> resolver will be used". This allows for the current provider to have
> multiple possible resolvers (e.g. edge vs core), and communicating the
> nature of the differences between those options.
>
> P.S. In terms of content, one idea I've had is that each should also
> mention performance considerations, particularly as I'm now thinking that
> the larger the set of resolvers a client talks to, the fewer requests it
> sends to each, and the more likely it is that a query will require a new
> TLS setup. Jim also mentioned another, that they'll need to report on
> GDPR-type issues
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Tue, 4 Aug 2020 18:47:03 +0100

What a good start to the thread. You've managed to turn my uncertain
grouping into something that looks a *lot* cleaner.

So perhaps we only need one requirements draft, containing use cases broken
down like this.

1. Given a known resolver, discover one or more associated/equivalent
encrypted resolvers

1a: Discover encrypted resolvers that are equivalent to the resolver given
out by DHCP/RA/PCO

1aa: Discovering encrypted resolvers behind forwarders, and using them
directly (thus bypassing the forwarder)

1ab: Discovering and using encrypted DNS running on forwarders (note that
this could involve interactions with the encrypted resolver “behind” the
forwarder)

1b: Discover encrypted resolvers that are equivalent to a
manually-configured resolver, which may be a public Internet resolver

1c: Discover encrypted resolvers that are equivalent to a VPN-configured
DNS servers

2a: Discover a mapping between a locally-hosted domain and an encrypted
resolver

- Walled-garden content

- Locally-cached content

Eric's point 1 I think can be addressed within 1a. Point 2 perhaps applies
to the whole document. Point 3 may require some ability for the discovered
information to be shared between OS and applications; we can probably
describe this in high level terms. Point 4 may need its own section that
elaborates the need for the network to communicate the enforcement that may
take place (or is taking place). I agree the capability is needed, but is
this more appropriate for ADD or CAPPORT?

Chris

On Mon, 3 Aug 2020 at 17:45, Eric Orth <[email-masked]> wrote:

> I would anticipate most clients wanting to respect manual config as much
> as possible, but that still doesn't rule out potential use for
> communicating network preferences.  Some possible cases I can think of:
>
>    2. In client configuration UIs, it may be helpful to inform the user
>    of current configuration or other network preferences as the user makes
>    decisions.
>    4. Even if clients don't want to respect network preferences at all,
>    it could be helpful for the client to get signals about it if the network
>> Within SPAU, I think a useful distinction is Ekr's "steering which
>> generic resolver will be used". This allows for the current provider to
>> have multiple possible resolvers (e.g. edge vs core), and communicating the

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 04 Aug 2020 15:23:15 -0700

"Chris Box (BT)" <[email-masked]> writes:

> What a good start to the thread. You've managed to turn my uncertain grouping into
> something that looks a *lot* cleaner.

> 
> So perhaps we only need one requirements draft, containing use cases broken down
> like this.

I suspect there is another case that most want to explicitly not pursue:

Given a network, discover whether its use is acceptable according to the
its operators, the ISP you're connecting under, and laws within the region.
Functionally, use-application-dns.net is a mechanism for detecting ISP
policy, eg.

-- 
Wes Hardaker
USC/ISI

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 05 Aug 2020 13:36:57 +1000

Hi Chris,

I think that this is a helpful simplification.  I have a question on the first arm of your taxonomy below.  This is probably just tactical, but it would be good to clarify.

On Wed, Aug 5, 2020, at 03:47, Chris Box (BT) wrote:
> So perhaps we only need one requirements draft, containing use cases 
> broken down like this.
> 

Do we necessarily have to have knowledge of a resolver before starting down this path?  I say that because 1a ultimately involves the network saying something about the resolver and you could do this one of two ways:

i) The network says "here is a resolver" and then you define a mechanism to go from that information - which is probably just an IP address - to encrypted resolver coordinates.

ii) The network says "here are the coordinates for a resolver that supports DoE".

I can see how you might want the former if your view is that you want to provide an upgrade path where the resolver is configured via unspecified means (your 1b or 1c), but I don't think that is the dominant case.  We heard that >90% of people don't touch defaults, so it seems to me that there are two avenues for investigation, which conveniently correspond to your 1aa/1ab distinction:

α) enhance the mechanisms that people use to discover a resolver (DHCP, RA, PPP, whatever)

β) find a way to talk to the resolver and get its opinion

You can imagine that a client with no opinion might do α then β.  In those deployments that include a forwarder as part of a gateway/router this offers that device an opportunity to offer its opinion if it has been updated.  Absent that upgrade, there will be no DoE information presented, so clients might then try asking the resolver (using resolver-info.arpa and SVCB or whatever happens to be fashionable when we eventually decide).

A client with an opinion about a resolver, but no information about DoE might just do β.

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 5 Aug 2020 18:38:43 +0100

Wes,

I'm not especially in favour of pursuing "discover whether using a resolver
X is acceptable".

I think it would be better to let the client try. If it succeeds, great. If
not (because the network is denying it), we should allow the network to
explain why it is not succeeding. This is simply a usability improvement.

Chris

On Tue, 4 Aug 2020 at 23:23, Wes Hardaker <[email-masked]> wrote:

> broken down

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 5 Aug 2020 18:41:47 +0100

Martin,

Interesting points. Credit for the taxonomy should go to Tommy Pauly, with
revisions by Neil.

I agree that it is unnecessary to bake in an assumption that
DHCP/RA/PPP/PCO must always return an IP address of a resolver before the
process of 1a can be started. We could instead enhance DHCP/RA/PPP to
return some richer set of data, such as the inclusion of an Explicit PvD in
RA described by draft-pauly-add-resolver-discovery. Note that PCO (Protocol
Configuration Options) is a 3GPP spec and so this working group cannot
*directly* alter that.

Could we generalise the requirement by using this wording, or similar?

1. Given information from the attached networks, and resolvers known from
configuration, discover one or more associated/equivalent encrypted
resolvers

1a: Discover encrypted resolvers that are equivalent to the resolver given
out by DHCP/RA/PPP/PCO, regardless of whether this is a classic IP address
or a richer set of information.

I think this allows for 1aa and 1ab, and α and β. In my view β will always
be needed as long as there are edge devices that only support issuing a
Do53 IP address.

Chris

On Wed, 5 Aug 2020 at 04:37, Martin Thomson <[email-masked]> wrote:

> Hi Chris,
>
> I think that this is a helpful simplification.  I have a question on the
> first arm of your taxonomy below.  This is probably just tactical, but it
> would be good to clarify.
>
> Do we necessarily have to have knowledge of a resolver before starting
> down this path?  I say that because 1a ultimately involves the network
> saying something about the resolver and you could do this one of two ways:
>
> i) The network says "here is a resolver" and then you define a mechanism
> to go from that information - which is probably just an IP address - to
> encrypted resolver coordinates.
>
> I can see how you might want the former if your view is that you want to
> provide an upgrade path where the resolver is configured via unspecified
> means (your 1b or 1c), but I don't think that is the dominant case.  We
> heard that >90% of people don't touch defaults, so it seems to me that
> there are two avenues for investigation, which conveniently correspond to
> your 1aa/1ab distinction:
>
> You can imagine that a client with no opinion might do α then β.  In those
> deployments that include a forwarder as part of a gateway/router this
> offers that device an opportunity to offer its opinion if it has been
> updated.  Absent that upgrade, there will be no DoE information presented,
> so clients might then try asking the resolver (using resolver-info.arpa and
> SVCB or whatever happens to be fashionable when we eventually decide).
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Aug 2020 18:31:16 +0000

> I'm not especially in favour of pursuing "discover whether using a resolver

i differ, and am in favour of that model.

> explain why it is not succeeding. This is simply a usability improvement.

there are two problems with this.

first, some technologies (DoH for example) are intended to be unblockable. if 
the only signal of non-compliance with policy is going to be failure, then 
that signal will be unreliable.

second, policy violations are actionable aberrations for many networks. if the 
operator of a privately owned edge network has to treat as urgent every use of 
non-approved accesses such as off-network RDNS use, that's too expensive.

therefore i want a cooperating device to be able to learn the local network's 
policies, in case that device wants to comply with those policies.

-- 
Paul

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 5 Aug 2020 18:43:30 +0000

Thanks for bringing this up Paul, as I did go to the secdispatch list as recommended during our 108 meeting chat. Their responses included "might deserve its own area" and "try reusing mechanisms like 802.11x" and a research proposal and a recommendation of the IRTF instead of the IETF. Each response is an example of how the problem is not specific to DNS.

The takeaway being: I still believe the problem of networks communicating policy securely to devices is beyond this WG's scope. This isn't a feature parity issue with classic DNS, as there's no such network to client communication pre-DoH/DoT either. Networks have been able to recommend DNS servers but could not indicate those servers were the only permissible servers to use.

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Paul Vixie <[email-masked]>
Sent: Wednesday, August 5, 2020 11:31 AM
To: ADD Mailing list <[email-masked]>
Cc: Chris Box (BT) <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Requirements drafts

--
Paul

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cf31f49cfb76b429a91e708d8396dc641%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637322490943879659&amp;sdata=3zpsQYbTPjgpq5PhzYnuz42LMCKJfmtc4g35T71vQ8o%3D&amp;reserved=0

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Aug 2020 18:55:58 +0000

On Wednesday, 5 August 2020 18:43:30 UTC Tommy Jensen wrote:
> Thanks for bringing this up Paul, as I did go to the secdispatch list as
> recommended during our 108 meeting chat. Their responses included "might
> deserve its own area" and "try reusing mechanisms like 802.11x" and a
> research proposal and a recommendation of the IRTF instead of the IETF.
> Each response is an example of how the problem is not specific to DNS.

i recommend greater care than what you heard. in the old (usenet) days, a 
common form of dismissal was "please move this discussion to a newsgroup i 
don't subscribe to". for something like dns autoconf, now that the consensus 
is that DHCP is not secure enough to be able to introduce such a vital 
service, we cannot afford to accidentally imply such dismissal, or 
accidentally heed it, or proceed in the absence of trustworthy policy guidance 
because it's off topic or will come too late. 

> The takeaway being: I still believe the problem of networks communicating
> policy securely to devices is beyond this WG's scope. This isn't a feature
> parity issue with classic DNS, as there's no such network to client
> communication pre-DoH/DoT either. Networks have been able to recommend DNS
> servers but could not indicate those servers were the only permissible
> servers to use.

if we could proceed on the basis that no such method is needed, then we would 
not have consensed that DHCP is inadequate for end-node DNS configuration. as 
i've expressed, i think an authentic DNS autoconfiguration method for end 
nodes could become the basis by which private-namespace DNS requests could be 
made to learn other policies. i don't mean that all of that is in-scope, but i 
do mean that if we build a foundation which could reasonably be used that way, 
it probably will be used that way.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2020 15:44:05 -0400

> policies, in case that device wants to comply with those policies.

Forgetting for a moment about whether we can do it here, in principle, how would you feel about a trust establishment ritual for managed devices, which would then allow such devices to securely discover that the network has a restrictive resolver policy? And devices that hadn’t established trust would not trust such a policy announcement (and possibly not discover it).

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Aug 2020 22:07:50 +0000

On Wednesday, 5 August 2020 19:44:05 UTC Ted Lemon wrote:
> > therefore i want a cooperating device to be able to learn the local
> > network's policies, in case that device wants to comply with those
> > policies.
> Forgetting for a moment about whether we can do it here, in principle, how
> would you feel about a trust establishment ritual for managed devices,
> which would then allow such devices to securely discover that the network
> has a restrictive resolver policy? And devices that hadn’t established
> trust would not trust such a policy announcement (and possibly not discover
> it).

i think that may be cutting it too fine. if we're going to keep using ARP to 
find MAC addresses, and we're going to keep using DHCP to find gateways, and 
we're not going to tell everybody to use a single host per broadcast domain in 
order to protect ARP and DHCP... then we can depend on policy information from 
the local broadcast domain to tell us what the network policy is.

i wouldn't mind if bringing up a new device required pairing, like bluetooth, 
with a shared secret (like "1111" in most cases), but i don't see how to make 
that work for IoT which usually has no keyboard and hardly ever has a display. 
to me that makes solutions along this axis of rotation largely undeployable.

in other words our implicit threat model is either off-path attackers or on-
path attackers outside our local network. we should make that explicit, and 
then go where that leads us.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2020 19:06:59 -0400

> the local broadcast domain to tell us what the network policy is.

That trust model works fine when you have a desktop machine chained to a fixed location with a trusted network. As soon as you have portable devices, they can plug into networks that definitely cannot be trusted to tell the truth. E.g., why would $GIANT_COFFEE_SHOP_CHAIN not just tell me to turn off privacy because they can monetize my queries? We’ve seen Verizon do exactly this with supercookies—this is not supposition. If I can’t say “trust Paul’s network config information and don’t trust $GCSC’s,” then I can’t really use that information safely.

I know you could argue that I just shouldn’t use $GCSC’s network if I don’t want them turning off my privacy, but it’s a decision that my machine has to make without consulting me, and even if it did consult me I’d have no way to validate the assertion that I was connecting to $GCSC’s network.  So there’s no my phone can tell that it’s actually connecting to $GCSC’s network and not some imposter network. The only way it can tell if it’s connecting to your network is if there’s a trust establishment process and a way to authenticate the assertion of trustworthiness.

Importantly, this is mostly already a solved problem. It’s not a trivial problem, but when I go to work, my phone knows I’m connected to the work network and doesn’t set up the VPN. If my work wanted to insist that I use their resolver, that’s an option in the VPN profile, which would be active both when connected to the VPN and when connected to the actual work network.  This is much more secure than what you’re asking for, because I get the same protection whether I’m at work or at home or at $GCSC. Also, very importantly, there is no way in the world that my employer would allow $GCSC to insist on using their resolver, if they had a policy like yours. They don’t, because my phone is assumed to be hard enough to crack that resolver filtering is going to do more harm than good, but in principle they could insist on resolver filtering wherever I connect, regardless of local policy, because they have a VPN.

> to me that makes solutions along this axis of rotation largely undeployable.

Well, for example, the way it’s done for HomeKit is with a QR code on the packaging, and a camera on the commissioning device (the phone).  Making this work for Wi-FI without using BLE as a bridge is harder, but work is being done in that area.  I think that ANIMA has something that does that.

> then go where that leads us.

The threat model I care about is on-path attackers. Off-path attacks are addressed by a variety of mitigations, from DNSSEC to DoT to DoH.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 5 Aug 2020 18:44:45 -0700

On Wed, Aug 5, 2020 at 4:07 PM Ted Lemon <[email-masked]> wrote:

>
> Importantly, this is mostly already a solved problem. It’s not a trivial
> problem, but when I go to work, my phone knows I’m connected to the work
> network and doesn’t set up the VPN.
>

Yes. My Android phone connects to Google's VPN at all times <
https://support.google.com/fi/answer/9040000?hl=en>. I'm sure there are
similar features on many other devices.

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 6 Aug 2020 11:40:50 +0200 (CEST)

>     Il 06/08/2020 01:06 Ted Lemon <[email-masked]> ha scritto:
>      
>     I know you could argue that I just shouldn’t use $GCSC’s network if I don’t want them turning off my privacy, but it’s a decision that my machine has to make without consulting me,
> 
Honestly, I think that the decision whether to trust some entity or not is so complex, so personal, so depending on personal preferences, locations and case, so based on typically human factors like sympathy and prejudice, that it is not possible to build any human-centric system based on an assumption that machines make trust decisions in place of their human users.

It is definitely possible to have machines support users in making those choices, for example through reputation systems, choice delegation systems ("I trust Mozilla so I want Mozilla to make these choices for me"), easy ways to give general directions ("never trust any network run by a cafe"), but I think we need a UX/policy architecture focused on empowering humans, and then we need to build the technical tools that make its implementation possible.

If we do not do that, we end up with the risk of some giant device/software maker pushing all users to only "trust" their own / their partners' networks, and never connect to commercially rival networks - and become the gatekeeper to Internet access.

Incidentally, in the bucket of things that clients should be able to discover from a network in secure ways (wherever work will happen on it), let's put also the basic piece of information of which network it is (i.e., recognize if it's the same network that I already connected to in the past, via some form of reliable unique identifier other than a self-advertised SSID) and who owns it. We managed to authenticate websites, could we do the same with networks?

--

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Aug 2020 10:17:34 -0400

> Honestly, I think that the decision whether to trust some entity or not is so complex, so personal, so depending on personal preferences, locations and case, so based on typically human factors lik…

It’s really important when talking about protocol development to differentiate between the meaning of technical terms that are being used and the natural language meaning of the same term. Trust has a lot of meanings in english (and in other languages, I am sure). One of them is the meaning that you are using here: the process by which we decide whether or not to trust some entity, which has aspects of emotion, aspects of logic, and so on. This is an important meaning of the word trust, and it’s relevant here, but it’s not what I was talking about.

The type of trust you are explaining here is how I decide whether to trust /Paul/.  It is how I decide whether to trust /$GCSC/. It is how I decide that I’m okay with my employer’s VPN. This is an important part of the equation. But this is not what the term “establish trust” is referring to.

Trust establishment is something that is done /after/ you decide /who/ to trust. Suppose I trust Paul. Okay, so I’m willing to use Paul’s resolver. Trust establishment is how I /know/ that I am using Paul’s resolver. This is what I was talking about here.

If I can’t /know/ that it’s Paul’s resolver I’m talking to, it doesn’t matter whether I trust Paul or not. I still can’t trust the resolver, because it’s just some random resolver. I have no way of knowing that it’s Paul’s resolver.

The other worries you mention in your message are all real worries, but they are tangential to the trust establishment process.  And they are really hard to solve in the IETF. If we are concerned that Firefox might misrepresent what they do so that we trust them when we shouldn’t, or don’t realize that we are trusting them, this is something that can really only be dealt with on the political level: it has to be illegal or immoral for Firefox to do that, and there has to be some way for us to tell that they are doing it. Happily, there are ways to do this. Firefox is open source, for one thing, so we can just look at the code. In the case of closed-source products, one of the ways we figure out whether to trust is based on the legal assertions that are made in the vendor’s privacy policy, and our understanding of the risk that they undertake if they lie to us. And of course we also rely on security researchers and market researchers to notice that they are living up to their promises, or not.

Again, these are all extremely important parts of the trust ecosystem, and we as citizens should support government policies that have good outcomes here, but the IETF can’t really be a part of that. All the IETF can do is figure out (for example) how, technically, a browser that is behaving in the interests of its users can securely establish trust with a resolver that the user has decided to trust.

---

From: "Chris Box (BT)" <[email-masked]>
Date: Thu, 6 Aug 2020 18:04:15 +0100

Ted said:
Making this work for Wi-FI without using BLE as a bridge is harder, but
work is being done in that area.  I think that ANIMA has something that
does that

Ted, were you thinking of BRSKI?
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-42
>From a quick look it does appear to be a "trust establishment" procedure.

While I'm here I'll post the current iteration of the proposed requirements
structure, in case anyone wants to make further comments on that.

resolvers.

1aa: Discovering encrypted resolvers behind forwarders, and using them
directly (thus bypassing the forwarder).

forwarder).

1b: Discover encrypted resolvers that are equivalent to a
manually-configured resolver, which may be a public Internet resolver.

DNS servers.

2. Discover an encrypted resolver that is applicable to a limited domain.

resolver.

- Walled-garden content

- Locally-cached content

2b: Discover a mapping between a public domain and an encrypted resolver.

Chris

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Aug 2020 13:12:01 -0400

On Aug 6, 2020, at 1:04 PM, Chris Box (BT) <[email-masked]> wrote:
> Ted, were you thinking of BRSKI? https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-42 <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-42> 

Yes.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Aug 2020 07:34:00 +0000

On Wednesday, 5 August 2020 23:06:59 UTC Ted Lemon wrote:
> > i think that may be cutting it too fine. if we're going to keep using ARP
> > to find MAC addresses, and we're going to keep using DHCP to find
> > gateways, and we're not going to tell everybody to use a single host per
> > broadcast domain in order to protect ARP and DHCP... then we can depend
> > on policy information from the local broadcast domain to tell us what the
> > network policy is.
> 
> That trust model works fine when you have a desktop machine chained to a
> fixed location with a trusted network. As soon as you have portable
> devices, they can plug into networks that definitely cannot be trusted to
> tell the truth. E.g., why would $GIANT_COFFEE_SHOP_CHAIN not just tell me
> to turn off privacy because they can monetize my queries? ...

you have ignored what i've said, and changed the subject, and attacked a straw 
man. i beg you to end that pattern of behaviour. the topic under discussion 

> network's policies, in case that device wants to comply with those

this has nothing to do with truth or trust. i believe that the same entity who 
tells me what my gateway is, and who controls the population who can see and 
answer DHCP and ARP requests and perhaps forge answers to them, can tell me 
their RDNS policy.

separately from that i will decide whether i believe it, or agree with it. 
but, if i proceed in abberance to that policy, i'll know that i might be 
considered an attacker, and defended against. that is all this is about.

please do not argue against anything i have not said. it's very distracting.

-- 
Paul

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 7 Aug 2020 13:27:15 +0000

> From: Paul Vixie
> Sent: Friday, August 07, 2020 2:34 AM
> To: Ted Lemon <[email-masked]>
> Cc: ADD Mailing list <[email-masked]>
> Subject: Re: [Add] Requirements drafts
> 

I'd been working on a lengthy reply to Ted that said something similar (though suggesting that perhaps he didn't seem to quite understand the point being made rather than an intentional misinterpretation -- because Ted is a very nice and rational person and it's so darned easy not to read emailed words correctly).

FWIW, I think Paul and I are on the same page with what we'd like to see. This isn't about mandating any sort of client behavior in response to a network saying the network has a policy to require use of DNS servers it advertises. The network has to assume there are clients that will ignore the policy statement; therefore, mandating client behavior is futile. But if there is a well-known means for the network to express this, then people/coders who *want* to can write code or configure devices that react to such a policy statement in a way that makes sense for them. I also believe that all coffee shops should have the right to set policies for use of their networks. If I don't like the policy, I can choose not to use the network or only use it for limited purposes where I don't care about privacy (e.g., searching for nearby tourist attractions). BTW, my employer has a strict policy against using coffee shop networks (or bringing/using company devices in certain foreign countries) -- even though the company devices require a VPN to do just about anything. I truly doubt that being able to use DoH or securely discover DNS server info in the coffee shop or foreign country would change this company policy.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Aug 2020 11:07:31 -0400

> man. i beg you to end that pattern of behaviour. the topic under discussion 

I could ask you the same.  Imagine that we are in a room on the second floor of a building, and there are some apples in the room that are taking up space. To free up space, you propose that we put the apples outside the window. I object that if you put the apples outside the window, they will fall and be bruised, and thus rendered useless. And you say “stop putting words in my mouth—I never said that the apples should fall—I just said to put them out the window.”

This is what this conversation feels like from my perspective.

When you establish a way for the network to say “if you want to use the network, you must disable the security that is presently enabled on your device,” you create an attack surface. You are saying “don’t worry, I’m not talking about creating an attack surface—I just want to be able to tell the user they’ve been blocked because their device’s security stance is not permitted here.”  This is like saying that if you put the apples out the window, they won’t fall: you’re denying that there is a connection between saying “you’re not winning because you are using a secure and private DNS protocol” and the user disabling their secure and private DNS protocol so that they can win.

Now, it may be that you believe that this doesn’t create an attack surface, and so we don’t have to do anything to address that. You may even be right. But the reason we keep going around on this is that it’s dead obvious to me that you are creating an attack surface, and so I naturally start thinking about how to mitigate it so that you can get what you want, and I can not put an attack surface in my devices. I’m engaging with you because I want to help you get what you say you want, not because I’m unreasonably trying to thwart you.

Making me out to be unreasonable and a villain when I do this is not cool.  If I’m wrong, convince me I’m wrong. Don’t tell me to shut up.

---

From: Eric Orth <[email-masked]>
Date: Fri, 7 Aug 2020 11:39:31 -0400

Mechanisms to communicate information do not create attack surfaces.
Clients trusting and changing behavior based on communicated information
has the potential to create attack surfaces.  How much clients trust info
or how they change their behavior is policy and out-of-scope for this WG.
Therefore, as long as a critical mass of client implementors can think of
reasons to want mechanisms for the network to communicate preferences, it
would be completely appropriate to produce relevant RFCs, as long as
security considerations give strong reminders of the potential dangers of
untrusted use.

More specifically, we've seen some proposals for adding DNS-specific
information such as DoH URLs to already-existing mechanisms such as DHCP,
and I think such proposals are a good idea.  Alternately, if people prefer
a wider-scoped new mechanism for communicating network preferences/policy
beyond just DNS, I believe it has already been suggested that such work may
be a good idea, but is out of scope for this WG.

On Fri, Aug 7, 2020 at 11:07 AM Ted Lemon <[email-masked]> wrote:

> I could ask you the same.  Imagine that we are in a room on the second
> floor of a building, and there are some apples in the room that are taking
> up space. To free up space, you propose that we put the apples outside the
> window. I object that if you put the apples outside the window, they will
> fall and be bruised, and thus rendered useless. And you say “stop putting
> words in my mouth—I never said that the apples should fall—I just said to
> put them out the window.”
>
> When you establish a way for the network to say “if you want to use the
> network, you must disable the security that is presently enabled on your
> device,” you create an attack surface. You are saying “don’t worry, I’m not
> talking about creating an attack surface—I just want to be able to tell the
> user they’ve been blocked because their device’s security stance is not
> permitted here.”  This is like saying that if you put the apples out the
> window, they won’t fall: you’re denying that there is a connection between
> saying “you’re not winning because you are using a secure and private DNS
> protocol” and the user disabling their secure and private DNS protocol so
> that they can win.
>
> Now, it may be that you believe that this doesn’t create an attack
> surface, and so we don’t have to do anything to address that. You may even
> be right. But the reason we keep going around on this is that it’s dead
> obvious to me that you are creating an attack surface, and so I naturally
> start thinking about how to mitigate it so that you can get what you want,
> and I can not put an attack surface in my devices. I’m engaging with you
> because I want to help you get what you say you want, not because I’m
> unreasonably trying to thwart you.
>
> Making me out to be unreasonable and a villain when I do this is not
> cool.  If I’m wrong, convince me I’m wrong. Don’t tell me to shut up.
>
> --
> Add mailing list
> [email-masked]

---

From: "Chris Box (BT)" <[email-masked]>
Date: Fri, 7 Aug 2020 17:06:09 +0100

On Fri, 7 Aug 2020 at 14:27, STARK, BARBARA H <[email-masked]> wrote:

> This isn't about mandating any sort of client behavior in response to a
> network saying the network has a policy to require use of DNS servers it
> advertises. The network has to assume there are clients that will ignore
> the policy statement; therefore, mandating client behavior is futile. But
> if there is a well-known means for the network to express this, then
> people/coders who *want* to can write code or configure devices that react
> to such a policy statement in a way that makes sense for them.

Earlier in the thread I said that it wasn't necessary for a network to
communicate policy in advance, only to provide a way to deliver the reasons
for a block, after it has occurred. But the above, together with Paul's,
has convinced me that such a thing would be useful.

Clearly there are large risks if clients automatically acquiesce to
whatever the unknown network says. Ted's right to point that out. But I can
envisage cases where it would be sensible.

Also +1 to what Eric said.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Aug 2020 12:48:06 -0400

> Mechanisms to communicate information do not create attack surfaces.

That’s pretty much the way we create attack surfaces. The belief that it is not has a long history of causing very expensive security failures.

An analogous case is the certificate alert bypass in web browsers. There’s nothing wrong with using self-signed certs. But if you ask the user to decide whether to trust one, you have an attack surface that’s easy to exploit, because users will tend to say yes.

As a consequence of this, what has begun to happen is that browsers have stopped even presenting a dialog when they get a cert they can’t validate with PKI. They do not offer users the option of bypassing the warning. To bypass the warning, the user has to actually already know how to bypass it. And indeed they don’t necessarily even get an explanation of why the connection has failed. The less information they get, the harder it is to trick them into bypassing the self-signed cert.

What we’re proposing here is to create an analogous attack surface. It seems like a good idea, because you’re informing the user as to why they are losing. But it creates a way to trick the user into acting against their interests.

What you’ve said is that this isn’t a problem, because the attack surface only exists if the implementation displays the information to the user. But the whole point of providing the mechanism is to make it possible to communicate useful information to the user.

What I’ve said, to which Paul is objecting, is that the mechanism should include a way of establishing and verifying trust, so that the user is presented with information that they’ve decided to trust only after they make the decision to trust it. This means that when the network tells you “no,” it’s okay for you to act on that.

BTW, this is totally orthogonal to the question of offering a DoH server in DHCP. If there is no pre-configured DoH server, this would be useful and make sense, and isn’t a particular security risk. If it were supposed to override the user’s pre-configured DoH server, that would be a problem, but I don’t expect that anybody would implement that.

---

From: Eric Orth <[email-masked]>
Date: Fri, 7 Aug 2020 14:06:40 -0400

On Fri, Aug 7, 2020 at 12:48 PM Ted Lemon <[email-masked]> wrote:

> BTW, this is totally orthogonal to the question of offering a DoH server
> in DHCP. If there is no pre-configured DoH server, this would be useful and
> make sense, and isn’t a particular security risk. If it were supposed to
> override the user’s pre-configured DoH server, that would be a problem, but
> I don’t expect that anybody would implement that.
>

I do not understand your point of how DHCP is fundamentally different from
other mechanisms of communicating network preferences/policy.  Why would
clients/users be trusted to use info responsibly only if it comes from
DHCP? Or is your point that just offering a specific DoH resolver is fine,
but more specific policy such as "you must use this resolver" would be
problematic?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Aug 2020 14:10:47 -0400

On Aug 7, 2020, at 2:06 PM, Eric Orth <[email-masked]> wrote:
> I do not understand your point of how DHCP is fundamentally different from other mechanisms of communicating network preferences/policy.  Why would clients/users be trusted to use info responsibly only if it comes from DHCP? Or is your point that just offering a specific DoH resolver is fine, but more specific policy such as "you must use this resolver" would be problematic?

What I believe Paul is asking for is a way to inform the user that DoH is not permitted on this network.  What DHCP does is to provide the address of a DoH server that is available on this network.

A DNS resolver that is not configured with a DoH server ought to prefer the local DoH server to the local Do53 server. So informing it of the availability of this service makes sense.  A DNS resolver that is configured with a DoH server ought not to replace that DoH server with one advertised by DHCP, because that would be an obvious way to violate the user’s privacy. So if we were to specify such an option, I would expect the applicability statement to say this clearly. And if it didn’t, an implementation that I did would still ignore the DHCP option if there was already an explicit DoH server configured. It’s hard to imagine an implementor of this DHCP option popping up a dialog to ask the user what to do when there is a conflict.

But the express purpose of the error message is to inform the user, so an implementation necessarily has to pop up a dialog, or in some other way inform the user.  That is how the two things are different.

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 7 Aug 2020 18:38:30 +0000

I think of this difference Ted is highlighting as "network recommendation" versus "network requirement". The former has existed for classic DNS in DHCP for a long time, and the latter as of yet does not exist for DNS servers.

I agree with Ted: offering network recommendations of DoH servers make perfect sense. It brings DoH use up to parity with classic DNS use. Offering network requirements for DoH I consider to be beyond WG scope as it is a subset of the network requirements problem which is unsolved for clients with no prior knowledge of the network.

To be clear: I think the problem of secure communication of network requirements is worth solving. However, it should get the scope and attention it deserves to get it right as opposed to an awkward blocker to DoH deployment.

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Sent: Friday, August 7, 2020 11:10 AM
To: Eric Orth <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Paul Vixie <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Requirements drafts

On Aug 7, 2020, at 2:06 PM, Eric Orth <[email-masked]<mailto:[email-masked]>> wrote:
I do not understand your point of how DHCP is fundamentally different from other mechanisms of communicating network preferences/policy.  Why would clients/users be trusted to use info responsibly only if it comes from DHCP? Or is your point that just offering a specific DoH resolver is fine, but more specific policy such as "you must use this resolver" would be problematic?

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Aug 2020 11:47:34 -0700

On Fri, Aug 7, 2020 at 11:38 AM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> I think of this difference Ted is highlighting as "network recommendation"
> versus "network requirement". The former has existed for classic DNS in
> DHCP for a long time, and the latter as of yet does not exist for DNS
> servers.
>

You mean "DoH servers" at the end I think, and I agree that advertising a
DoH or DoT server is not a regression. It's not clear how some of these
resolvers are going to provide a certificate. Maybe we'll see more PSK
traffic on LANs.

>
> I agree with Ted: offering network recommendations of DoH servers make
> perfect sense. It brings DoH use up to parity with classic DNS use.
> Offering network requirements for DoH I consider to be beyond WG scope as
> it is a subset of the network requirements problem which is unsolved for
> clients with no prior knowledge of the network.
>

Sorry for the "+1" message, but +1.

thanks,
Rob

---

From: Eric Orth <[email-masked]>
Date: Fri, 7 Aug 2020 15:50:13 -0400

I do not believe there is any practical distinction between "network
recommendations" and "network requirements" unless the client chooses to
follow the requirements or the network chooses to attempt to enforce its
requirements.  Maybe good for the network to specify that it considers
something to be a requirement and I especially like the idea of networks
specifying whether or not they will attempt to enforce requirements.  Any
mandates of clients following "requirements" are obviously out-of-scope for
the WG and unenforceable by IETF, but I don't think anybody has seriously
suggested doing that.  Any mandates of networks not attempting to enforce
requirements are similarly out of scope, and much as I would prefer they
didn't, I assume some networks will.

Some scenarios I can think of where general-purpose clients may want to use
those network-provided signals:

   - If the client detects that DoH does not work and may be being blocked
   by the network, the client may want to check for a "DoH is disallowed on
   this network and we will attempt to enforce that" signal or maybe an "only
   DoH provider X is allowed on this network" signal.  That can allow the
   client to provide better error messages, informing the user of what is
   going on.
   - If the user is taking action to manually change configuration (e.g.
   using a client settings UI), some clients may find it reasonable at that
   time to inform the user of the network-provided recommendations or
   "requirements".  Maybe even more powerful if combined with test queries to
   determine if non-recommended configurations are functional.

There was a comment above about clients responding to network preference
signals by popping up a dialog to the user about it.  Sounds like a
problematic UX that I don't see any general-purpose client implementing,
but if some client wants to, out of scope for the WG to say that they can't.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Aug 2020 20:11:23 -0700

On Fri, Aug 7, 2020 at 12:50 PM Eric Orth <[email-masked]> wrote:

> recommendations" and "network requirements"
>

I agree with this sentiment. As long as there are no MUST/SHALL/REQUIRED
rules on clients, it seems like agreeing on things for the network to send
could be productive.

thanks,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Aug 2020 20:47:34 -0400

> I'm not especially in favour of pursuing "discover whether using a resolver

A case that I was thinking about is when on trains/aircraft.
You *CAN* use some external resolver, but the performance will be awful.
How/do we let the network explain this?

And, the situation may change after authenticating to the network and/or
upgrading to the better data plan.

    > explain why it is not succeeding. This is simply a usability improvement.

The above is distinct from the case where national infrastructure blocks the
access, and here we need to let the network explain.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Aug 2020 06:48:26 -0700

> You *CAN* use some external resolver, but the performance will be awful.

Is this in fact true? Back when I used to fly, I used to use DoH quite a
bit as well as
using browsers that were not configured with DoH and I never really noticed
a material
difference.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Aug 2020 10:50:55 -0400

On Aug 10, 2020, at 9:48 AM, Eric Rescorla <[email-masked]> wrote:
> Is this in fact true? Back when I used to fly, I used to use DoH quite a bit as well as
> using browsers that were not configured with DoH and I never really noticed a material
> difference.

Unlikely to be true. What’s true is that high latency and packet loss cause problems for TCP connections on airplanes, and packet loss causes DNS failures, but when you have packet loss the DNS answer doesn’t matter, and probably isn’t in cache anyway. I definitely have noticed DNS failures in flight, but they are always when the network fundamentally isn’t working. A DNS cache on the airplane will probably lower latency for some oft-visited sites, but only a bit. If you have a cache in your laptop, it will get you nearly all of the benefit that using the caching resolver on the airplane infrastructure would give you.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2020 16:56:16 -0400

> a material difference.

My experiences have been on pooly provisioned trains, where the bufferbloat
meant that DNS requests took many seconds.

Yes Ted, *I* can run a local, caching, recursive DNSSEC resolver. I do.
But my phone doesn't.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 10 Aug 2020 14:41:16 -0700

> using browsers that were not configured with DoH and I never really

The only issue I've noticed with DoH or VPN on planes are CAPPORT
issues--meaning the initial WiFi sign-in might not work. Besides that, I
haven't noticed anything other than DoH or VPNs occasionally being better
than using the airline DNS server...

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Aug 2020 14:42:02 -0700

> meant that DNS requests took many seconds.

Doesn't this have a similarly negative effect on the content you actually
want to retrieve which presumably goes over TCP?

-Ekr

---

From: Steffen Nurpmeso <[email-masked]>
Date: Tue, 11 Aug 2020 00:32:41 +0200

Rob Sayre wrote in
 <[email-masked]>:
 |On Mon, Aug 10, 2020 at 6:49 AM Eric Rescorla <[email-masked]> wrote:
 |> On Sun, Aug 9, 2020 at 5:47 PM Michael Richardson <[email-masked]>
 |> wrote:
 |>> Chris Box (BT) <[email-masked]> wrote:
 |>>> I'm not especially in favour of pursuing "discover whether using a
 |>> resolver
 |>>> X is acceptable".
 |>>
 |>> A case that I was thinking about is when on trains/aircraft.
 |>> You *CAN* use some external resolver, but the performance will be awful.
 |>
 |> Is this in fact true? Back when I used to fly, I used to use DoH quite a
 |> bit as well as
 |> using browsers that were not configured with DoH and I never really
 |> noticed a material
 |> difference.
 |
 |The only issue I've noticed with DoH or VPN on planes are CAPPORT
 |issues--meaning the initial WiFi sign-in might not work. Besides that, I
 |haven't noticed anything other than DoH or VPNs occasionally being better
 |than using the airline DNS server...
 |
 |thanks,

Quite off-topic, but i did not fly in thirty-three years.  By then
airplanes were dirty ressource hogs.  (Luckily the new load of
Musk satellites addressed that terrible glowing from the solar
panels i think it is, it was so depressing to see that line of
artificial stuff that here in Germany and even Europe noone needs
in a ~30 second interval, right after they have been started.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2020 20:49:41 -0400

> want to retrieve which presumably goes over TCP?

It depends upon what you are trying to do.
Bufferbloat'ed networks do good jobs of delivering large web blobs, and video.
They are terrible for interactive use.

A feature of offsite DoH/DoT would be that the networks would more visibly
suck for all users, and those can get fixed, might get fixed.

Those that can't be fixed, because of existing terrestial/satellite limits
would probably benefit from as much local DNS caching as possible.

One certainly can't do interactive ssh from many trains.

(Thalys is among the worst I've seen, and many others have agreed, but
Canada's VIA Rail system is a close second)

But, I don't have to wait for IMAP/POP3 or SMTP, it happens in the background, so
it's okay if it takes many seconds per command.
And IMAP supports multiple commands, but I personally tend not to use it that way.
Once the data starts flowing, things are okay.  git pushes/pulls are a toss-up.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [