[Cryptography] Apple's iCloud+ "VPN"

[Liam Ayr]

> On 28 Jun 2021, at 5:27 pm, Bill Woodcock <woody at pch.net> wrote:
> 
>> On Jun 28, 2021, at 5:09 AM, Lanlan Pan <abbypan at gmail.com> wrote:
>> They are using ‘Oblivious DNS’. A technology co-authored by Cloudflare, Fastly, and Apple.
> 
> Neither of these statements is correct.
> 
> They’re using ODoH, not ODNS.

Yes. apologies. I was being careless with language. I meant that Apple are using Oblivious DNS over HTTPS.  Which is related to the aforementioned 3 organisations.


> ODNS was authored by Anne Edmundson , with Paul Schmitt, Allison Mankin, and Nick Feamster.  None of the are associated with Cloudflare, Fastly, or Apple.
> 
>> The first step, a number of years ago, in improving the privacy of DNS - an otherwise entirely plaintext protocol, was to use https (or TLS) between the client and the resolver.
> 
> The first (and sufficient) step was TLS.  HTTPS came later, as a significant privacy and net-neutrality downgrade.

I’m curious why you regard HTTPS as a downgrade in those terms? Not contesting it, just curious for more information.

>> This stopped eavesdropping but the resolver still knew what the request was and where it was coming from.
> 
> …which means that it didn’t stop eavesdropping, it just reduced the number of parties to the eavesdropping, which consequently vastly increased the monetization value of the data for the parties which now possess a scarcer resource.  Reduction is good but, as you point out, its incompleteness was why ODNS was conceived.
> 
>> Oblivious DNS adds am extra hop in such a way as the resolver knows what the request is - so can answer it - but doesn’t know who the requestor is.
> 
> That is only true in the case in which the “target” or exit node is not also a CDN and party to subsequent web transactions which invariably contain authentication / login / cookie / fingerprint information.

> If the target / exit node is operated by a CDN, ODNS and ODoH are worse than useless, and provide only a false sense of privacy.

This is confusing. I’m talking about DNS resolution. The client, over an encrypted channel, talks to the resolver proxy which talks to the resolver and then sends back the answer.  Where is the auth / login / cookie / fingerprint information in a name look up?

Once I have my IP address returned for website.some.domain I go there. That doesn’t mean I go via any CDN necessarily.  If I do then yes I see your point as it’s carrying the website payload. I recall our Akamai representative going very quiet when questioned the integrity of our https traffic via Akamai.  All he ended up saying was "depends where think the business endpoint is" or some such.

But in terms of resolving using ODoH per the protocol can you explain why the CDN is in a privileged position if it happens to run the ODoH proxy.  My reading of the design is that the whole point is no single point in the path can possess all the information.

>> My location has regulations that require ISPs to prevent access to some BitTorrent and file sharing sites.  ISPs have a choice of technology to do this as long as the content providers (movie studios, record companies) agree. One is to prevent DNS queries returning the right answer, instead resolving to a scary webpage that says naughty.  If iCloud Private Relay sends to a resolver such as provided by google or cloudflare or quad9 then I don’t see how the interception by the ISP will be relevant.
> 
> Cloudflare has reportedly already complied with content-based blocking requests via their DNS last year (though their case was more clear-cut: the infringing torrent site was their paying customer), and Quad9 is currently fighting an injunction which would force blocking of unrelated domains.

Unfortunately I haven’t read the details of the case involving Sony, just the quad9 blog entry.  Quite the overreach and unacceptable.  Hoping for a successful appeal.

regards

L.