Subject: [arch-d] Is consolidation a protocol property?

From: Watson Ladd <[email-masked]>
Date: Thu, 29 Jul 2021 20:11:04 -0700

Dear all,

After a rather contentious BoF on Oblivious HTTP, where there was
quite a bit of discussion of consolidation, I think the conversation
needs to be revived.   Personally I'm skeptical this is a meaningful
thing to talk about for an early stage protocol, and distracts from
more technical issues. How a protocol is deployed is mostly  fairly
independent from its technical details and changes over time. SMTP
didn't change to make Gmail possible.

Given that this has also happened at other BOFs, I think it makes
sense to figure out if consolidation is really an appropriate thing to
throw around in the first case at protocols, or if its about the sort
of deployment issues we don't really look at.

Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 30 Jul 2021 17:10:28 -0700

Hi Watson,

I think I’d agree with the direction you’re going in here, that consolidation/centralization is not a property of a protocol itself. Arguably for any unicast protocol, the identity of the other side of communication may be some entity that is considered “centralized” or not.

I am sympathetic to the fact that consolidation is an interesting question when taken in the right context, but I would argue that it is a matter of *deployment* models, not protocols themselves. There can of course be protocol elements that are required to make certain deployment models possible, but there are many instances where deployment models do not require standardized protocols.

My impression from the OHTTP BoF was that a lot of the discussion about consolidation really belonged in some other venue, like in DINRG or an OPS area discussion of how privacy-preserving protocols are deployed in practice.

Best,
Tommy

> On Jul 29, 2021, at 8:11 PM, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 31 Jul 2021 02:32:39 +0200

Is it fair to say that the purpose of privacy against spoofing
in the "Internet" segment will become better and better
the more web-pages are "hidden" behind the server side proxy ?

Aka: if a proxy just has one server behind it, ohttp doesn't
buy much, right ?

Of course, one could say that there could also be multiple
server side proxies offering access to the same server, like
in a federated set of "competing" server side proxies,
but there is no mechanism to explicitly support this. I
think this falls into the traumatic "discovery" topic,
so in the absence of such components, the protocol can only
support solutions that get better the more server a single operators
server-side proxies support.

Hope this is roughly stating the high level issue correctly.

Cheers
    Toerless

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 31 Jul 2021 10:56:46 +1000

I generally agree with what Tommy has said here, though I will note that the question can be important to the design of a protocol.  Privacy Pass have had this problem wherein aspects of the design might have limited the number of actors that can provide certain key functions in the system.  I think we have a reasonable solution there that doesn't result in any inherent bias toward having a limited set of actors, but it is existence proof of the issue.

FWIW, any PKI would be another great example of inherent centralization bias.

I tend to think that, like anything else in this space, awareness of the potential problem and discussion of its effects on designs is OK.  There is probably no single thing that can be said on the topic that applies in all cases, except what has already been said:

   We embrace technical concepts such as
   decentralized control, edge-user empowerment and sharing of
   resources, because those concepts resonate with the core values of
   the IETF community.  

-- RFC 3935, Section 4.1

There is, of course, value in exploring specific cases in more detail and trying to extract common lessons.  I haven't seen any truly compelling work in that space yet.  It's hard.  People are still finding their way.

The risk here is that this turns into "we don't like specific entity X because they have too much power", which is not about the technology any more.  At that point, we're well outside our domain of expertise.

On Sat, Jul 31, 2021, at 10:10, Tommy Pauly wrote:
> Hi Watson,
> 
> I think I’d agree with the direction you’re going in here, that 
> consolidation/centralization is not a property of a protocol itself. 
> Arguably for any unicast protocol, the identity of the other side of 
> communication may be some entity that is considered “centralized” or 
> not.
> 
> I am sympathetic to the fact that consolidation is an interesting 
> question when taken in the right context, but I would argue that it is 
> a matter of *deployment* models, not protocols themselves. There can of 
> course be protocol elements that are required to make certain 
> deployment models possible, but there are many instances where 
> deployment models do not require standardized protocols.
> 
> My impression from the OHTTP BoF was that a lot of the discussion about 
> consolidation really belonged in some other venue, like in DINRG or an 
> OPS area discussion of how privacy-preserving protocols are deployed in 
> practice.
> 
> Best,
> Tommy
>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 31 Jul 2021 03:33:41 +0200

Martin,

fully agree that decentralization and distribution is 
often more difficult than centralization. Traffic
Engineering is another example, although PKI is
also the worst offender i can think of, but we are doing
work in this as well, at least in where i work (ANIMA).

