Re: [saag] Discovery: can it be solved

[Ted Hardie <[e-mail]>]

Hi David,

On Tue, Nov 16, 2021 at 9:25 PM David Schinazi <[e-mail]>
wrote:

> I don't see any value in standardizing discovery of privacy-related
> services.
> When a client device (a user agent, if you will) ships a feature that is
> marketed at improving user privacy, the vendor makes some promises to its
> users. For example, it could say "your IP address is hidden from websites".
> The vendor needs to follow through on that claim, and the way it does that
> is
> by using specific proxies that it trusts.
>

Put differently, the need for discovery depends on what claim the folks
shipping the feature put forward.  I can imagine claims that work with
discovery, like "This software protects from on-the-wire observers
collecting your DNS traffic by using any locally available DoH or DoQ
services.  It falls back to a globally configured service when no local
services are available."  I can imagine claims that do not.

As Martin put it:

What security basis do we have for clients retrieving critical information
from the network? How does that affect the security of those clients? How
might that shape how the services that are discovered can be deployed? What
does that do to the diversity of those services?

Unless we somehow establish a consensus security basis for clients
retrieving critical information from the network, it  seems likely to me
that at least some deployments will use discovered services.



> If the vendor is fancy, it might even build
> a two-hop system with some cool privacy properties - but those properties
> still
> rely on the contractual agreements the vendor has with the other proxy
> operators.
> The vendor simply isn't going to let the local network recommend a proxy
> provider,
> because then the vendor would be lying to its users.
>

Your model is presuming a pretty powerful vendor, who can establish trust
with multiple proxies and who is maintaining contracts with them to achieve
its goals.  Less powerful (or wealthy) software providers will likely rely
on shared infrastructure for this, and there are models in which an
organization rather than a vendor provides them (a university might stand
up an OHAI-like proxy, for example, to protect the data of its students).

One size is not going to fit all here, I'm afraid.

regards,

Ted Hardie



>
> David
>
> On Tue, Nov 16, 2021 at 5:15 AM Michael Richardson <[e-mail]>
> wrote:
>
>>
>> Martin Thomson <[e-mail]> wrote:
>>     > The questions here are more fundamental.  What security basis do we
>>     > have for clients retrieving critical information from the network?
>> How
>>     > does that affect the security of those clients? How might that shape
>>     > how the services that are discovered can be deployed? What does
>> that do
>>     > to the diversity of those services?
>>
>> I think that this is a pretty good question.
>>
>> 1) IoT LLN networks would like to avoid multicast, and so we have a move
>> from
>>    multicast everything to register.
>>
>> 2) It's not a big-yellow-coax anyway, multicast is not real (its
>> emulated),
>>    MLD is broken in many places, we can't continue to play L2 tricks.
>>    We need to acknowledge the real L1 topology, and we can do this in
>> IPv6.
>>
>> 3) SEND failed due to lack of network/node/node trust relationships.
>>
>> 4) How many temporary addresses can the network sustain for each node?
>>    We have no way in current RA/RS ND/NA for the routers to put any kind
>>    of limit, and we already have documents that deal with pre-populating
>>    NCE in routers to lower latency on initial connections.
>>    If nodes need to register, then maybe the authentication can be mutual.
>>
>>     > At some level, the question of IP intermediation (aka routing) has
>> been
>>     > solved.  We assume virtually nothing from IP forwarding and routing,
>>     > but also expect very little from those providing that service.
>>
>> I don't really agree with this statement.  I don't think it's been solved.
>> I think that we have paved over this relationship (think: little child
>> with
>> fingers in their ears.... "I can't hear you"), and it's exactly this
>> relation
>> that we need to fix.
>>
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting
>> )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>