|
PERC may be a valid solution for some scenarios, maybe SIP.
But in regards of WebRTC, my personal opinion is that it is not
well suited and that we should do a fresh start, with an analysis
of the requirements and specifics of webrtc, define trust models,
role of the js apps, UI/UX, IdP and isolated media streams, key
management within browser, compatibility with webrtc 1.0, if we
need to support it in SDP or not, QUIC, WASM, etc.. and then check
if PERC is able to fulfill them or what parts can be reused, if
any.
Best regards
Sergio
On 02/02/2019 21:42, Bernard Aboba
wrote:
Sergio -
In your opinion, what portions of PERC are
salvageable, if any? Is this a situation where we need to
start over or could some aspect of PERC (e.g. Double if the
triple encryption problem were fixed) be suitably modified and
then implemented?
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
|
