Subject: [MBONED] Re. AMBI

From: Toerless Eckert <[email-masked]>
Date: Tue, 21 Apr 2020 20:51:42 +0200

Just to summarize on my comments on the mike in the side meeting:

If AMBI is a possible blocker/problem in getting the solution depoyed,
i think wee should consider the actual realities of how for the last
decades tha mayority of money with broacast media is made and
protected, and that is DRM on receivers:

DRM on receiver constitutes of the use of symmetric keys with
individually authenticated receivers. Each of the receivers is
given the symmetric key and is hardened so that it will not
leak this key. And i think we can also add: The DRM code is
trusted NOT to send fake traffic with the encryption key.

This is the model all the industry including hollywood trustss on.
Every browser has DRM from multiple vendors built in to support
streaming of Netwflix, Amazon, Disney and what have you.

SliverLight from Microsoft is one example i remember that had
multicsat support with DRM forever (10 years), some version even
added SSM support.

I do not understand the current maze of APIs in browsers, but
i would assume that any pcontent you need to pay for MUSST have DRM
in the browser. And that means that there will be some API how you
pass encrypted payload into the DRM from where on it will only
be directly displayed (on an uathenticated, encrypted channel display).

Aka: certainly some work to figure out the API mess and write it
down, but i can't see how the overall solution for multicst
could ignore DRM. And as soon as we know what to do to support
DRM, i think we're done for that case.

For content where no DRM is used, one could of course simply
claim that there could be some DRM, but of course the problem of
locking down software etc. for DRM is limiting its use. As we
see on linux. So an AMBI type option is still quite valuable,
but it wouldn't sitblocking existing business models.

Cheers
    Toerless

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 29 Apr 2020 04:31:53 +0000

Hi Toerless,

Thanks for commenting and for suggesting a path forward.  I have
several responses.

> protected, and that is DRM on receivers:

As I said, I think this is an interesting idea and an interesting
argument, but on reflection I don't think it meets the security needs
for deployment.

Before laying out my argument in detail, I want to clarify a few points
up front:

1.
My understanding so far is that AMBI as written is not a blocker to
getting the solution deployed.

However, a substantial change to its security properties COULD be a
blocker to getting the solution deployed.  (I'll lay out this case in
more detail below.)

If I am able to deploy the system as it stands, I don't know of any
security-based objections yet.  The objections so far are of the form
"I don't think you'll be able to deploy this as it stands", or perhaps
"I think it will be too hard in general for people to deploy this as
it stands".  (As an aside, I would have preferred to see these raised
during the adoption call, because doing an alternative would require
getting a new and different doc accepted, but I think it doesn't
matter all that much, and I'm certainly willing to engage with these
objections at this stage, as well as grateful for the reviews and
suggestions.)

My current belief is that I will in fact be able to deploy it roughly
as it stands, and others won't have a substantially harder time
bringing up something like a kubernetes fleet that can do it also.

To me, the unicast-stream version of AMBI isn't substantially harder
to serve than any normal scalable streaming, except it's at ~1/30th
the scale of streaming the video it's authenticating, and once the
multicast version with signed manifests works (c.f. ALTA, which
still needs a lot more work before I want to ask for adoption), it'll
be even easier.

But if I turn out to be wrong on those points, I will of course report
that to mboned and withdraw the proposal, and hopefully raise a new
proposal in its place.  (This of course would also be the case for the
alternative suggestions I've heard so far, if I became convinced that
one of them would be a better approach.)

2.
I think I mentioned it briefly at the time, but should probably
give some more context about the side conversation with Ben Kaduk
(security AD) that I referenced when we adopted this draft:
https://www.youtube.com/watch?v=ttGJyd5is2w&t=1h17m22s

When he told me in Singapore that the proposed approach was simple
and therefore reasonable to work on in mboned with just a security
area review, rather than to work on it in the security area, there
were a few things he talked about in the context of claiming it's
simple:
- it has wide crypto flexibility about algorithm selection and isn't
  tied in any tight way to hard requirements on key sizes, etc.
- it uses only standard secure crypto systems in a reasonable way
  that's common and well-vetted in other security systems

This meant it was not the kind of cryptographic innovation that
needed to happen in the security area, and that it was therefore
OK to do the work in a place like mboned with just a security review
once we've got consensus it will meet the multicast delivery goals.

I don't think he envisioned a fundamental change to the security
design under this judgement of simplicity, so if we did something
like a significant change to the approach, I would want to re-check
with some security review before giving it serious consideration,
because by my understanding that would step outside the scope of
what was discussed at that time.

Likewise, when speaking with people accustomed to checking code
into the browser, the first questions were generally about how it
would be secured, and the hand-wavy version of describing AMBI's
operation was considered satisfactory.

Although I didn't have the conversation with everyone, as I
understood it they were generally prepared to object strongly that
shared keys would not be adequate for transport-layer security to
authenticate content that would be passed into MSE.  Some said
they were half expecting that I would propose it or another
unworkable scheme, and they typically only gave further
consideration to the API after I had satisfied them that the
authentication approach was resting on already well-known security
properties that were applied appropriately.

This forms the basis of my belief that changing to a shared key
system would be a likely blocker to adoption.

3.
With the above 2 points clarified, I'll now engage with the meat
of the given suggestion about authenticating via feeding the data
into existing DRM systems:

> But to flesh out that point a bit, 
>

