Subject: [Add] Followup from ADD session today

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Wed, 24 Jul 2019 01:38:25 +0000

As a matter of fact today I was cut on the mic and yet after me, Barry had the chance to speak and then another person had the chance to speak so it gives me the continued appearance that it is difficult to work in the IETF.

So if I would have had the chance to speak, I would have asked the question regarding David's presentation that the approach taken here seems to particularly increase the centralisation effect and I would have asked clarification questions on the UX implications on how the user would chose the right DoH server from the vetted hard coded one vs the proposed new one, etc. which UX was expected, wondering how could it be done with a good UX in a situation of a expansion of modalities (this app is using this DoH server, this browser another one, my OS another one and now I am asked to make a choice !?! are we ‘customer centric’ ?). Not saying at all it is impossible, nor whether I like it or not but what was considered.

The other aspects are, as Vasily Dolmatov said, the fact that we are implicitly accepting a default of configuration at application level for 1.1.1.1, etc. is going to have a number of consequences that we probably do not measure yet completely in particular, I backup Vasily, that it will create interesting semantic issues between domains (application level vs infrastructure level) and I share his concern about the potential implications.

Another person made the good remark that it is a change on the architecture for applications and services overall and we should pause and discuss it and Jari pointed the problem of centralization which is a real problem to me too

So my question on another alternative to what David is proposing, is why don't we try to recognise that here we have general application configuration issue and this situation reminded me the infancy 25 years ago when mail and DNS where basically the 2 only services that could be offered to customers, citizens etc. and when we were missing so many pieces and it had many side effects on what we were trying to do like how to get clients to understand their own configuration. In this vein an application access protocol was created called ACAP which is still https://tools.ietf.org/html/rfc2244. it didn't meet any big success perhaps for the similar centralisation issues as we have today but in a different context at that time

I am surely very naive here but if what we are facing here are applications that need to find their DoH server and perhaps other resources, why are we not more ambitious and why don't we reconsider a protocol that is for application configuration and thus it could be managed by service providers, would keep the alignment to infrastructure semantics, would help to distribute the deployment, could avoid centralisation and could help the architecture?

My 0.02 CHF

