Subject: Re: [Secdispatch] Requesting agenda time for draft-krose-multicast-security

From: "Olopade, Olorunloba" <[email-masked]>
Date: Tue, 2 Nov 2021 05:53:13 +0000

Hello all,

I'm in the same boat as Morten and agree with his comments about dedicated apps (and devices). 

We are looking at Multicast to address some of these scaling issues already mentioned. It will be great if we can find a workable solution for this. 

Regards.
Save Paper - Do you really need to print this e-mail?

This email contains information from Virgin Media and/or Telefonica UK Limited (O2) and may be confidential and legally privileged. Statements and opinions expressed in this email or any attachment may not represent either those of Virgin Media or Telefonica UK Limited. Any representations or commitments in this email or any attachment are subject to contract.  The information in this email is intended solely for the attention of the addressee(s) and if you are not the intended recipient please delete it (including any attachment) from your system, and be aware that any disclosure, copying distribution or use of any of this information is not permitted.

If you are in receipt of a suspicious email or you have received an email in error from Virgin Media, please report it to www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please report it to www.o2.co.uk/help/safety-and-security. 

 Registered offices:

 Virgin Media Limited, 500 Brook Drive, Reading, RG2 6UU. Registered in England and Wales: 2591237

 Telefonica UK Limited, 260 Bath Road, Slough, Berkshire SL1 4DX. Registered in England and Wales: 1743099

 VMED O2 UK Limited, Griffin House, 161 Hammersmith Road, London, United Kingdom, W6 8BS. Registered in England and Wales: 12580944

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 3 Nov 2021 20:57:55 +0000

From: Eric Rescorla <[email-masked]>
Date: Sat,2021-10-30 at 8:00 AM
> Well, browsers don't support DTLS in the sense that they support
> TLS. What they support is a new API surface that is designed to
> serve a different set of application use cases from content delivery,
> i.e., WebRTC.

Not sure I understand the distinction here.  Surely WebRTC delivers
content too, just from a possibly-different source?

Anyway, the proposed multicast-cg work also aims to be embedded in the
APIs where it's helpful, not a new kind of scheme in the address bar,
though content delivery that comes from servers is one of the use
cases we hope to cover.

>> Multicast in particular also comes with a removal of an individualized
>> destination IP address and port, which makes it much harder to tie the
>> content to the individual who's consuming it, from an on-path observer's
>> point of view. 
>
> I'm not sure about "much harder". If you can observe the routing
> information you know a lot.

You have very little information from the routing information at most
network locations.  With multicast an attacker would have to compromise
user-specific devices or their next-hop access devices across the
population of interest to get the same kind of insight into their traffic
contents that can be inferred from published traffic analysis attacks
against TLS on traffic captured from anywhere the user's IP is visible.

And although the papers I've seen didn't address the question, it seems
like the problem of defending against traffic analysis of TLS is very
exacerbated for the popular content that gets gains by the use of
multicast--I'd bet for the 60 million people who download an extra 16gb
of encrypted data on Fortnite release day outside their usual patterns,
that particular content they've consumed is highly identifiable.  Likewise
the 20m+ people who suddenly start consuming a 6-10mbps stream for an
hour within a few minutes of the Squid Game publish time.

Against observers on devices outside their homes and next-hop access
devices (like for example near the source data center), the consumers of
traffic like this would be *much* more anonymous if the bulk data traffic
didn't have an individualized IP address on it.

Against attackers that do have access to monitoring from in-home devices,
there's no particular gains and some risk of loss on anonymity due to the
potentially easier discoverability of traffic contents.  This is of course
why we recommended that private browsing mode should not use multicast by
default, to better defend against local network admins for content the
individual user considers sensitive.

But by refusing to allow multicast where it's appropriate, we expose
users to a much wider scope of attackers for network traffic analysis,
because many fewer entities can compromise the home devices at scale
than can establish an observation post at any on-path location.

-Jake