Subject: [arch-d] <draft-lazanski-consolidation-00>

From: Dominique Lazanski <[email-masked]>
Date: Mon, 9 Nov 2020 17:09:19 +0000

Hey Mark and I have a draft on consolidation. 

Protocol and Engineering Effects of Consolidation can be found here: https://datatracker.ietf.org/doc/draft-lazanski-consolidation/ <https://datatracker.ietf.org/doc/draft-lazanski-consolidation/>

If you have any thoughts or comments, we would love to have them!

Dominique

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 9 Nov 2020 20:42:02 +0100

Hi Dominique,

Thanks for this well documented work! I hope you don't mind if I ask some questions. I am a bit confused by this argument:

   The QUIC protocol is an example of the consolidation between layers
   of the Internet - and not at the application layer. Designed and
   deployed as a transport layer protocol, it effectively replaces TCP
   at the network layer while also adding improved security. The result
   is the merging or consolidation of three layers. QUIC should improve
   efficiency and delivery of applications, but also forces all data to
   be managed at the endpoint, which in this case is a browser, making
   it more difficult to manage traffic at the network layer.

The web browser is not one entity, right? So how does QUIC lead to consolidation?

Further down you argue that:

However,
   there was little multistakeholder consultation and discussion prior
   to the adoption of DoH. This was more of a rapid development and
   deployment process, without the market driving the use cases and
   uptake.

Does this mean that you think that the IETF process in general is flawed or only in this case? Because I don't think this process have deviated from the standard IETF process.

You also argue that:

   The market should be a regulating factor in consolidation.

I am curious what you base this on, because almost no contemporary economic theory argues this. Would be nice to add some sources.

For the purposes of this draft we view it from the
   perspective of the underlying architecture of the public Internet.

What do you mean with 'the public Internet' here? Is that different from 'the Internet'? Or would you argue that global dependency bring about other responsibilities for the Internet architecture and hence the term 'public'? More discussion here would be welcome too. 

This will
   create not a network of networks, but a mesh. 

This differentiation could also benefit from some elaboration imho.

The 'Actions for the IETF', largely seem actions for IRTF (1 and 4) and the IAB. Point 4 would be an interesting point of discussion for hrpc!

Thanks again for this work, curious to see where it goes, and thanks for keeping this discussion going.

Best,

Niels

On 11/9/20 6:09 PM, Dominique Lazanski wrote:
> Protocol and Engineering Effects of Consolidation can be found here: https://datatracker.ietf.org/doc/draft-lazanski-consolidation/
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Postdoctoral Research Fellow - Communications Department - Texas A&M University
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my disseration 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Nov 2020 12:43:43 +1100

Hi Dominique,

In addition to Dr. Niels' excellent questions and observations, I think that you might want to think about the effects that attacks on these protocols might have.

I agree that there are consolidation effects exhibited by some of the examples.  Privacy Pass continues to bother me in this regard, for example, but that doesn't necessarily render it irredeemable; it might just be that the deployment models considered don't work in all cases.

However, I think that it pays to understand the dynamics involved in the standardization of these protocols better.