Sent with [ProtonMail](https://protonmail.com) Secure Email.

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 22:14:55 -0400

You touch on a point that I think is critical. All of this provides the potential for massive centralization and tracking of DNS data, on a scale much more severe than anything we have today. The internet and privacy works best when we are very decentralized. 

Imaging an app being installed on a device that allows a user to browse the web. It has a hard coded DoH server that it wants to use, that points to the DoH server of its choice.  The app can add as many other headers it wants to ensure that it can fully track that user and application, no matter where they are.  So no matter where that client is, you will always be able to have a perfect telemetry of everything they have done and when they do it. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 23, 2019, at 9:38 PM, Arnaud.Taddei.IETF <Arnaud.Taddei.IETF=[email-masked]> wrote:
> 
> So my question on another alternative to what David is proposing, is why don't we try to recognise that here we have general application configuration issue and this situation reminded me the infancy 25 years ago when mail and DNS where basically the 2 only services that could be offered to customers, citizens etc. and when we were missing so many pieces and it had many side effects on what we were trying to do like how to get clients to understand their own configuration. In this vein an application access protocol was created called ACAP which is still https://tools.ietf.org/html/rfc2244 <https://tools.ietf.org/html/rfc2244>. it didn't meet any big success perhaps for the similar centralisation issues as we have today but in a different context at that time
> 
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 24 Jul 2019 03:10:22 +0000

There was talk about this in the Jabber thread today. Ekr suggested having a drop down of server suggestions was a possibility. While I’m personally a fan of promoting DNS server choice to the user’s attention, it’s also very important to make that choice optional as users shouldn’t have to understand the question to get online.

Perhaps having the default choice be random (or geolocation driven, or any other function) per install to distribute the lion’s share of traffic which will never open DNS UI as much as possible? Apps could also defer to the platform’s DNS if we can establish a contract under which the app gains assurance the platform DNS is user/admin blessed as opposed to user/admin not-blessed configuration such as public WiFi.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Bret Jordan <[email-masked]>
Sent: Tuesday, July 23, 2019 7:14:55 PM
To: Arnaud Taddei <[email-masked]>
Cc: [email-masked] <[email-masked]>; Barry Leiba <[email-masked]>
Subject: Re: [Add] Followup from ADD session today

Thanks,
Bret

On Jul 23, 2019, at 9:38 PM, Arnaud.Taddei.IETF <Arnaud.Taddei.IETF=[email-masked]<mailto:Arnaud.Taddei.IETF=[email-masked]>> wrote:

So my question on another alternative to what David is proposing, is why don't we try to recognise that here we have general application configuration issue and this situation reminded me the infancy 25 years ago when mail and DNS where basically the 2 only services that could be offered to customers, citizens etc. and when we were missing so many pieces and it had many side effects on what we were trying to do like how to get clients to understand their own configuration. In this vein an application access protocol was created called ACAP which is still https://tools.ietf.org/html/rfc2244<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2244&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cf1c0faa5345f49a73e9808d70fdcc245%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636995313232501884&sdata=PxXwHnZ6ESclcCx%2FcwFWxXRK7pI%2FqlQVTAhx1jFSG%2Bc%3D&reserved=0>. it didn't meet any big success perhaps for the similar centralisation issues as we have today but in a different context at that time

My 0.02 CHF

Sent with ProtonMail<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cf1c0faa5345f49a73e9808d70fdcc245%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636995313232511878&sdata=X%2FXDHlV%2B5DG7Fr8%2B7BxdiIxyvJuQdDJomzpjgyBH0PQ%3D&reserved=0> Secure Email.

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Bret Jordan <[email-masked]>
Date: Tue, 23 Jul 2019 23:32:07 -0400

Yeah, or maybe we could just have a tool like DHCP give out the DNS server information for the default case to prevent any one organization from tracking everyone.  If only a tool like that existed.  (Sarcasm)

Then for anyone that wants to manually change things or hide their traffic they could run a vpn service or configure their own dns resolver on their client. (More sarcasm).  

One problem with a random DNS server, is it runs the risk of giving less than optimal routes to services. Local services may also not work in that case for most managed networks.  So schools and enterprises would have a hard time. Split dns is a thing. 

Bret 

Sent from my Commodore 128D

> On Jul 23, 2019, at 11:10 PM, Tommy Jensen <[email-masked]> wrote:
> 
>> Sent with ProtonMail Secure Email.
>> 
>> -- 
>> Add mailing list
>> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jul 2019 06:13:03 -0400

> Imaging an app being installed on a device that allows a user to browse the web. It has a hard coded DoH server that it wants to use, that points to the DoH server of its choice.  The app can add a…

Do you know of a way to detect such a client and prevent it from behaving in this way?

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Jul 2019 06:16:55 -0400

Arnaud,

> As a matter of fact today I was cut on the mic and yet after me, Barry had the chance to speak and then another person had the chance to speak so it gives me the continued appearance that it is dif…

as I started to explain when you complained to me after the session and then walked away, I had closed the lines long before you got up to queue.

Barry is the AD sponsoring the BOF. It's his show. Of course he gets to speak, he is expected to figure out what to take forward out of the BOF, and in which shape. If he wants to make a statement or ask the room a question, that's his prerogative.

Lucy got up to queue after Barry, and I asked Barry if he wanted to grant Lucy a minute after he was done. He seemed to indicate to me that he wanted to do this, which is why Lucy got to speak.

Lars

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 24 Jul 2019 14:51:19 -0400

On Jul 23, 2019, at 10:14 PM, Bret Jordan <[email-masked]> wrote:
>> Imaging an app being installed on a device that allows a user to
>> browse the web. It has a hard coded DoH server that it wants to use,
>> that points to the DoH server of its choice.  The app can add as
>> many other headers it wants to ensure that it can fully track that
>> user and application, no matter where they are.  So no matter where
>> that client is, you will always be able to have a perfect telemetry
>> of everything they have done and when they do it.  

> Do you know of a way to detect such a client and prevent it from

Additionally, how is this particular to DoH?

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Jul 2019 15:12:34 -0400

> Additionally, how is this particular to DoH?

 It is particular to DoH as opposed to DoT, in the following regards:

   - If an app was installed with a hardcoded DoT server, the unique port
   used for DoT would enable detection of the connection to the specific DoT
   server (e.g. if it were not on a white list of DoT servers), and could be
   blocked (via white-listing/black-listing methods based on IP+port).
   - If no other apps were doing DoH client stacks, the development effort
   would be greater than using an already deployed DoT proxy (assuming such a
   proxy existed and was available on the device).

The intrinsic argument is, please, let's identify the cost-value
proposition of DoT as an alternative to DoH, and seriously consider DoT
instead.

Having malware or users make local changes in choice of DoT servers, is
compatible with the detection/blocking of numerous environments, including
the enterprise use case.
Not having any apps which do DoH, means malware is, by definition, unable
to hijack those apps in order to evade that detection and blocking.

The specific use case of end-users in hostile locations, while a genuine
use case, IMHO should involve deployment of distinct versions of browsers
which do DoH, with lots of warnings to end users about the personal risks
of using them, and the ability for managed-device systems to identify those
versions (and if necessary, block their use or installation).

Brian

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Wed, 24 Jul 2019 19:23:52 +0000

Thank you for the explanation, I could not hear a lot of things and the end of the meeting was a bit confusing to me

I clearly over-reacted in a certain paranoia context and I present you my apologies

Best Regards

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday 24 July 2019 06:16, Lars Eggert <[email-masked]> wrote:

> Arnaud,
>
> On 2019-7-23, at 21:38, Arnaud.Taddei.IETF Arnaud.Taddei.IETF=[email-masked] wrote:
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Add mailing list
> [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 16:35:54 -0400

On Wed, Jul 24, 2019 at 01:38:25AM +0000,
 Arnaud.Taddei.IETF <Arnaud.Taddei.IETF=[email-masked]> wrote 
 a message of 231 lines which said:

> As a matter of fact today I was cut on the mic and yet after me,
> Barry had the chance to speak

It is always frustrating when the line close (I was still wondering if
I would intervene or not) but I feel sympathy for the BoF chairs:
there were a lot of people and not enough time.

IMHO, this should be seen as a symptom of "no clear delineation of the
BoF, no clear idea of what we were discussing". This is why there were
so many people in line and you couldn't speak.

> I would have asked clarification questions on the UX implications on
> how the user would chose the right DoH server from the vetted hard
> coded one vs the proposed new one, etc. which UX was expected

Talking of UX and UI is fine but remember we are the IETF: we are not
experts on UX and, while our input is certainly interesting, we are
not expected to standardize the user experience or interface.

> The other aspects are, as Vasily Dolmatov said, the fact that we are
> implicitly accepting a default of configuration at application level

We are accepting nothing. The IETF has no authority over the software
authors. This is a good thing, not because they are perfect and always
make good choices, but simply because we do not have the moral
authority to force them to do this or that. (We still can provide
reasonable guidance, relying on our moral authority.)

> I am surely very naive here but if what we are facing here are
> applications that need to find their DoH server and perhaps other
> resources, why are we not more ambitious and why don't we reconsider
> a protocol that is for application configuration and thus it could
> be managed by service providers, would keep the alignment to
> infrastructure semantics,

It seems to me a bad idea. If you use DoH, it's because you don't
completely trust the infrastructure. IMHO, the choice of a DoH server
should not depend on the local access network.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Jul 2019 16:46:50 -0400

On Tue, Jul 23, 2019 at 10:14:55PM -0400,
 Bret Jordan <[email-masked]> wrote 

> of everything they have done and when they do it.

Imagine an app being installed on a device that allows a user to
browse the web. It uses a lot of trackers and send a lot of data to
many actors everywhere.

You have just described the vast majority of apps that one can found
today on Google Play or App Store. (See
<https://exodus-privacy.eu.org/>.)  In what way is it a DoH issue?
Apps can send tracking data and they actually do it, and they did it
long before RFC 8484. Why was there no complaint? Why using this as an
anti-DoH argument?

---

From: Patrick McManus <[email-masked]>
Date: Wed, 24 Jul 2019 16:53:18 -0400

> should not depend on the local access network.
I mostly agree with this - trust is not a feature of the network, and you
can't generally can't even be certain what network you are using.

OTOH the locality of a resource is an interesting optimization. So if you
can discover something locally and then find an out of band way to ratchet
up your trust (e.g. a PVD based discovery shows you a resolver that turns
out to have a certificate signed by a trust anchor you trust to vet
resolvers separate from the web PKI) then maybe you've done something
useful.