> The risk here is that this turns into "we don't like specific entity X because they have too much power", which is not about the technology any more.  At that point, we're well outside our domain o…

Few use-case requirements are about technoloy
per-see. That has nothing to do with the fact that
our work would be about the technical work on 
technologies to solve those requirements.

Whether someone asks me to build decentralized
solutions to avoid fostering even more business monopolization is
as good a requirement for me as mission survivability in battlefield
scenarios is when the DoD is asking for distributed routing
solutions, or resilient PKI infrastructures.

The sad difference is that the military pays
for their use-case requirements, OTT businesses pay for
standardization of protection against underlay interaction
to save their business, but nobody seems to be willing to pay for
avoidance of web-scale business monopolization to foster a more
player competitive, resilient and broader innovative web-infratructure
economy.

Ultimately, it is left up to the IETF community to make this a goal.
A community which is nowadays very much dominated by those
against whose interests such a goal would be. Which showed clearly
in this weeks meeting.

So, yes, i do not see any hope that IETF will do better on this front
than what is proposed by ohttp, but lets at least be honest about
the commercial reasons of shaping the proposal in a particular form.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jul 2021 18:56:26 -0700

> against whose interests such a goal would be. Which showed clearly

It would be great if we could keep this conversation on a technical level,
as indicated by S 2 of RFC 7154 and especially point 2.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Fri, 30 Jul 2021 20:46:57 -0700

> Aka: if a proxy just has one server behind it, ohttp doesn't

Size matters for pretty much all designs that involve "hiding in a 
crowd", or rather hiding behind a relay. The number of clients using the 
relay has to be large enough to hide the relation between incoming and 
outgoing traffic; the number of servers accessed by the relay has to be 
large enough to hide the relation between incoming requests and outgoing 
ones. So there is a benefit to being big.

It does not follow that relays should be centralized. Indeed, if just 
one company is providing relays, the anonymity set would be large enough 
to protect clients against outsiders, but clients would be fully exposed 
to the centralized company. It merely implies that each relay should 
serve a big enough population.

We then have to be concerned about business models. Competition will 
only be sustainable if relays can get enough revenues to sustain the 
service -- otherwise we end up with services operated as cost centers by 
large companies, for various motives. That probably implies allowing 
some form of authentication to reserve the services to authorized 
customers. But that authentication or authorization scheme shall not 
reveal the client's identity, which in turns requires something like 
Privacy Pass. (Of course, services like Privacy Pass rely on their own 
infrastructure and have their own risks of centralization...)

None of that is specific to oblivious HTTP. The same would apply to 
oblivious DNS, public VPNs, Onion routers, etc.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Sat, 31 Jul 2021 11:46:46 +0200

Tommy

I won't respond fully at the moment, but I think it's good to take 
another example.  We have a service that enrolls devices onto networks 
with X.509 certificates, in which the RA has identity values for the 
device that the device doesn't have.  There are two choices: feed the 
values to the device or feed them to the CA. The diversity of clients 
and complexity of the former leads us to the latter, for which there is 
no standard.  Rather different CAs have their own APIs.  That LACK of 
standardization leads to per-CA code, and THAT has a consolidating effect.

The deployment of DoH absent discovery will have a concentrating effect 
that will lead to risk of large scale failures, since the goal is to an 
enumerated list of services from a broader set of resolvers.  Why?  We 
see those large scale failures in other such services.  That is because 
those services are developed and managed by human beings.  Diversity of 
services isn't the only risk.  A monoculture of implementations can also 
cause that risk, as we have also previously seen with sendmail.

Eliot

On 31.07.21 02:10, Tommy Pauly wrote:
> communication may be some entity that is considered “centralized” or not.
>
> a matter of *deployment* models, not protocols themselves. There can 
> of course be protocol elements that are required to make certain 
> My impression from the OHTTP BoF was that a lot of the discussion 
> about consolidation really belonged in some other venue, like in DINRG 
> or an OPS area discussion of how privacy-preserving protocols are 
> deployed in practice.
>
> Best,
> Tommy
>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 31 Jul 2021 10:11:34 -0700

> Aka: if a proxy just has one server behind it, ohttp doesn't

It buys a fairly important property which is that the user cannot be
linked across interactions by the server and the client knows this.
But this properly belongs on the ohttp list, not here.

> server-side proxies support.

Yes, anonymity against network adversaries does have a "winner-takes
all dynamic", e.g. why everyone uses Tor and builds around it. But Tor
is very different from a singular entity running everything, which
doesn't work for anonymity.