Mostly I view this thread as the same set of people that failed to get consensus in the WG trying to reopen issues that was clearly not consensus for so I have mostly ignored this thread … but let me comment on the “JS access to media keys” issue.
"JS access to media keys" is exactly the heart of the issue of the SDES keying of SRTP vs. DTLS keying of SRTP - the WebRTC group had a huge discussion on that topic. This discussion finalized in a large meeting at IETF-87 that including many of the SIP, WebRTC, and Security folks at IETF. The consensus was extremely strong for not doing the SDES solution that put the keys in JS. ( See https://www.ietf.org/proceedings/87/minutes/minutes-87-rtcweb )
In some cases Google and other are fans of of what I think of as End to Middle security. That is things need to be secure from User A to Google and from Google to user B but no need to be secure from A to B. In some cases that is fine but in other cases we want security from A to B. PERC is all about making things strong from A to B. Since IETF 87, I do not think the IETF consensus on things like SDES has gotten weaker - in fact we have moved to a stronger desire for the best security we can design and making end to end possible where we can.
Bit more inline …
(+Cullen) (as individual)
Hi Sergio,
I don’t recall, and I don’t see anything in the notes or email consensus call, that would suggest the consensus included anything along the lines “it’s okay to let the js application have the media keys.” That is, even if the idea was to let PERC do it’s thing and let other groups spin their own key management systems, I don’t think there’s a consensus that everyone would be okay with that particular approach.
Cullen: As the other join presenter, do you have thoughts?
Mostly the agreement was we would the way EKT and double was done breaking all the existing implementation if Sergio and Emil agreed they would support that approach. Before the meeting, Emil decided he did not support it which made the many of us regret making the breaking changes. We were hoping to find a way to move forward without the constant problem of people saying the did not like the solution in the WG while not being able to present an alternative that addressed the security requirements and issues that had been raised (such as the splicing attack).
Any group at IETF or other organization can always do some other form of perc-lite and nothing the PERC WG had done limits that in any way and simular nothing done in PERC WG can for some other WG or organization to do anything in particular. That was clear then and clear now.
Thanks!
Ben.
Hi Ben,
The consensus we reached in Prague was
that while many of us didn't like the proposed solution, we
managed to put together a solution that was technically feasible,
so we were not going to prevent the ones in favor of it for
getting it done as it could be possible to advance with perc lite
and alternative key management in different forums (namely w3c).
When the use case was presented in the
w3c webrtc for nv, the liaison statement was sent to prevent the
discussion to even get started. So I personally consider the
consensus is invalidated (and so seems others), others even
question that the consensus was even reached on the first place.
Best regards
Sergio
On 13/02/2019 21:21, Ben Campbell
wrote:
(as individual)
Hi Sergio,
Can you elaborate on that comment? The statement you
reference was explicitly about preserving the PERC trust model.
How does it overturn any consensus in PERC?
Thanks!
Ben.
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
_______________________________________________
Perc mailing list
Perc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/perc
|
