|
I think Emil and Bernard have described
quite precisely where we are and how we managed to get here.
In my opinion it would be a big mistake
to consider PERC as *THE* solution for end to end encryption for
multiconferencing, as if there was a one size fits all solution
for the problem.
Speaking from a WebRTC perspective,
PERC, apart of have taken some controversial technical decisions
(OHB as header, the ssrc rewriting issue and reverse the the order
of FEC/RTX and SRTP), does not take into consideration the
specifics of WebRTC (it could be argued that that was not in the
scope of this group), like the role of the js app, the possibility
of allowing key management in js, or the interaction with Idp and
isolated media streams. Not to speak about the recent discussions
about full frame vs per packet encryption or QUIC.
Best regards
Sergio
On 02/02/2019 18:42, Emil Ivov wrote:
Emil said:
"The need to do a triple encryption for example is a
particularly egregious consequence of the order problem.
That’s a problem specific to the “double” documents."
[BA] Can you describe how the need for "triple
encryption" arises? The framework document doesn't even
mention the issues with ordering of FEC/RTX/RED and
encryption, let alone the need for "triple encryption".
One of the goals that some members of the
group seemed to have was to allow specific applications to
become PERC-compliant without changing the app code itself
and by simply replacing the libsrtp library with a
PERC-enabled one.
I don’t know that this goal is a direct
consequence of the framework’s conceptual approach (contrary
to the imposition of key distribution and negotiation). I
think it simply carries a promise for some minimal pragmatic
value to some implementers.
The issue with this approach is that it leaves
hop-by-hop protection mechanisms such FEC and RTC
unavailable to the SFU as they are usually performed before
SRTP, which would make them e2e encrypted.
The solution to that is simple. One merely
needs to perform e2e encryption first, then apply FEC and/or
RTX and only then apply the second (hop-by-hop) layer of
SRTP.
This approach was referred to as “wedging RTX
and FEC” as it places them in between the two encryption
operations.
While wedging appeared to have overall support
in hallway discussions by all SFU implementors except
potentially one, it was mysteriously rejected by a subset of
the WG and replaced with the following:
Applications will apply SRTP-double first and,
those that need to use FEC and RTX would have to apply them
only after.
It was quickly pointed out that this not only
destroys the stated “don’t-change-the-app” goal, but also
leaves RTX and mostly FEC unprotected and FEC receivers
vulnerable to DoS. To this the proponents of this approach
simply replied with: “well, those of you who use FEC/RTX
will simply do a third round of SRTP”, thus arriving at a
total of three encryptions for every packet..
The discussions around this topic were highly
contentious.
Hope this makes things clear,
Emil
The need to do a triple encryption for
example is a particularly egregious consequence of
the order problem. That’s a problem specific to the
“double” documents.
I would however also say that the
decision to bake one specific way of performing key
negotiation into the framework rather than leaving
it open was both unnecessary and quite problematic.
Emil
"on the consensus not reached on
this and other topics."
[BA] Out of curiosity, what other topics
do you consider to be problematic within the
framework? I am aware of at least two
others where implementers have chosen
different paths than in the PERC framework:
* Order of application of encryption
versus FEC/RTX/RED
* Whole frame encryption versus payload
encryption
With respect to consensus, this is IETF
last call, one of whose purposes is to
determine whether there is IETF consensus to
publish this document as a Proposed
Standard. Are you saying that you do not
agree that there is an IETF consensus to
publish this document as a Proposed
Standard? Or that there is no IETF
consensus to publish *any* of the PERC WG
output as a Proposed Standard?
+1 on ssrc rewriting, and on
the consensus not reached on this and
other topics.
Sent from my iPhone
+1, SSRC rewriting is
pretty much fundamental to all SFUs
out there.
Lorenzo
Il 2 febbraio
2019 10:19:06 CET, Emil Ivov < emcho@xxxxxxxxx>
ha scritto:
I want to second
that as it is a particularly
major problem: not allowing
SSRC rewriting makes the
entire framework unusable with
SFU implementation I represent
as well as every other SFU I
am familiar with.
I am also not sure
that I agree with “SSRC
rewriting could not be allowed”
is a conclusion that ever had
any consensus in PERC,
regardless of what WG leadership
is trying to make everyone
believe.
Richard said:
"Again,
the answer is clear
here, but the document
should be clearer.
The working group
discussed SSRC
rewriting several
times, and concluded
that SSRC rewriting
could not be allowed
in this system. This
decision is reflected,
e.g., in the fact that
the Double transform
does not allow
modification of SSRCs."
[BA] Not being able
to rewrite SSRCs has
some major implications
with respect to
requirements on PERC
endpoints. Typically
today's MDD will switch
between the simulcast
streams provided by an
endpoint, forwarding
only a single stream to
other participants,
based on the bandwidth,
resolution and
framerates. If
rewriting of SSRCs is
not possible, do PERC
endpoints need to be
able to receive
simulcast? If PERC
endpoints do need to be
able to receive
simulcast, what are the
requirements for
endpoints? For example,
should endpoints expect
the MDD to use RID
header extensions to
identify the incoming
simulcast streams?
Receiving of
simulcast is tricky
because the endpoint is
receiving multiple
streams with different
sequence number spaces
which may contain holes
because of reordering or
loss. This not only
complicates the
application of RTX, RED
and FEC, but also the
operation of the
endpoint. As a result,
as noted in the WEBRTC
specification Section
5.4.1, support for
reception of simulcast
is optional. I am aware
of two ORTC
implementations that
have attempted to
support simulcast
reception, neither of
which is robust in
scenarios with
considerable loss and/or
reordering. And neither
implementation supports
the RID header extension
on received simulcast
streams.
On
01/02/2019 17:18,
Richard Barnes
wrote:
So I would
propose we add
something like the
following to this
definition:
"In the context
of WebRTC, where
control of a
session is divided
between a
_javascript_
application and a
browser, the
browser acts as
the Trusted
Endpoint for
purposes of this
framework (just as
it acts as the
endpoint for
DTLS-SRTP in
one-to-one calls).
If we decide to
adopt perc (big if)
in webrtc, shouldn't
this be defined
within the https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17
doc ?
Optimally, we would not rely on trust in any entities other than the
browser. However, this is unfortunately not possible if we wish to
have a functional system. Other network elements fall into two
categories: those which can be authenticated by the browser and thus
can be granted permissions to access sensitive resources, and those
which cannot be authenticated and thus are untrusted.
WebRTC already IdP
as trusted for
identity purposes,
so it should be up
to the RTCWEB group
to decide what is a
trusted endpoint and
what is not in
webrtc. As Bernard
is stating, we could
decide that there
are other key
management solutions
trusted (even in JS
or WASM), as for for
example is being
done in EME:
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryption
Best regards
Sergio
_______________________________________________
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc
--
sent
from my mobile
--
Inviato dal mio dispositivo Android
con K-9 Mail. Perdonate la brevità.
--
sent
from my mobile
--
sent from my mobile
_______________________________________________
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc
|
