|
You are missing an important piece on
the timeline:
Statement from the IETF ART and SEC
Area Directors regarding the "Trusted application, untrusted
intermediary" use case
This liaison statement basically blows
away any rough consensus from IETF 99 as the basis of my joint
proposal was that it could be possible to proceed with the PERC
lite proposal and that alternative keying mechanism could be
studied without involving the PERC group.
Best regards
Sergio
On 13/02/2019 2:34, Nils Ohlmeier
wrote:
Thank you for the input on the framework and the double documents from everyone.
The points raised by the individuals here are not new and have been discussed before by the WG at several occasions. And for these issues there has be no WG consensus.
Specifically on the points regarding double encryption:
At IETF 95 double had consensus and got adopted (after 4 design team meetings and 3 IETF meetings).
At IETF 96 the WG chairs re-opened the discussions around SSRC mutability and Emil got asked to submit a draft on the security impact of SSRC mutability
At IETF 98 SSRC immutability and RTX considerations were discussed but no proposal made on security implications
At IETF 99 the double authors and Sergio presented a joint proposal. The WG chairs called for consensus in the room and on the list and concluded that with rough consensus, the proposal got adopted.
Best regards
Nils & Suhas
PERC WG chairs
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
_______________________________________________
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc
|