For the QUIC example (which is not dominated in the implied fashion by Google and Mozilla (who also don't make Safari)), I would prefer to say that the effect is the opposite of what this draft claims.  That is, technology that was previously available only to Google and Facebook is now available to others.  There are many implementations, many of them good, and many of them accessible to more than just a few.  This function of standardization remains a valuable defense against accretion of proprietary technologies that provide larger actors with greater advantage.

The draft doesn't suggest any particular course of action in response for these protocols (QUIC, TLS, DoH) in response to the implication that they drive consolidation.  If I were to infer that refusal to standardize is an option, I posit that that would have a severe deleterious effect on the playing field.  It wouldn't remove the desire to deploy such mechanisms, but it would affect the availability of technology to smaller players.

That isn't to say that QUIC isn't without its shortcomings when it comes to power and resource disparities.  The deployment complexities involved mean that - for the foreseeable future at least - small players are still significantly disadvantaged.  But that would be considerably worse had the IETF not been involved at all.

Separately, I find this reassuring:

>  [...] QUIC should improve

This was a headline goal of QUIC and I'm glad you agree that we've achieved it.

The document claims that DoH deployment was forced.  The claim is that this was not market forces at work.  I have to reject that thesis entirely.  While I agree with the author of RFC 8890 that the development of RFC 8484 had some issues (some of which were novel, all of which are worth learning from), the progress toward deployment seems to me to be unremarkable.  It's a deployment with a disruptive technical innovation that has a displacement effect on some incumbents, for sure, which are never painless, but it's not like Microsoft or Apple or Google or Comcast or any of the other actors who have responded are responding to force.  They are responding to market pressures.

This is FUD, and I'm disappointed to see it repeated here:

>   By routing the DNS over HTTPS, it becomes much easier to track user
>   activity through the use of cookies.  Therefore a protocol that was
>   developed to enhance user privacy and security could actually
>   undermine both: privacy through the use of cookies and security by
>   consolidating DNS traffic onto far fewer resolver operators that are
>   far more attractive targets for malicious actors of various types.

Yes, cookies are terrible.  Which is why no DoH implementation I'm aware of pays any attention to them.  That's a simplification, but the suggestion that client implementations don't take all reasonable steps to manage privacy risks and the trade-offs involved demonstrates a lack of understanding.

Cheers,
Martin

p.s., your drafting tool seems to have produced some weird errors.

On Tue, Nov 10, 2020, at 06:42, Niels ten Oever wrote:
> Hi Dominique,
> 
> Thanks for this well documented work! I hope you don't mind if I ask 
> some questions. I am a bit confused by this argument:
> 
> Does this mean that you think that the IETF process in general is 
> flawed or only in this case? Because I don't think this process have 
> deviated from the standard IETF process.
> 
> You also argue that:
> 
> I am curious what you base this on, because almost no contemporary 
> economic theory argues this. Would be nice to add some sources.
> 
> What do you mean with 'the public Internet' here? Is that different 
> from 'the Internet'? Or would you argue that global dependency bring 
> about other responsibilities for the Internet architecture and hence 
> the term 'public'? More discussion here would be welcome too. 
> 
> This will
> The 'Actions for the IETF', largely seem actions for IRTF (1 and 4) and 
> the IAB. Point 4 would be an interesting point of discussion for hrpc!
> 
> 
> Read my disseration 'Wired Norms' here: 
> https://pure.uva.nl/ws/files/50781961/Thesis.pdf
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 11 Nov 2020 12:37:32 +0000

Hi Martin,

> -----Original Message-----
> From: Architecture-discuss <[email-masked]> On
> Behalf Of Martin Thomson
> Sent: 10 November 2020 01:44
> To: [email-masked]
> Subject: Re: [arch-d] <draft-lazanski-consolidation-00>
> 
> Hi Dominique,
> 
> In addition to Dr. Niels' excellent questions and observations, I think
> that you might want to think about the effects that attacks on these
> protocols might have.
> 
> I agree that there are consolidation effects exhibited by some of the
> examples.  Privacy Pass continues to bother me in this regard, for
> example, but that doesn't necessarily render it irredeemable; it might
> just be that the deployment models considered don't work in all cases.
> 
> However, I think that it pays to understand the dynamics involved in the
> standardization of these protocols better.
> 
> For the QUIC example (which is not dominated in the implied fashion by
> Google and Mozilla (who also don't make Safari)), I would prefer to say
> that the effect is the opposite of what this draft claims.  That is,
> technology that was previously available only to Google and Facebook is
> now available to others.  There are many implementations, many of them
> good, and many of them accessible to more than just a few.  This function
> of standardization remains a valuable defense against accretion of
> proprietary technologies that provide larger actors with greater
> advantage.
> 
> The draft doesn't suggest any particular course of action in response for
> these protocols (QUIC, TLS, DoH) in response to the implication that they
> drive consolidation.  If I were to infer that refusal to standardize is an
> option, I posit that that would have a severe deleterious effect on the
> playing field.  It wouldn't remove the desire to deploy such mechanisms,
> but it would affect the availability of technology to smaller players.
> 
> That isn't to say that QUIC isn't without its shortcomings when it comes
> to power and resource disparities.  The deployment complexities involved
> mean that - for the foreseeable future at least - small players are still
> significantly disadvantaged.  But that would be considerably worse had the
> IETF not been involved at all.
> 
[RW] 

I would like to check that I am reading and understanding your comment correctly.

Are you really intending to say that a headline goal of QUIC is to make it more difficult to manage traffic at the network layer, and by implication make it more difficult for ISPs to manage networks?

I'm not that familiar with QUIC yet, but I had assumed that the goal was to increase user privacy and reduce the leakage of private information that is available at the network layer, and that making it harder to manage traffic at the network layer was an unfortunate side effect of that increase of privacy rather than as an explicit goal.

I am more concerned about the loss of privacy that seems to be occurring at the application layer via extensive tracking of users and sharing of user information, rather than my perception of what is now occurring at the network layer.

Regards,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 11 Nov 2020 14:14:57 +0100 (CET)

> Il 10/11/2020 02:43 Martin Thomson <[email-masked]> ha scritto:
> 

+1 to this. In fact, the (non-technical) problems do not come from having standardized a protocol, but from having failed to gather and address the non-technical requirements of all stakeholders before finalizing and deploying the standard.
 
> The document claims that DoH deployment was forced.  The claim is that this was not market forces at work.  I have to reject that thesis entirely.  While I agree with the author of RFC 8890 that th…

The problem, however, is that consolidation *is* the effect of market pressures.  The global regulatory discussion around Internet platforms is indeed a discussion about rules that could prevent these market pressures from reaching a short-term optimal point which is damaging to the market itself in the long term, and that endangers fundamental rights and public policy needs.

> Yes, cookies are terrible.  Which is why no DoH implementation I'm aware of pays any attention to them.  That's a simplification, but the suggestion that client implementations don't take all reaso…

However, when you design a protocol, you should also take into consideration how it could be misused.  If you design a protocol that gives an additional possibility for user tracking to a sector of the Internet industry that in many cases has user tracking and profiling as its main source of revenues, then there will be a natural business incentive for these companies to activate the tracking sooner or later.  Of course you can rely on a pledge that they will never do so, but still, you created a new risk by design.

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Nov 2020 05:25:28 -0800

On Wed, Nov 11, 2020 at 4:37 AM Rob Wilton (rwilton) <rwilton=
[email-masked]> wrote:

I am more concerned about the loss of privacy that seems to be occurring at
> the application layer via extensive tracking of users and sharing of user
> information, rather than my perception of what is now occurring at the
> network layer.
>

The goals of reducing tracking at the application layer and at the network
layer are complementary, rather than in tension. And in fact, there is
extensive work happening on reducing application layer tracking (see, for
instance, Intelligent Tracking Protection [Safari] and Enhanced Tracking
Protection [Firefox]).

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 12 Nov 2020 11:37:57 +1100

> Are you really intending to say that a headline goal of QUIC is to make 
> it more difficult to manage traffic at the network layer, and by 
> implication make it more difficult for ISPs to manage networks?

No, I should have been more careful there.  There were a couple of goals relevant to this.  One was to reduce information exposure and improve privacy with respect to on-path attackers.  The other was to limit active interference by an on-path attacker.

The net effect is that ISPs are less able to manage the details of other people's interactions.  But there are affordances in the protocol that should allow ISPs (and other network operators) to continue to manage their networks effectively.  Of course, it's still a matter of debate how much information or control network operators need from endpoints, but at least QUIC provides end users (or at least end systems) greater ability to decide what happens.
 
> I am more concerned about the loss of privacy that seems to be 
> occurring at the application layer via extensive tracking of users and 
> sharing of user information, rather than my perception of what is now 
> occurring at the network layer.

A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Nov 2020 19:29:09 -0800

> The net effect is that ISPs are less able to manage the details of other people's interactions.  But there are affordances in the protocol that should allow ISPs (and other network operators) to co…

This is not a new debate. The MARNEW workshop was very much dedicated to
this topic: how does encryption affect network management. See the
report in RFC 8462. Another reference directly related to this subject
is RFC 8404, Effects of Pervasive Encryption on Operators. We learned
something from MARNEW and from the review process of RFC 8404: "network
management" is defined very loosely. When an operator say that they
"need to manage the network", it covers a spectrum of things from "being
able to debug an error condition" to "being able to extract additional
revenues from the network". It is easier to get IETF consensus on some
parts of that spectrum than on others.

Encryption does not preclude network slices, priorities and other forms
of QoS. Applications can absolutely be programmed to explicitly use a
QoS API and request a specific form of network service. What encryption
precludes is differentiated treatment of various applications without
explicit agreement between network and endpoint. We could have a debate
over the consequences, but this is a very different issue than
concentration.

> A totally legitimate concern, but that line of argumentation sounds like whataboutism. Improvements in privacy with respect to the network do not drive privacy violations at the application layer.

What Martin says. The draft is supposedly about consolidation. There is
definitely a relation between concentration and privacy: if traffic gets
consolidated on a small number of big platforms, the owners of these
platforms see a lot of data and metadata, which affects privacy. But the
relation between that and end-to-end encryption is tenuous. For example,
Google was getting just as many cookies before web pages started being
sent over HTTPS. The differences is that before encryption other actors
were also able to read these cookies. That was hardly a better privacy
posture.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Nov 2020 20:00:09 -0800

A specific point on the statement in the draft that "Both Christian
Huitema and Julien Maisonneuve noted concentration, which leads to
consolidation, as an effect of economies of scale and network effects in
business models in the implementation of business practices."  There are
lots of possible interpretations behind that statement, including the
classic "natural monopoly" defense of, well, monopolies. It is very
clear that both effects exist, but also that investors who explicitly
seek to achieve monopoly do not rely on those two effects alone, and
that standards have a role to play.

The network effect is in full swing with social networks. Indeed, most
of the upstarts social networks do fail rapidly, because they fail to
achieve a critical mass of users. There is a long list there, including
very well funded initiatives like Google+. The economies of scale
effects are also very visible in e-mail services. Effective e-mail
service requires big investments to manage spam. In practice, just two
providers concentrate a huge part of mail service: Google's GMail and
Microsoft's Outlook. Dismissing these effects would be very misleading.
Scale also brings knowledge, be it technical knowledge of the
application domain or the soft knowledge that comes from observing the
behaviors of a large and diverse user base. The products of less 
knowledgeable competitors will often be perceived as inferior. Network
effects and scale provide advantages to providers who achieve them, and
contribute to "naturally" maintaining dominant positions.

On the other hand, dominant positions bring lots of advantages to
whoever achieves them. In the old industries, dominant positions
translated into pricing power. For "free" services, dominant positions
translate into gigantic accumulation of data on users, monetized through
advertisements. In any case, dominant positions are known to bring big
financial rewards. Investors will push entrepreneurs to achieve them
with a variety of strategies including selling services at a loss or
encouraging competitors to merge.

I will stop there, but I have grown sensitive to the "natural monopoly"
arguments, and I wanted to clarify my position.

-- Christian Huitema

On 11/9/2020 9:09 AM, Dominique Lazanski wrote:
> Protocol and Engineering Effects of Consolidation can be found
> here: https://datatracker.ietf.org/doc/draft-lazanski-consolidation/
>

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 12 Nov 2020 15:46:23 +0100 (CET)

>     Il 12/11/2020 04:29 Christian Huitema <[email-masked]> ha scritto:
> 
> 
> 

>     What Martin says. The draft is supposedly about consolidation. There is definitely a relation between concentration and privacy: if traffic gets consolidated on a small number of big platforms, the owners of these platforms see a lot of data and metadata, which affects privacy. But the relation between that and end-to-end encryption is tenuous. For example, Google was getting just as many cookies before web pages started being sent over HTTPS. The differences is that before encryption other actors were also able to read these cookies. That was hardly a better privacy posture.
> 
I note one big risk to privacy that is generated by the introduction of end-to-end encryption, together with the IoT and cloudification trends: end-users - not just network administrators - lose the ability to scrutinize what their applications and devices actually send to their makers, or - in case of self-masquerading technologies like DoH - even to detect that a communication is happening and to block it if they want so. There was a talk about this at the IETF 105 plenary:
https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-lessons-from-privacy-measurement-arvind-narayanan-00

Indeed, one of the side effects of DoH for some (more technical) users is to disrupt their Pi-holes and other DNS-based tracker blockers.

Consolidation underpins all of this, as in the "surveillance capitalism" business model whoever has more opportunities to acquire information wins.

--

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Nov 2020 08:11:50 -0800

On 11/12/2020 6:46 AM, Vittorio Bertola wrote:
>> What Martin says. The draft is supposedly about consolidation. There
>> is definitely a relation between concentration and privacy: if
>> traffic gets consolidated on a small number of big platforms, the
>> owners of these platforms see a lot of data and metadata, which
>> affects privacy. But the relation between that and end-to-end
>> encryption is tenuous. For example, Google was getting just as many
>> cookies before web pages started being sent over HTTPS. The
>> differences is that before encryption other actors were also able to
>> read these cookies. That was hardly a better privacy posture.
>>
> I note one big risk to privacy that is generated by the introduction
> of end-to-end encryption, together with the IoT and cloudification
> trends: end-users - not just network administrators - lose the ability
> to scrutinize what their applications and devices actually send to
> their makers, or - in case of self-masquerading technologies like DoH
> - even to detect that a communication is happening and to block it if
> they want so. There was a talk about this at the IETF 105 plenary:

Device inspection is an interesting issue, but it is far to being as
clear-cut as you present it.

Take the example of a doorbell camera. It sends motion activated video
streams to a cloud server, from which they can be accessed by the home
owners using their cell phone. If the traffic was in the clear,
inspection would reveal exactly that: motion activated video streams to
a cloud server. It will not reveal whether the cloud servers provide a
copy of the video streams to the police. It will not tell whether the
servers perform face recognition on the incoming images, and use that
for tracking the movement of people walking nearby. Encryption will
prevent that inspection, but it will also prevent third parties from
tapping into the video stream and performing their own parasitic
surveillance. From a privacy point of view, encryption there is a net
gain -- but the presence of the devices themselves may well be a huge loss.

The inspection performed by researchers revealed that some devices where
performing extra tasks, not described in the public specification of the
device. Maybe a child's toy also sending data about the children to its
manufacturer. Inspection by researchers has revealed such shenanigans in
the past, and the inspection was typically done by breaking the device
encryption using spoofed server certificates. Should we then recommend
that all devices should accept spoofed server certificates? That would
be opening the gates to a free-for-all of hacking and banditry. It would
also not solve the "cloud connection" problem shown with the doorbell
cameras.

The device problem is real, but the solution certainly is not to make
the devices easy to break by third parties. Instead I would rather see
consumer bureaus stepping in and providing "clean device" certification
labels, after inspecting devices and services in which the protections
have been lifted by the manufacturer. Or, law enforcement could step in
and severely punish device manufacturers engaged in deceptive practices,
either on the device or in the cloud servers.

>
> Indeed, one of the side effects of DoH for some (more technical) users

> is to disrupt their Pi-holes and other DNS-based tracker blockers.
>
> Consolidation underpins all of this, as in the "surveillance
> capitalism" business model whoever has more opportunities to acquire
> information wins.

There is definitely a relation between surveillance capitalism and
consolidation, but you don't need to discuss the encryption of
communication to make that point.

-- Christian Huitema

> [email-masked] <mailto:[email-masked]>