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

[Martin Thomson <[e-mail]>]

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
>   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.

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:
> 
>    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:
> > 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/
> > 
> > If you have any thoughts or comments, we would love to have them!
> > 
> > Dominique
> > 
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > 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: [e-mail]
> T: @nielstenoever
> P/S/WA: [phone]
> 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
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>