One advantage for AMBI here is that it proposes to authenticate the
traffic before trying to construct video segments out of it.  This is
useful for a few reasons:
- FEC reassembly is a reasonably large attack surface, and would be
  best applied to traffic that's already authenticated, at least until
  the FEC implementations are mature enough to be well-hardened.
- I want to support more use cases than streaming video, such as
  downloads that are typically do not have DRM integrated
- The DRM space is usually quite restrictive, with authentication and
  signed binaries and its own complex ecosystem.  Although there is
  some browser integration with DRM, passing multicast-delivered
  traffic into a DRM system would approximately double the complexity
  of deploying receiving systems, since it would need changes to the
  browsers in addition to the DRM systems.

However, even though these considerations are probably sufficient, the
bigger reason is that DRM systems do not provide authentication, they
provide authorization and a form of confidentiality.  They rely on the
transport layer for authentication.  This is explicitly described for
example in section 3.2 in the description for the "l.2" property in
"Core Security Requirements of DRM Systems" by H.L. Jonker and S. Mauw:
https://www.researchgate.net/publication/228958248_Core_security_requirements_of_DRM_systems

On top of that, the security model between the 2 systems (DRM vs.
transport layer security) is fundamentally different:

The goal of a DRM system is to make it hard for a casual user to
defeat it easily, and it's coupled with legal enforcement actions
against those who redistribute the content or the keys to keep the
piracy ecosystem from having a wide reach, but there are many things
that the DRM system itself provides no protection against (like the
content authentication example, above).

By contrast, transport layer security is trying to protect against
a more sophisticated set of attacks, most prominently those delivering
Remote Code Execution (RCE) payloads to compromise end systems, sometimes
with 0-days (previously unknown attacks).  There also is concern over the
capability of delivering alternative content while representing the
sender as the source of it.

These attacks are not theoretical, they've been observed in the wild,
for example as described in these talks:
https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild-A-Large-Scale-Study.pdf#page=10
https://www.blackhat.com/docs/us-16/materials/us-16-Sivakorn-HTTP-Cookie-Hijacking-In-The-Wild-Security-And-Privacy-Implications.pdf#page=7

And likewise, the threat that an injection of malicious content into
the video player could compromise receiver systems at scale is also
not a theoretical problem:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2107
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13962

This is another of the commonly cited issues, where I understood that
although many of the browser developers were aware that even though
http is still sometimes used (with increasing levels of warning and a
deliberate drive to phase it out as soon as practical), at least the
scale of this kind of attack against an http connection is limited to
targeted attacks, because packet injections have to reach an active
unicast endpoint and match its connection state.

However, allowing insufficiently authenticated multicast dramatically
increases the scale of the potential attack, and is an extra cause for
concern that has been frequently expressed.  Multicast authentication
might very well need to be *more* secure than unicast authentication
needs to be, because of the increased exposure of users if there is a
successful RCE injection.

> be directly displayed (on an uathenticated, encrypted channel display).

I don't think it's too hard to follow if you want to understand it.
There's an example dummy usage of the current APIs with clearkey here
for instance, and generally the vendors have sample canonical usage
docs for their in-browser solutions:
https://developers.google.com/web/fundamentals/media/eme#clear_key

The problem is that you need to have received an object that's already
been authenticated before you can pass it into the EME APIs.  For
instance, it already has to be in a secure context, so you can't
access the APIs if you're dealing with something that hasn't already
provided transport layer security:
https://www.w3.org/TR/encrypted-media/#privacy-secureorigin

And even if the DRM systems did provide authentication, then a packet
injection or packet change would just become a denial of service,
because the encrypted media chunk would be wrong, but you would not
be able to pick out the valid multicast packets from the invalid
ones, unless you somehow did a per-packet authentication scheme, but
added the direct multicast receive capability to the CDMs in addition
to (or instead of) adding it to the browsers, but this would be even
harder than adding it to the browsers, and still would not solve the
problem unless it made the shared key concept usable.  But that in
turn would require a deep integration with the sender platforms, so
the whole concept would get a lot more complicated to deploy.

> DRM, i think we're done for that case.

I think the proposed solution in AMBI will interoperate well with
DRM, because it will operate at a separate layer.  AMBI does per-
packet authentication before delivering the payloads to javascript,
and then javascript can either construct proper segments and pass
them to MSE or to the ESE apis (or to the file system apis for
downloads), as appropriate for the multicast service.

> but it wouldn't sitblocking existing business models.

I don't think AMBI is blocking business models, but if you disagree
I'd like to hear more about how.

I think the "too complicated" critiques so far have focused more
on the operational complexity of delivering the authenticated
manifests to the hosts in the same time window as the data packets
that are being authenticated.

While I agree this can be complicated and easy to get wrong when
you attempt it at scale, I also think that even in the complicated
unicast case this is not harder than scaling the video to 30x the
bandwidth usage.  But also, I expect it to get a lot easier for
those who want to run it with multicast authentication once there
is a multicast approach written down for delivering the manifests,
and the intent of the current text in AMBI is that it would
explicitly be compatible with such a system, so the unicast
system I intend to bring up first will not be required.

Anyway, I hope that's a helpful explanation.  I'm going to try to
reword some of that and fold it into one of the "rejected designs"
sections that I want to add to the doc.

Thanks again for the comments.

Best regards,
Jake