From nobody Fri Feb 1 08:18:24 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369A5130F3A for ; Fri, 1 Feb 2019 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJIUVNPSbE9s for ; Fri, 1 Feb 2019 08:18:17 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C73A130F33 for ; Fri, 1 Feb 2019 08:18:17 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id v6so6261665oif.2 for ; Fri, 01 Feb 2019 08:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CsWlmcPp0SeOjXM9VsMiBidOdCsbybS/pz06NPluSqU=; b=ebqaeTZOzIfFtGTU82jfJwtRharNcTd8LclYZjkTtVqwmHQMVHFZ9vTUrkkGPMn0Jl 1WBQb8lpVYBRqV+FvYTHs2cwr77oxsOcImp/2q6x5/xquSTFRK1Ew1wZdHrVsUm5BDXe J710otZtPWv4KB19GV9XOr9br++1e5rftCy/3t8eYFW5vkU+InB8RRIxIZGp4Qg7pwWF GY25svWFqJrTpPuR2mMMIXseuhFpe78BYbVY1gHScvU5BvcDxz+0vDkm2jkGVO6aQuli 1RXFO5JN9oTXJQ+bKItiO3UhnRv/ebIxJYHQI/iZWIo008NNBLnXUkyod8vlPAQyL2U1 UzMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CsWlmcPp0SeOjXM9VsMiBidOdCsbybS/pz06NPluSqU=; b=pVvC1EmJ1BnDFwizOIXZU53J3QZSyZCd9LDZsUm7iTox+ViV0NJHtVaU5klNh9BfB8 fhu5RX+FMNC1b3WDfTijFNqatRz1Hn+aAlaoR3Drukjnk2BTCwBUq8Zz/I0Kr7j4snh1 cJy8LHwKxyQw8yUDjK8yoK+B4q7eBMZ+mfFtns0MYCXi/ZltZFxY3YsXtCXk56HzauWf BKFawSTpkSPshuUp080XMtD2FTci97W5Z7Smmu+xQ9nP8vUU6ZnVpN6eDPP8Zm3Oyzu2 1iJv9phZpwPeE3fIlliXsG1hD/7/HJStqwGV4fS3+T9qHZwGp4DbN6WcBV8c9bre5JLa JB7w== X-Gm-Message-State: AHQUAubkRBob9bDdyzBBp1N7duCa0ICtqMSNiGfmFe7zTJxziMHk3Lzj xJi3r3D8FUk8LMrip8i2aMtSbHuGtTjx38k14ieo9g== X-Google-Smtp-Source: AHgI3IZByO1hSmkpRIxJ1yqrfTxiZ3I/XAireQ6yS8STG74kBj1clKoM3p/S2AWlXqHWoSp3ZS7H7oOFk02ijhVDaI0= X-Received: by 2002:aca:6b8c:: with SMTP id g134mr17889970oic.135.1549037896254; Fri, 01 Feb 2019 08:18:16 -0800 (PST) MIME-Version: 1.0 References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> In-Reply-To: From: Richard Barnes Date: Fri, 1 Feb 2019 11:18:00 -0500 Message-ID: To: Bernard Aboba Cc: IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, Alexandre GOUAILLARD , The IESG Content-Type: multipart/alternative; boundary="0000000000008ce0160580d77db7" Archived-At: Subject: Re: [Perc] Last Call: (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 16:18:22 -0000 --0000000000008ce0160580d77db7 Content-Type: text/plain; charset="UTF-8" Hi Bernard, Thanks for taking a fresh look at this. On Thu, Jan 31, 2019 at 10:51 PM Bernard Aboba wrote: > My review of draft-ietf-perc-private-media-framework-08, found below, > represents my personal opinion. > > In reading this document, I was disappointed to find that it did not > address some key issues that have been encountered by implementers. I > therefore feel that the document is not ready for publication. > > Problem #1: Definition of a Trusted Endpoint > > The document defines a "Trusted Endpoint" as follows: > > Trusted Endpoint: An RTP flow terminating entity that has possession > of E2E media encryption keys and terminates E2E encryption. This may > include embedded user conferencing equipment or browsers on > computers, media gateways, MCUs, media recording device and more that > are in the trusted domain for a given deployment. > > > In practice, this definition has created considerable confusion among implementers, particularly those who have attempted to > > implement Web-based applications. > > > In these situations, an "endpoint" may represent a unitary native application, or potentially an application written in > > Javascript or WASM running on a browser platform. In such a situation, portions of the application code may > > be provided by multiple parties, which might include the domain in control of the key management server, a party > > unrelated to the provider of the MDD or key management server, etc. In such situations, the definition of > > "trusted endpoint" provided in this document becomes difficult to apply. > > > This point has been underlined by a recent IESG note sent to the W3C WEBRTC WG which has been attempting to > > develop use cases based upon the PERC framework, and has found itself unable to come to consensus on the > > meaning of a "trusted endpoint": > > https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0114.html > > > In beginning my review of this document, I was hoping to find material relating to the points made in the IESG > > relating to the nature of a "trusted endpoint", but was disappointed that few of the points made by the IESG > > were expounded upon in the document. Since the IETF generally requires documents to stand on their own without the > > need for IESG interpretation, this appears to represent a serious inadequacy in the current framework document. > > I appreciate that there's confusion here, and I think we can clarify. It seems pretty clear from the other documents in this suite (draft-ietf-perc-srtp-ekt-diet and draft-ietf-perc-double) that this system only really makes sense in the case where the browser is trusted and the JS is not. Otherwise, you would not need the DTLS parts of EKT, since you could rely on some external thing to provide the key encryption key. (Note that this latter architecture was proposed, considered, and rejected by the WG.) 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)." Problem #2: Relationship to RTP topology model (RFC 7667) > > > The document defines a Media Distributor (MD) as follows: > > > Media Distributor (MD): An RTP middlebox that forwards endpoint media > content (e.g., voice or video data) unaltered, either a subset or all > of the flows at any given time, and is never allowed have access to > E2E encryption keys. It operates according to the Selective > Forwarding Middlebox RTP topologies [RFC7667 ] per the constraints > defined by the PERC system, which includes, but not limited to, > having no access to RTP media unencrypted and having limits on what > > RTP header field it can alter. > > > The Selective Forwarding Middlebox is described in RFC 7667 Section 3.7 as follows: > > Another method for handling media in the RTP mixer is to "project", > or make available, all potential RTP sources (SSRCs) into a per- > endpoint, independent RTP session. The middlebox can select which of > the potential sources that are currently actively transmitting media > will be sent to each of the endpoints. This is similar to the Media- > Switching Mixer but has some important differences in RTP details... > > As the middlebox selects the source in the > different RTP sessions that transmit media to the endpoints, each RTP > stream requires the rewriting of certain RTP header fields when being > projected from one session into another. In particular, the sequence > > number needs to be consecutively incremented based on the packet > actually being transmitted in each RTP session. Therefore, the RTP > sequence number offset will change each time a source is turned on in > an RTP session. The timestamp (possibly offset) stays the same. > > The RTP sessions can be considered independent, resulting in that the > SSRC numbers used can also be handled independently. This simplifies > the SSRC collision detection and avoidance but requires tools such as > remapping tables between the RTP sessions. Using independent RTP > sessions is not required, as it is possible for the switching > behavior to also perform with a common SSRC space. However, in this > case, collision detection and handling becomes a different problem. > It is up to the implementation to use a single common SSRC space or > separate ones. > > Using separate SSRC spaces has some implications. For example, the > RTP stream that is being sent by endpoint B to the middlebox (BV1) > may use an SSRC value of 12345678. When that RTP stream is sent to > endpoint F by the middlebox, it can use any SSRC value, e.g., > 87654321. As a result, each endpoint may have a different view of > the application usage of a particular SSRC. Any RTP-level identity > information, such as SDES items, also needs to update the SSRC > referenced, if the included SDES items are intended to be global. > Thus, the application must not use SSRC as references to RTP streams > when communicating with other peers directly. This also affects loop > detection, which will fail to work as there is no common namespace > and identities across the different legs in the Communication Session > on the RTP level. Instead, this responsibility falls onto higher > layers. > > [BA] I interpret the above text as potentially allowing the MDD to rewrite > the SSRC of > > RTP and RTCP packets. Yet my reading of the framework document is that such rewriting > > could be problematic, since Section 4.3 of the framework document notes that the SSRC > > is utilized to identify which E2E keys are to be used to decrypt a given RTP media flow: > > 4.3 . E2E Keys and Endpoint Operations > > Any given RTP media flow is identified by its SSRC, and an endpoint > might send more than one at a time and change the mix of media flows > transmitted during the life of a conference. > > Thus, an endpoint MUST maintain a list of SSRCs from received RTP > flows and each SSRC's associated E2E key information. An endpoint > MUST discard old E2E keys no later than when it leaves the conference > (see Section 4.5.2 ). > > > [BA] Given the above, it is not clear to me whether the framework document > has added restrictions on > > the behavior of the Selective Forwarding Middlebox (such as no SSRC rewriting), and if so, what the > > implications are for existing implementations. > > 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. I'll leave it to Paul to propose concrete fixes here, since I'm less familiar with these points. --Richard > > On Wed, Jan 30, 2019 at 7:45 PM The IESG wrote: > >> >> The IESG has received a request from the Privacy Enhanced RTP >> Conferencing >> WG (perc) to consider the following document: - 'A Solution Framework for >> Private Media in Privacy Enhanced RTP >> Conferencing' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2019-02-13. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document describes a solution framework for ensuring that media >> confidentiality and integrity are maintained end-to-end within the >> context of a switched conferencing environment where media >> distributors are not trusted with the end-to-end media encryption >> keys. The solution aims to build upon existing security mechanisms >> defined for the real-time transport protocol (RTP). >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ >> >> IESG discussion can be tracked via >> >> https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --0000000000008ce0160580d77db7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bernard,

Thanks for taking a fresh look at this.

On Thu, Jan 31, 2019 at 1= 0:51 PM Bernard Aboba <bernar= d.aboba@gmail.com> wrote:
My revi= ew of=C2=A0draft-ietf-perc-private-media-framework-08, found below, represe= nts my personal opinion.=C2=A0

In read= ing this document, I was disappointed to find that it did not address some = key issues that have been encountered by implementers. I therefore feel tha= t the document is not ready for publication.=C2=A0

Problem #1:=C2=A0 Definition of a Trusted Endpoint

The document defines a "Trusted Endpoint" as follows:=C2=A0

   Trusted Endpoint: An RTP flow terminating enti=
ty that has possession
   of E2E media encryption keys and terminates E2E encryption.  This may
   include embedded user conferencing equipment or browsers on
   computers, media gateways, MCUs, media recording device and more that
   are in the trusted domain for a given deployment.

In practice, this definition has created considerable confusion among impl= ementers, particularly those who have attempted to
implement Web-b=
ased applications. 

In these situations, an "en=
dpoint" may represent a unitary native application, or potentially an =
application written in
Javascript or WASM running on a browser pla=
tform.  In such a situation, portions of the application code may
= be provided by multiple parties, which might include the domain in control = of the key management server, a party
unrelated to the provider of=
 the MDD or key management server, etc.  In such situations, the definition=
 of
"trusted endpoint" provided in this document becomes=
 difficult to apply. 

This point has been underlined=
 by a recent IESG note sent to the W3C WEBRTC WG which has been attempting =
to
develop use cases based upon the PERC framework, and has found =
itself unable to come to consensus on the
meaning of a "trust=
ed endpoint":
https://lists.w3.org/Archives/Public/public-webrtc/2018Nov=
/0114.html

In beginning my review of this d=
ocument, I was hoping to find material relating to the points made in the I=
ESG
relating t=
o the nature of a "trusted endpoint", but was disappointed that f=
ew of the points made by the IESG
were expounded upon in the docum=
ent.  Since the IETF generally requires documents to stand on their own wit=
hout the 
need for IESG interpretation, this appears to represent =
a serious inadequacy in the current framework document.
<= /div>

I appreciate that there's c= onfusion here, and I think we can clarify.

It seem= s pretty clear from the other documents in this suite (draft-ietf-perc-srtp= -ekt-diet and draft-ietf-perc-double) that this system only really makes se= nse in the case where the browser is trusted and the JS is not.=C2=A0 Other= wise, you would not need the DTLS parts of EKT, since you could rely on som= e external thing to provide the key encryption key.=C2=A0 (Note that this l= atter architecture was proposed, considered, and rejected by the WG.)
=

So I would propose we add something like the following = to this definition:

"In the context of W= ebRTC, where control of a session is divided between a JavaScript applicati= on 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)."
=C2=A0

Problem #2:  Relationship to RTP topology model (RFC 7667)

The document defi=
nes a Media Distributor (MD) as follows:

   Media Distributor (MD): An RTP =
middlebox that forwards endpoint media
   content (e.g., voice or video data) unaltered, either a subset or all
   of the flows at any given time, and is never allowed have access to
   E2E encryption keys.  It operates according to the Selective
   Forwarding Middlebox RTP topologies [RFC7667=
] per the constraints
   defined by the PERC system, which includes, but not limited to,
   having no access to RTP media unencrypted and having limits on what

      RTP =
header field it can alter. 

The Selectiv=
e Forwarding Middlebox is described in RFC 7667 Section 3.7 as follows:
   Another method for handl=
ing media in the RTP mixer is to "project",
   or make available, all potential RTP sources (SSRCs) into a per-
   endpoint, independent RTP session.  The middlebox can select which of
   the potential sources that are currently actively transmitting media
   will be sent to each of the endpoints.  This is similar to the Media-
   Switching Mixer but has some important differences in RTP details...
   As the middlebox selects=
 the source in the
   different RTP sessions that transmit media to the endpoints, each RTP
   stream requires the rewriting of certain RTP header fields when being
   projected from one session into another.  In particular, the sequence

   number needs to be conse=
cutively incremented based on the packet
   actually being transmitted in each RTP session.  Therefore, the RTP
   sequence number offset will change each time a source is turned on in
   an RTP session.  The timestamp (possibly offset) stays the same.

   The RTP sessions can be considered independent, resulting in that the
   SSRC numbers used can also be handled independently.  This simplifies
   the SSRC collision detection and avoidance but requires tools such as
   remapping tables between the RTP sessions.  Using independent RTP
   sessions is not required, as it is possible for the switching
   behavior to also perform with a common SSRC space.  However, in this
   case, collision detection and handling becomes a different problem.
   It is up to the implementation to use a single common SSRC space or
   separate ones.

   Using separate SSRC spaces has some implications.  For example, the
   RTP stream that is being sent by endpoint B to the middlebox (BV1)
   may use an SSRC value of 12345678.  When that RTP stream is sent to
   endpoint F by the middlebox, it can use any SSRC value, e.g.,
   87654321.  As a result, each endpoint may have a different view of
   the application usage of a particular SSRC.  Any RTP-level identity
   information, such as SDES items, also needs to update the SSRC
   referenced, if the included SDES items are intended to be global.
   Thus, the application must not use SSRC as references to RTP streams
   when communicating with other peers directly.  This also affects loop
   detection, which will fail to work as there is no common namespace
   and identities across the different legs in the Communication Session
   on the RTP level.  Instead, this responsibility falls onto higher
   layers.

[BA] I interpret the above text as potentially allowing the MDD to rewrite =
the SSRC of
RTP and RTCP packets.  Yet my reading of the framework=
 document is that such rewriting
could be problematic, since Secti=
on 4.3 of the framework document notes that the SSRC
is utilized t=
o identify which E2E keys are to be used to decrypt a given RTP media flow:=

4.3.  E2E Keys and Endpoint Op=
erations


   Any given RTP media flow is identified by its SSRC, and an endpoint
   might send more than one at a time and change the mix of media flows
   transmitted during the life of a conference.

   Thus, an endpoint MUST maintain a list of SSRCs from received RTP
   flows and each SSRC's associated E2E key information.  An endpoint
   MUST discard old E2E keys no later than when it leaves the conference
   (see Section 4.5.2).


[BA] Given the above, it is not clear to me whether the framework docum=
ent has added restrictions on
the behavior of the Selective Forwar=
ding Middlebox (such as no SSRC rewriting), and if so, what the
im=
plications are for existing implementations. 
=


Again, the answer is clear here, but the d=
ocument should be clearer.=C2=A0 The working group discussed SSRC rewriting=
 several times, and concluded that SSRC rewriting could not be allowed in t=
his system.=C2=A0 This decision is reflected, e.g., in the fact that the Do=
uble transform does not allow modification of SSRCs.

I'll leave it to Paul to propose concrete fixes here, since I'm =
less familiar with these points.

--Richard

=C2=A0






On Wed, Jan 30, 2019 at 7:45 PM The IESG &l=
t;iesg-secreta=
ry@ietf.org> wrote:


The IESG has received a request from the Privacy Enhanced RTP Conferencing =


WG (perc) to consider the following document: - 'A Solution Framework f=
or

Private Media in Privacy Enhanced RTP

=C2=A0 =C2=A0Conferencing'

=C2=A0 <draft-ietf-perc-private-media-framework-08.txt> as Proposed S=
tandard



The IESG plans to make a decision in the next few weeks, and solicits final=


comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2019-02-13. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the beginning of

the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This document describes a solution framework for ensuring that=
 media

=C2=A0 =C2=A0confidentiality and integrity are maintained end-to-end within=
 the

=C2=A0 =C2=A0context of a switched conferencing environment where media

=C2=A0 =C2=A0distributors are not trusted with the end-to-end media encrypt=
ion

=C2=A0 =C2=A0keys.=C2=A0 The solution aims to build upon existing security =
mechanisms

=C2=A0 =C2=A0defined for the real-time transport protocol (RTP).









The file can be obtained via

https://datatracker.ietf.or=
g/doc/draft-ietf-perc-private-media-framework/



IESG discussion can be tracked via

https://datatracker.=
ietf.org/doc/draft-ietf-perc-private-media-framework/ballot/





No IPR declarations have been submitted directly on this I-D.









_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc



_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




--0000000000008ce0160580d77db7--


From nobody Fri Feb  1 08:58:48 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47613103A; Fri,  1 Feb 2019 08:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgM1DjmtKNc6; Fri,  1 Feb 2019 08:58:34 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893DF13101F; Fri,  1 Feb 2019 08:58:34 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id x28so4573181vsh.12; Fri, 01 Feb 2019 08:58:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KbtGvCfwe7yDHnlIIhAnhc1NgQZBBIiiq3RxZCZ8c5w=; b=lETs5I+uYtx8yQHeMSNew+2XlGbdxmF7HZCzwHfFPSEZ2vK2X9R2gQM9vZ4PcF+MJk BSMnRvQpoLYVY2ohevydaNrrvJqLnUAhFY5S8uqTgq/Q30GUPSp0eTUe5eIbjTAj7tdj Ol55whMiNns3G1qPpudt3GWpbfAh03dYhvypD7fmbV7XlWl1RVwzrGhi4z1Xj+XjL8Zu aQYgcyFwJCGrx4UjI0mFbQjF0p3rQczXQAPu0JaA5teIxz2900If+elgG8SRjLsvPb7+ 79rnQe6x8GfL4vgKSYjEx0aIPwfhW1i9UqjI9Mv4fSiXaWtHHuYBEudrh33yXTVZyumM czsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KbtGvCfwe7yDHnlIIhAnhc1NgQZBBIiiq3RxZCZ8c5w=; b=bz+LemVtT1HrBzTreiIJ4GWP9/SkiERXJYK5gWm+WtlR+VQTSMc8pMheL3oaMwsI66 9hK3Ajxet+Pcx9FXX7DCiUiJabkAH2iWWB3ntNw/jEUmAwZ2mziZZVq1wbJjbj2Y3i4L ZFxvVd0xcgetKo14QmY1N5fFqrVIdDvSgYQCd7N6mvVtwjbjW/SmhLI6OlZ/XWuf6Xoq 9DVvdljtnIw7sMK01PqgTu5v+UtWpnrugS/hZgrjQEXAUtELnBvZxiA9bAqBSesOYwuV xcCQS4jhonXwkKTe3nT+NWGMqPTJT4IC6VzmO/G2ZPR4bUizLfOSzQ90Z4ZjeGe46GMQ 6U6g==
X-Gm-Message-State: AJcUukczcZ6CfrR7pWUd1/WGhM5qIO3x3o6cSiFG6XPp8vg1xfw6894/ R12H91LETkekz8Pd9i9Dg4hF+kWZSvJnJ1hO66w=
X-Google-Smtp-Source: ALg8bN5cqX58GL65SK4ypB/PdGyYK71FROEi11VyweNGQ/rLRFeD4+FQREDMCUnb1sPlUTkbS55Gv33nzi6oH4271i4=
X-Received: by 2002:a67:804e:: with SMTP id b75mr17033893vsd.226.1549040312727;  Fri, 01 Feb 2019 08:58:32 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>  
In-Reply-To: 
From: Bernard Aboba 
Date: Fri, 1 Feb 2019 11:58:21 -0500
Message-ID: 
To: Richard Barnes 
Cc: Alexandre GOUAILLARD , Emad Omara ,  Emil Ivov , IETF discussion list , The IESG , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000953dd00580d80d16"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Feb 2019 16:58:38 -0000

--000000000000953dd00580d80d16
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Comments below.

On Fri, Feb 1, 2019 at 11:18 Richard Barnes  wrote:

>
>> I appreciate that there's confusion here, and I think we can clarify.
>
> It seems pretty clear from the other documents in this suite
> (draft-ietf-perc-srtp-ekt-diet and draft-ietf-perc-double) that this syst=
em
> only really makes sense in the case where the browser is trusted and the =
JS
> is not.
>

[BA] Does this depend on the origin of the JS and how it is delivered?
Development frameworks such as Electron are now quite popular for
delivering native applications. Are you saying that the framework
intrinsically distinguishes a native C/C++ application utilizing the WebRTC
APIs from one partially written in JS?

Seems to me that this Is really about access to media and keys, not
development methodology.

I would also note that DRM frameworks such as EME have their own key
management requirements and definition of =E2=80=9Ctrust=E2=80=9D rooted in=
 hardware such
as the TPM.

Otherwise, you would not need the DTLS parts of EKT, since you could rely
> on some external thing to provide the key encryption key.  (Note that thi=
s
> latter architecture was proposed, considered, and rejected by the WG.)
>

[BA] This is a framework document. As such, it needs to explain the
requirements for key management.


> 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)."
>

[BA] Given that WebRTC APIs are frequently used to develop native
applications, and that existing Web APIs such as EME support handling of
encrypted content, I do not think the above text is adequate. The document
actually needs to articulate the key management requirements.


> 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.
>
> I'll leave it to Paul to propose concrete fixes here, since I'm less
> familiar with these points.
>
> --Richard
>
>
>
>>
>> On Wed, Jan 30, 2019 at 7:45 PM The IESG  wrote=
:
>>
>>>
>>> The IESG has received a request from the Privacy Enhanced RTP
>>> Conferencing
>>> WG (perc) to consider the following document: - 'A Solution Framework f=
or
>>> Private Media in Privacy Enhanced RTP
>>>    Conferencing'
>>>    as Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final
>>> comments on this action. Please send substantive comments to the
>>> ietf@ietf.org mailing lists by 2019-02-13. Exceptionally, comments may
>>> be
>>> sent to iesg@ietf.org instead. In either case, please retain the
>>> beginning of
>>> the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>    This document describes a solution framework for ensuring that media
>>>    confidentiality and integrity are maintained end-to-end within the
>>>    context of a switched conferencing environment where media
>>>    distributors are not trusted with the end-to-end media encryption
>>>    keys.  The solution aims to build upon existing security mechanisms
>>>    defined for the real-time transport protocol (RTP).
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framewor=
k/
>>>
>>> IESG discussion can be tracked via
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framewor=
k/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Perc mailing list
>>> Perc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>>
>

--000000000000953dd00580d80d16
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Comments below.

On Fri, Feb 1, 2019 at 11:18 Richard Barnes <=
;rlb@ipv.sx> wrote:

=

I appreciate that there's confusion here, and I think =
we can clarify.

It seems pretty clear from the oth=
er documents in this suite (draft-ietf-perc-srtp-ekt-diet and draft-ietf-pe=
rc-double) that this system only really makes sense in the case where the b=
rowser is trusted and the JS is not.=C2=A0 
<=
div dir=3D"auto">
[BA] Does this depend on the o=
rigin of the JS and how it is delivered? Development frameworks such as Ele=
ctron are now quite popular for delivering native applications. Are you say=
ing that the framework intrinsically distinguishes a native C/C++ applicati=
on utilizing the WebRTC APIs from one partially written in JS?=C2=A0
<=
div dir=3D"auto">
Seems to me that this Is reall=
y about access to media and keys, not development methodology.

I would also note that DRM framework=
s such as EME have their own key management requirements and definition of =
=E2=80=9Ctrust=E2=80=9D rooted in hardware such as the TPM.=C2=A0

Otherwise, you would not need the DTLS parts o=
f EKT, since you could rely on some external thing to provide the key encry=
ption key.=C2=A0 (Note that this latter architecture was proposed, consider=
ed, and rejected by the WG.)

[BA] This is a framework document. As such, i=
t needs to explain the requirements for key management.=C2=A0


So I would propose we ad=
d 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 Tr=
usted Endpoint for purposes of this framework (just as it acts as the endpo=
int for DTLS-SRTP in one-to-one calls)."

[BA] Given that WebRTC APIs =
are frequently used to develop native applications, and that existing Web A=
PIs such as EME support handling of encrypted content, I do not think the a=
bove text is adequate. The document actually needs to articulate the key ma=
nagement requirements.=C2=A0


Again, the a=
nswer is clear here, but the document should be clearer.=C2=A0 The working =
group discussed SSRC rewriting several times, and concluded that SSRC rewri=
ting could not be allowed in this system.=C2=A0 This decision is reflected,=
 e.g., in the fact that the Double transform does not allow modification of=
 SSRCs.

I'll leave it to Paul to propose concr=
ete fixes here, since I'm less familiar with these points.
<=
/div>

--Rich=
ard

=C2=A0






On Wed, Jan 30, 2019 at 7:45 PM The IESG &l=
t;iesg-secreta=
ry@ietf.org> wrote:


The IESG has received a request from the Privacy Enhanced RTP Conferencing =


WG (perc) to consider the following document: - 'A Solution Framework f=
or

Private Media in Privacy Enhanced RTP

=C2=A0 =C2=A0Conferencing'

=C2=A0 <draft-ietf-perc-private-media-framework-08.txt> as Proposed S=
tandard



The IESG plans to make a decision in the next few weeks, and solicits final=


comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2019-02-13. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the beginning of

the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This document describes a solution framework for ensuring that=
 media

=C2=A0 =C2=A0confidentiality and integrity are maintained end-to-end within=
 the

=C2=A0 =C2=A0context of a switched conferencing environment where media

=C2=A0 =C2=A0distributors are not trusted with the end-to-end media encrypt=
ion

=C2=A0 =C2=A0keys.=C2=A0 The solution aims to build upon existing security =
mechanisms

=C2=A0 =C2=A0defined for the real-time transport protocol (RTP).









The file can be obtained via

https://datatracker.ietf.or=
g/doc/draft-ietf-perc-private-media-framework/



IESG discussion can be tracked via

https://datatracker.=
ietf.org/doc/draft-ietf-perc-private-media-framework/ballot/





No IPR declarations have been submitted directly on this I-D.









_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc



_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc






--000000000000953dd00580d80d16--


From nobody Fri Feb  1 09:23:45 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7A1310BA for ; Fri,  1 Feb 2019 09:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpCnijuFELF5 for ; Fri,  1 Feb 2019 09:23:42 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98391310C6 for ; Fri,  1 Feb 2019 09:23:41 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id q18so7903581wrx.9 for ; Fri, 01 Feb 2019 09:23:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Wu1Gs0EarI7FR4ltVAVLFoE34z1oSx0wC00UMuPjouA=; b=DKXXemCMaNybjXie2aaf/eTZ9AnEEjuLmXic8T5QeRI2Ofxm2idUIuD75XIJFthq08 vx4vARFzpUawRBTbzoKkymYocGCIiQRv/ufHg1WbHMSWvL+3h4uXFCQTqGopWezhjdn7 UlHnTlOl+pdvBy2AJH9LIjbhrt5kUhFZHi4l2yicfrEmrq+yuF6T++AFuWyevXL8GBoZ h3L/vk69s0qQffg4gam3wDP2fY3DmggpNSUV6rUeMzq83kOcXB25NtU5TJ2nXYusn6wH tA3pLutd+gHnZehqEofMmVhjuGbg7i2L00GDfXbid1AUwl4KBTt0IH6BFo1nBZTk3vB4 I/Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Wu1Gs0EarI7FR4ltVAVLFoE34z1oSx0wC00UMuPjouA=; b=WpLzlhZOPL2lErpl5b4A21bX+dDlw9mppR1U0wjH+kkNEth3Beg9LH7nktM8jmaBfy WmCvQrw+qGRo33EsnXtWuoi02z9apdotiR9idRqgogbnIlOgFl+Qe9+8jr8gfZqnTlcR K0iiOssaU6K0YaYu2iqbPW9RmP4dcdht3w9jaTbgyazZfAk07BHSQGs2mJL2pE/oI4TK x7/MiHDZ0X1NvzIl+NEhNAUOb5FEPdurQNVgtX4GFcO/Ow1QV04D7ef+XcBm9W6fjXbK QvnpvubDwHhDH5ukhpXqZ8yOHKDgZ8Fl0GFywvYxnrF9hsNqNd1rtqokIcEi80JWiu6L 77MQ==
X-Gm-Message-State: AJcUuke9cBUUsXrJUx6/lWucpTaZQOXk5EX1dYHoMjzZI9JVeAaGfU/a aeJT0SOGKJSkp6W5WGipvrquwlLG
X-Google-Smtp-Source: ALg8bN6Cu12mRGx6UAsOQ7Nw5zOtmfhadaxW8NPPIgPruKn/YSHn5tYPVK1pfKG5HvNQPPy9HUN11g==
X-Received: by 2002:adf:e64d:: with SMTP id b13mr40467755wrn.276.1549041819946;  Fri, 01 Feb 2019 09:23:39 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id w16sm9713335wrp.1.2019.02.01.09.23.38 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 09:23:39 -0800 (PST)
To: perc@ietf.org
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>  
From: Sergio Garcia Murillo 
Message-ID: <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>
Date: Fri, 1 Feb 2019 18:28:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------10CFD02282DD6F1E2D86CA45"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Feb 2019 17:23:44 -0000

This is a multi-part message in MIME format.
--------------10CFD02282DD6F1E2D86CA45
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------10CFD02282DD6F1E2D86CA45
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
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

    

  


--------------10CFD02282DD6F1E2D86CA45--


From nobody Fri Feb  1 22:21:47 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406E3131004; Fri,  1 Feb 2019 22:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyuep9SIGntm; Fri,  1 Feb 2019 22:21:36 -0800 (PST)
Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE34130EB8; Fri,  1 Feb 2019 22:21:35 -0800 (PST)
Received: by mail-vs1-xe44.google.com with SMTP id e7so5635298vsc.2; Fri, 01 Feb 2019 22:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ai/YcJt0LWdXIT8yWDm4mxXdQrSg1xd0TlM3HVjY3ZY=; b=Zj6k2DDrdTA2nzwDJj1fv1ogjWdOTS/A0ypxz+ber0bUCV0K6kuIPsjI+darH8txJA JT6/MVP0hiz5iGIamCrQM84RH2yWAEuZlbVCKN9AkmQD1KGcCPTWnDzs91O6JLbEo4NJ 6dEJAcFbjBOZkKAAlwnPIfvChQWjtMU4gVrws6fKGaGp9wexIob1bTr3e90WojJIuGmA Mvw3DMcit0r1CdZ8TwOBaAAXEXK5/pRouHHMCntekgq2lK0OtC/SzCkyjNv8toc8Ehkl dbtz/blkKt8gEDqT6Cpr9E7vEl10p0Od5CLRjhoQCU/8VObn/Q0VhYWE4fjVsoDQTDiO t65w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ai/YcJt0LWdXIT8yWDm4mxXdQrSg1xd0TlM3HVjY3ZY=; b=Kewm2iNPR+Bs3ypB2h0GbgPwA+sXPbsOG9SKjOXrpUnoQ6fFVyN6B4tkQdKM3a+VFC iFyfH+hYJAPIPPsa2jr+FZ8xiVJEmxBKSSADuimWLvgqrH6OV/duX88gTE9VoqNvtrHH nT6OoC1tNmfIp0MJIEA/ibrn42+DR0OjNyKSbL1eYhD2nk89b1KRK3iDWD/0+vp/SmEg W5/QX3867Q1rAwM/WSBWj7zt+dduSCS99MiXSTGF42Gj3+IRiapysbIRCAEjq0qQMK8W G90PIwK00uuDZf2FbketM852W5RPrZssnJn8z3SlrYma/mxxPjNlZHndNaiXSblRwF1X +49A==
X-Gm-Message-State: AJcUukfMb4+Q8hHRlT+Lv7dqbcpGOV4X7F9NdRUUVdWO+iSHRppEwEoQ JwR42NRzMMTr+mRSfVuZJ5JtDgXuv3T1CrEu55eAL2yN
X-Google-Smtp-Source: ALg8bN4zJ9eR8jepAA+PL67SnESxW6HBHTAlC6iVf6D5oG43ew5j+KSY4VjGu7qaQ7LT2Imtcr8B4d/h6URj/ehORB0=
X-Received: by 2002:a67:de97:: with SMTP id r23mr18178193vsk.127.1549088494438;  Fri, 01 Feb 2019 22:21:34 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>
In-Reply-To: <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>
From: Bernard Aboba 
Date: Sat, 2 Feb 2019 01:29:08 -0500
Message-ID: 
To: perc@ietf.org, IETF discussion list 
Cc: Emad Omara ,  Sergio Garcia Murillo , Emil Ivov , "hta@google.com" , Alexandre GOUAILLARD 
Content-Type: multipart/alternative; boundary="0000000000006fd0fe0580e34585"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 06:21:38 -0000

--0000000000006fd0fe0580e34585
Content-Type: text/plain; charset="UTF-8"

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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>

--0000000000006fd0fe0580e34585
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Richard said:

"Again, the answer is clear here, but the document should be=
 clearer.=C2=A0 The working group discussed SSRC rewriting several times, a=
nd concluded that SSRC rewriting could not be allowed in this system.=C2=A0=
 This decision is reflected, e.g., in the fact that the Double transform do=
es not allow modification of SSRCs."

[=
BA]=C2=A0 Not being able to rewrite SSRCs has some major implications with =
respect to requirements on PERC endpoints.=C2=A0 Typically today's MDD =
will switch between the simulcast streams provided by an endpoint, forwardi=
ng only a single stream to other participants, based on the bandwidth, reso=
lution and framerates.=C2=A0 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?=
=C2=A0 For example, should endpoints expect the MDD to use RID header exten=
sions to identify the incoming simulcast streams?=C2=A0

Receiving of simulcast is tricky because the endpoint is receiving mu=
ltiple streams with different sequence number spaces which may contain hole=
s because of reordering or loss. This not only complicates the application =
of RTX, RED and FEC, but also the operation of the endpoint.=C2=A0 As a res=
ult, as noted in the WEBRTC specification Section 5.4.1, support for recept=
ion of simulcast is optional. I am aware of two ORTC implementations that h=
ave attempted to support simulcast reception, neither of which is robust in=
 scenarios with considerable loss and/or reordering.=C2=A0 And neither impl=
ementation supports the RID header extension on received simulcast streams.=





On Fri, Feb 1, 2019 at 1=
2:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

 =20
   =20
 =20
  

    
On 01/02/201=
9 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<=
/a> 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@ietf.org

https://www.ietf.org/mailman/listinfo/perc




--0000000000006fd0fe0580e34585--


From nobody Sat Feb  2 01:19:29 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D9B12872C for ; Sat,  2 Feb 2019 01:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR14AVQRuhOu for ; Sat,  2 Feb 2019 01:19:19 -0800 (PST)
Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FE61277BB for ; Sat,  2 Feb 2019 01:19:19 -0800 (PST)
Received: by mail-ua1-x941.google.com with SMTP id p9so3012028uaa.5 for ; Sat, 02 Feb 2019 01:19:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vBBXrfau2o2oIk0QdV2xwS+1EDHO857aP/9qM+dHMYs=; b=1F+VgbRtT4/noNXgIBuJ4HeBBpRaOkFRfWs5UQG2+QicxPnmwdSBBGQr11meUcCpp0 pAp/BLv59texlL0o+HzaLRB84Lj9+lbdnukw6IrjdGUUWVt1dPK71gYheta1QQ0UTVXS MWAixUHPzr/gaU2tjbpaPRLjo/qnS0olMeyoSl4NdwGwUT6iDnB0GGtQfY3G/fcreDy9 4CX4cNgDPHAO47xDSY19n7v3Zsgo8m6XDho1n6mNY/h8qTBJavY8fNjxur0rOQMEgt/V nmSXUG/ZSA23lmEkf9BwfDTChQYqN19+M5wBxINfeEEakhvA8ySZisn7niWo8wOEhjGY lG4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vBBXrfau2o2oIk0QdV2xwS+1EDHO857aP/9qM+dHMYs=; b=TNESHdz3lfIS14mL4kw2agKU97D8LTOTj6uXRAFcZDSnsCd9h2S/j5ineANb+oBC+o soAzrwnHljmu3ta+oRtAqV7/OqfoFs/neLnRx5/1BU/n6cV89dQOfARXCrv3lxJBSulM YOxLS3SRitZScwpm2oav2pBJuIgwFVjuAmLLEGr820L/O4BAG8Tff2wILOBlBiWG/sSn mOIzHrJWWh88A+T0JCktdz3dur2h8iQCqD21DlzDz5VbMNVo9dDUlK4rKH0zPj06vCv/ 9iLQJWug9I3yCm5Lmv47xfdkUTCj5xi3+0gleH9hM73PBIYPETz2g6GNwyEYivowv2/M rPmQ==
X-Gm-Message-State: AJcUukfzU7cYXlsHosijvExtz8it9/+rDC7rqlT+G4N7JogtavK7pZFU sVJcQanWX84GfKAFqSmPuGKBBrA0fGrHMea/eCf2sg==
X-Google-Smtp-Source: ALg8bN6ATeKYKklC/ZcJ2yHMTFqCnBViub2ugYfotRIg34ZdWu/vCGKFJzpYfe3DMsYuCOG6lQD5BKmdGvSIKLd/0Qw=
X-Received: by 2002:a9f:2b44:: with SMTP id q4mr17207346uaj.126.1549099158043;  Sat, 02 Feb 2019 01:19:18 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com> 
In-Reply-To: 
From: Emil Ivov 
Date: Sat, 2 Feb 2019 09:19:06 +0000
Message-ID: 
To: Bernard Aboba 
Cc: Alexandre GOUAILLARD , Emad Omara , IETF discussion list ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000009a0550580e5c11a"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 09:19:23 -0000

--00000000000009a0550580e5c11a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=9CSSRC rewriting could not be a=
llowed=E2=80=9D
is a conclusion that ever had any consensus in PERC, regardless of what WG
leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba  wrote:

> 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 i=
s
> 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 PER=
C
> 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, neith=
er
> 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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
>> 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-1=
7
>> 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#encr=
yption
>>
>> Best regards
>>
>> Sergio
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>>
> --
sent from my mobile

--00000000000009a0550580e5c11a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.aboba@gmail.com=
> wrote:
Richar=
d said:

"Again, =
the answer is clear here, but the document should be clearer.=C2=A0 The wor=
king group discussed SSRC rewriting several times, and concluded that SSRC =
rewriting could not be allowed in this system.=C2=A0 This decision is refle=
cted, e.g., in the fact that the Double transform does not allow modificati=
on of SSRCs."

[BA]=C2=A0 Not being abl=
e to rewrite SSRCs has some major implications with respect to requirements=
 on PERC endpoints.=C2=A0 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.=
=C2=A0 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?=C2=A0 For example, shou=
ld endpoints expect the MDD to use RID header extensions to identify the in=
coming simulcast streams?=C2=A0

Receiving of simul=
cast is tricky because the endpoint is receiving multiple streams with diff=
erent 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.=C2=A0 As a result, as noted in the WEB=
RTC specification Section 5.4.1, support for reception of simulcast is opti=
onal. I am aware of two ORTC implementations that have attempted to support=
 simulcast reception, neither of which is robust in scenarios with consider=
able loss and/or reordering.=C2=A0 And neither implementation supports the =
RID header extension on received simulcast streams.




On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Mu=
rillo <sergio.garcia.murillo@gmail.com> wrote:

 =20
   =20
 =20
  

    
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-rtcwe=
b-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/med=
ia-capabilities/blob/master/explainer.md#encryption

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile


--00000000000009a0550580e5c11a--


From nobody Sat Feb  2 02:18:25 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1210512DF71 for ; Sat,  2 Feb 2019 02:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csYa5N49EUiD for ; Sat,  2 Feb 2019 02:18:20 -0800 (PST)
Received: from smtpcmd0871.aruba.it (smtpcmd0871.aruba.it [62.149.156.71]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9D12896A for ; Sat,  2 Feb 2019 02:18:19 -0800 (PST)
Received: from [10.26.217.52] ([176.200.163.100]) by smtpcmd08.ad.aruba.it with bizsmtp id XmJG1z00J2AGvNQ01mJGiA; Sat, 02 Feb 2019 11:18:17 +0100
Date: Sat, 02 Feb 2019 11:18:15 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>  
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----6RM9CLM5C75SWHUL47OUVJM53C4XYO"
Content-Transfer-Encoding: 7bit
To: perc@ietf.org, Emil Ivov , Bernard Aboba 
CC: Alexandre GOUAILLARD , IETF discussion list , Emad Omara , "hta@google.com" , Sergio Garcia Murillo 
From: Lorenzo Miniero 
Message-ID: <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1549102697; bh=pWO6W7+Tv+OsRK7cyrtx4ZEs5oR/WsXXkt37gnsrJkM=; h=Date:MIME-Version:Content-Type:Subject:To:From; b=Nt2eCpxi7jaRgJWJ+Jc8e4EzP/MkMTg89lx3k7+tzMr34gP/UE3Jv4zpB+jk3GXpX +IUpAiBSeebbqsfwGyFqAfBNjD6SQ0p/BIr/9dSdAdiryTmHrZOaefxcBXR+tUa/Fc OGYY/FYe6SIsQtgeQoSu9ROUZj6pwvQD8dyQdeTU3oilFCSHUWHl0CJYfPQT+N3BKo RgC3nMHag3/rlnV026U2BPtsgt4tJabkP+C3CA4EZMFji5KCYdvEauFR8CAV9dutSr J4l7p97s6tFTZBOssj8DWl7x9TBqBkE6eQGYvxspe3clt9PUozDItrEBwIQhFAvVi0 Kb67gvPhrU0rA==
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 10:18:24 -0000

------6RM9CLM5C75SWHUL47OUVJM53C4XYO
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1, SSRC rewriting is pretty much fundamental to all SFUs out there=2E

Lorenzo

Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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=2E
>
>I am also not sure that I agree with =E2=80=9CSSRC rewriting could not be
>allowed=E2=80=9D
>is a conclusion that ever had any consensus in PERC, regardless of what
>WG
>leadership is trying to make everyone believe=2E
>
>On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>wrote:
>
>> Richard said:
>>
>> "Again, the answer is clear here, but the document should be clearer=2E
>> The working group discussed SSRC rewriting several times, and
>concluded
>> that SSRC rewriting could not be allowed in this system=2E  This
>decision is
>> reflected, e=2Eg=2E, in the fact that the Double transform does not all=
ow
>> modification of SSRCs=2E"
>>
>> [BA]  Not being able to rewrite SSRCs has some major implications
>with
>> respect to requirements on PERC endpoints=2E  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=2E  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=2E This not only complicates the
>> application of RTX, RED and FEC, but also the operation of the
>endpoint=2E
>> As a result, as noted in the WEBRTC specification Section 5=2E4=2E1,
>support
>> for reception of simulcast is optional=2E 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=2E
>> And neither implementation supports the RID header extension on
>received
>> simulcast streams=2E
>>
>>
>>
>>
>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>> sergio=2Egarcia=2Emurillo@gmail=2Ecom> wrote:
>>
>>> 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)=2E
>>>
>>>
>>> If we decide to adopt perc (big if) in webrtc, shouldn't this be
>defined
>>> within the
>https://tools=2Eietf=2Eorg/html/draft-ietf-rtcweb-security-arch-17
>>> doc ?
>>>
>>>
>>>    Optimally, we would not rely on trust in any entities other than
>the
>>>    browser=2E  However, this is unfortunately not possible if we wish
>to
>>>    have a functional system=2E  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=2E
>>>
>>>
>>> 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=2E 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=2Ecom/WICG/media-capabilities/blob/master/explainer=2Emd#e=
ncryption
>>>
>>> Best regards
>>>
>>> Sergio
>>> _______________________________________________
>>> Perc mailing list
>>> Perc@ietf=2Eorg
>>> https://www=2Eietf=2Eorg/mailman/listinfo/perc
>>>
>> --
>sent from my mobile

--=20
Inviato dal mio dispositivo Android con K-9 Mail=2E Perdonate la brevit=C3=
=A0=2E
------6RM9CLM5C75SWHUL47OUVJM53C4XYO
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1, SSRC rewriting is pretty much fundamental to a=
ll SFUs out there=2E

Lorenzo

Il 2 =
febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi=2Eorg> ha scritto:=



I want to second that as it is a particularly major=
 problem: not allowing SSRC rewriting makes the entire framework unusable w=
ith SFU implementation I represent as well as every other SFU I am familiar=
 with=2E

I am also=
 not sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=
=80=9D is a conclusion that ever had any consensus in PERC, regardless of w=
hat WG leadership is trying to make everyone believe=2E

On Sat 2 Feb 2019 at 06:21, Bernard =
Aboba <bernard=2Eaboba@gm=
ail=2Ecom> wrote:
Richard said:

"Again, the answer is clear here, but the document should be clearer=2E=
  The working group discussed SSRC rewriting several times, and conclu=
ded that SSRC rewriting could not be allowed in this system=2E  This d=
ecision is reflected, e=2Eg=2E, in the fact that the Double transform does =
not allow modification of SSRCs=2E"

[BA]&nb=
sp; Not being able to rewrite SSRCs has some major implications with respec=
t to requirements on PERC endpoints=2E  Typically today's MDD will swi=
tch between the simulcast streams provided by an endpoint, forwarding only =
a single stream to other participants, based on the bandwidth, resolution a=
nd framerates=2E  If rewriting of SSRCs is not possible, do PERC endpo=
ints need to be able to receive simulcast? If PERC endpoints do need to be =
able to receive simulcast, what are the requirements for endpoints?  F=
or example, should endpoints expect the MDD to use RID header extensions to=
 identify the incoming simulcast streams? 

Re=
ceiving of simulcast is tricky because the endpoint is receiving multiple s=
treams with different sequence number spaces which may contain holes becaus=
e of reordering or loss=2E This not only complicates the application of RTX=
, RED and FEC, but also the operation of the endpoint=2E  As a result,=
 as noted in the WEBRTC specification Section 5=2E4=2E1, support for recept=
ion of simulcast is optional=2E 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=2E  And neither =
implementation supports the RID header extension on received simulcast stre=
ams=2E




On Fri, Feb 1, 201=
9 at 12:23 PM Sergio Garcia Murillo <sergio=2Egarcia=2Emurillo@gmail=
=2Ecom> wrote:

 =20
   =20
 =20
  

    
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)=2E

    

    


    

    
If we decide to adopt perc (big if) in webrtc, shouldn't this be
      defined within the
      https://tools=2Eietf=2Eorg/html/draft-i=
etf-rtcweb-security-arch-17 doc
      ?

    

    


    

    
   Optimally, we would not rely=
 on trust in any entities other than the
   browser=2E  However, this is unfortunately not possible if we wish to
   have a functional system=2E  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=2E


    


    

    
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=2E 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=2Ecom/W=
ICG/media-capabilities/blob/master/explainer=2Emd#encryption

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/perc



-- 
sent from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 =
Mail=2E Perdonate la brevit=C3=A0=2E
------6RM9CLM5C75SWHUL47OUVJM53C4XYO--


From nobody Sat Feb  2 02:41:02 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318E5130E2E for ; Sat,  2 Feb 2019 02:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Level: 
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cosmosoftware-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq05pcfWgQwL for ; Sat,  2 Feb 2019 02:40:58 -0800 (PST)
Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583DD130DEF for ; Sat,  2 Feb 2019 02:40:58 -0800 (PST)
Received: by mail-pl1-x644.google.com with SMTP id g9so4573357plo.3 for ; Sat, 02 Feb 2019 02:40:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1C2+8bEtbX2Ka7l0cjNCJ/HCivx/pjm/MtVFuB7hmbw=; b=1zjFgpdqNuTgmvQ/Z7KArgiUdVVjcnGJk/gYIOaxmZbu6r1amiQMtuc8uGKo6XMrU4 Mr6VUEbGdVRImIClNxxiVC5u+srCsnC+q5qo2KBvLUOnv/9359WKeENJ3s7I5zEpNUdQ zypxd/4OKVVOAQxIuOG2HLNKQHgnTH9r2eAEuyk1QnFxMjI+yH1eKCpQ6rHW01VQPzUX Nno66CW2YByg/3h57b/ewPeljhgQCOENWVvj8tia1TwgOnd1bjTqIIv6fvM+lOJ9Pgzm +NmKYRAikxLclIrfCzKXNo3okQ/drxxPi6FwP63yTv8Otq2AzAnfTOIAaSo6Pv9sjhBP A1Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1C2+8bEtbX2Ka7l0cjNCJ/HCivx/pjm/MtVFuB7hmbw=; b=slJm8Jd3XqNxyOHdurVz+rJhBndK/UQ+QDCL2Q+dH4x+r+w3Cf8ewqrWd/a6B6hKPj eyRaV0BNZfTczuZgXcTOmiN1HIDhE18ltt3m5FSu3RYC989M3uDvGbGy0kzDWbBUjIQX CgNjQRigDxLZlhK7gAsboGVw2MmdpNs2pANy+lbuJZFnL8v4nnroNRn48ONroD6GYoYf V3rkG6hOOoI87Pqar/7U7Hq5YdsO9UQ/85PvuDjItMInfueRPv4qxtRg0y7d+0aZCRKh 3WXMvjJxFzWUDamOWe1ojCq40FTumuQmiKE1iBlGZzwMLY+3EnJQEc5Llgi9kz1wBxrN y38Q==
X-Gm-Message-State: AJcUukfTo7A2gvdK3Az3TR+9r4EPCuD98LfBGymgRwyp8ycIHs0D6teW vO5sUBY/e/ZKAGjUZzSH2fJn/A==
X-Google-Smtp-Source: ALg8bN5Xt31xRSmYnf/AOrMI4c/JQ7ontwX3stntFGrqcUoWSyZhiWsFm+f/SDhOiE2RU4UtvT8n8Q==
X-Received: by 2002:a17:902:2ec1:: with SMTP id r59mr44058510plb.254.1549104057669;  Sat, 02 Feb 2019 02:40:57 -0800 (PST)
Received: from [10.113.46.93] ([183.90.36.51]) by smtp.gmail.com with ESMTPSA id f67sm18098359pff.29.2019.02.02.02.40.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 02:40:56 -0800 (PST)
From: Alexandre GOUAILLARD 
X-Google-Original-From: Alexandre GOUAILLARD 
Content-Type: multipart/alternative; boundary=Apple-Mail-94EE7229-6067-4173-958A-DC2DB5C6A6AA
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (16C101)
In-Reply-To: <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>
Date: Sat, 2 Feb 2019 17:40:54 +0700
Cc: perc@ietf.org, Emil Ivov , Bernard Aboba , IETF discussion list , Emad Omara , "hta@google.com" , Sergio Garcia Murillo 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>
To: Lorenzo Miniero 
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 10:41:01 -0000

--Apple-Mail-94EE7229-6067-4173-958A-DC2DB5C6A6AA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 on ssrc rewriting, and on the consensus not reached on this and other top=
ics.

Sent from my iPhone

> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote:
>=20
> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>=20
> Lorenzo
>=20
> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  ha scritto:
>>=20
>> 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.
>>=20
>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could not be=
 allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, regar=
dless of what WG leadership is trying to make everyone believe.
>>=20
>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba  wrot=
e:
>>> Richard said:
>>>=20
>>> "Again, the answer is clear here, but the document should be clearer.  T=
he working group discussed SSRC rewriting several times, and concluded that S=
SRC rewriting could not be allowed in this system.  This decision is reflect=
ed, e.g., in the fact that the Double transform does not allow modification o=
f SSRCs."
>>>=20
>>> [BA]  Not being able to rewrite SSRCs has some major implications with r=
espect to requirements on PERC endpoints.  Typically today's MDD will switch=
 between the simulcast streams provided by an endpoint, forwarding only a si=
ngle stream to other participants, based on the bandwidth, resolution and fr=
amerates.  If rewriting of SSRCs is not possible, do PERC endpoints need to b=
e able to receive simulcast? If PERC endpoints do need to be able to receive=
 simulcast, what are the requirements for endpoints?  For example, should en=
dpoints expect the MDD to use RID header extensions to identify the incoming=
 simulcast streams?=20
>>>=20
>>> Receiving of simulcast is tricky because the endpoint is receiving multi=
ple streams with different sequence number spaces which may contain holes be=
cause of reordering or loss. This not only complicates the application of RT=
X, RED and FEC, but also the operation of the endpoint.  As a result, as not=
ed in the WEBRTC specification Section 5.4.1, support for reception of simul=
cast is optional. I am aware of two ORTC implementations that have attempted=
 to support simulcast reception, neither of which is robust in scenarios wit=
h considerable loss and/or reordering.  And neither implementation supports t=
he RID header extension on received simulcast streams.
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo  wrote:
>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>> So I would propose we add something like the following to this definit=
ion:=20
>>>>>=20
>>>>> "In the context of WebRTC, where control of a session is divided betwe=
en a JavaScript application and a browser, the browser acts as the Trusted E=
ndpoint for purposes of this framework (just as it acts as the endpoint for D=
TLS-SRTP in one-to-one calls).
>>>>=20
>>>> If we decide to adopt perc (big if) in webrtc, shouldn't this be define=
d within the https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17 d=
oc ?
>>>>=20
>>>>=20
>>>>=20
>>>>    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.
>>>>=20
>>>>=20
>>>> 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 man=
agement solutions trusted (even in JS or WASM), as for for example is being d=
one in EME:
>>>>=20
>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#enc=
ryption
>>>>=20
>>>> Best regards
>>>>=20
>>>> Sergio
>>>>=20
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/perc
>> --=20
>> sent from my mobile
>=20
> --=20
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=C3=A0=
.

--Apple-Mail-94EE7229-6067-4173-958A-DC2DB5C6A6AA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 on ssrc rewriting, and on the consensus n=
ot reached on this and other topics.

Sent from my iPhone

On 2 Feb 2019, at 1=
7:18, Lorenzo Miniero <lorenzo@me=
etecho.com> wrote:

+1, SSRC rewriting is pretty much fundamental to all SFUs out there.
Lorenzo

Il 2 febbraio 2019 10:19:06 C=
ET, Emil Ivov <emcho@jitsi.org>=
 ha scritto:


I want to second that as it is a particularly major p=
roblem: not allowing SSRC rewriting makes the entire framework unusable with=
 SFU implementation I represent as well as every other SFU I am familiar wit=
h.

I am also not su=
re that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=9D i=
s a conclusion that ever had any consensus in PERC, regardless of what WG le=
adership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba <bernard.aboba@gmail.com> wrote=
:
Richard said:
=

"Again, the answer is clea=
r here, but the document should be clearer.  The working group discusse=
d SSRC rewriting several times, and concluded that SSRC rewriting could not b=
e allowed in this system.  This decision is reflected, e.g., in the fac=
t that the Double transform does not allow modification of SSRCs."

[BA]  Not being able to rewrite SSRCs has some m=
ajor implications with respect to requirements on PERC endpoints.  Typi=
cally today's MDD will switch between the simulcast streams provided by an e=
ndpoint, forwarding only a single stream to other participants, based on the=
 bandwidth, resolution and framerates.  If rewriting of SSRCs is not po=
ssible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements for=
 endpoints?  For example, should endpoints expect the MDD to use RID he=
ader extensions to identify the incoming simulcast streams? 
=

Receiving of simulcast is tricky because the endpoint is rece=
iving multiple streams with different sequence number spaces which may conta=
in holes because of reordering or loss. This not only complicates the applic=
ation 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 rec=
eption of simulcast is optional. I am aware of two ORTC implementations that=
 have attempted to support simulcast reception, neither of which is robust i=
n scenarios with considerable loss and/or reordering.  And neither impl=
ementation supports the RID header extension on received simulcast streams.<=
/div>




On Fri, Feb 1, 2019 at 12:2=
3 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

 =20
   =20
 =20
  

    
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-s=
ecurity-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@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 Ma=
il. Perdonate la brevit=C3=A0.
=

--Apple-Mail-94EE7229-6067-4173-958A-DC2DB5C6A6AA--


From nobody Sat Feb  2 04:23:10 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7272C130D7A; Sat,  2 Feb 2019 04:23:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRFQQYUAib6F; Sat,  2 Feb 2019 04:23:01 -0800 (PST)
Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BA5128D09; Sat,  2 Feb 2019 04:23:00 -0800 (PST)
Received: by mail-vs1-xe44.google.com with SMTP id b74so5875803vsd.9; Sat, 02 Feb 2019 04:23:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gjTH32OsRrcPNw8iyMjBN+pwOiOGbpJoKVG8aOGgdT0=; b=TaSeKtIf5Q6FRn90GFqKA+qMF+B104cL3v0ePf0MPrGSD71pqYv5dAVnK+JZEx540p w/7Z0uycjwEMJwgl9PKneU8+Ud9Yokir60MXApjTx57RtYwbcDyq+QDCaFkzOqOkP7LH hKnWKG/aThJNk8kn0j7sP/aciS0oLw4xn7pJ9Y0ws3I4+STiKV1loJboXL86hCxO28PP 0nbQxumcVzl6tF39GvR3+jLe4nRqTtmyLiUUHmy0Gic4Z1PCnGPB0+w681mxH+aPoXAw CL9y8DojQKm8pOY37bGGy5ZOgDJeCR4I/fINm85cuTK/8WUYI1VZAnWyfOm9YkJJald9 9ZLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gjTH32OsRrcPNw8iyMjBN+pwOiOGbpJoKVG8aOGgdT0=; b=b3kYoJYvKkVmQsUdT5w5WXJh4Vkw9XTxyFy1Tbun6Me5twDqsS4Kfr3veWvxUaL2QA 1eKUOsSkWZx/Ldb2hajDo/zWJE0U5ROkt8BEP9oQqKjoZoKX5UzRRNK+H8JETKKgd78T U/LAun8ZQLDqu1RnAoC/OGyOojFfiexI0bwy1SrPuzErwIinRHGs7Wm4Ys4W8VoFtBru TPau9eAMPafnpK3bgpP6UqKi91nete8xM07j9jBtZCYGAb41zR12M4ADvDfir+RqCzp5 g0XqUgA/AsFCaBrH/nvN3TTEMaW1BFJUitBZuXrCnlU1HEMyh/uxTjkJn8+Y31BqFLoH piIg==
X-Gm-Message-State: AJcUukfRU0JtDfDF+cmU+liU+6Q3UkcSsD6tynzvC97pjpMt0PvVbAC3 QlgQv2vh/ko9865+D5OlEfL70jWL+OuyO0xszMM=
X-Google-Smtp-Source: ALg8bN5C583Q2oTafNze+j+MVFD1OVS+ym6twPiA85ApEqEU/Hjc/6EdvJvOhL+Hi8wR8HJjzF03Fi/2kYXdL6ciXk4=
X-Received: by 2002:a67:42c7:: with SMTP id p190mr19620539vsa.82.1549110179138;  Sat, 02 Feb 2019 04:22:59 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com> 
In-Reply-To: 
From: Bernard Aboba 
Date: Sat, 2 Feb 2019 07:30:33 -0500
Message-ID: 
To: Alexandre GOUAILLARD 
Cc: Lorenzo Miniero , perc@ietf.org, Emil Ivov ,  IETF discussion list , Emad Omara , "hta@google.com" ,  Sergio Garcia Murillo 
Content-Type: multipart/alternative; boundary="000000000000f216040580e8518f"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 12:23:04 -0000

--000000000000f216040580e8518f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

"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?

On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
alex.gouaillard@cosmosoftware.io> wrote:

> +1 on ssrc rewriting, and on the consensus not reached on this and other
> topics.
>
> Sent from my iPhone
>
> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote:
>
> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>
> Lorenzo
>
> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  ha scritto:
>>
>> I want to second that as it is a particularly major problem: not allowin=
g
>> SSRC rewriting makes the entire framework unusable with SFU implementati=
on
>> I represent as well as every other SFU I am familiar with.
>>
>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could not b=
e
>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, re=
gardless of
>> what WG leadership is trying to make everyone believe.
>>
>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>> wrote:
>>
>>> 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, forwardin=
g
>>> only a single stream to other participants, based on the bandwidth,
>>> resolution and framerates.  If rewriting of SSRCs is not possible, do P=
ERC
>>> endpoints need to be able to receive simulcast? If PERC endpoints do ne=
ed
>>> to be able to receive simulcast, what are the requirements for endpoint=
s?
>>> For example, should endpoints expect the MDD to use RID header extensio=
ns
>>> 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 contai=
n
>>> 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, suppor=
t
>>> for reception of simulcast is optional. I am aware of two ORTC
>>> implementations that have attempted to support simulcast reception, nei=
ther
>>> of which is robust in scenarios with considerable loss and/or reorderin=
g.
>>> And neither implementation supports the RID header extension on receive=
d
>>> simulcast streams.
>>>
>>>
>>>
>>>
>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>> sergio.garcia.murillo@gmail.com> wrote:
>>>
>>>> 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 th=
e
>>>> Trusted Endpoint for purposes of this framework (just as it acts as th=
e
>>>> 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 th=
e
>>>>    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 thu=
s
>>>>    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 u=
p
>>>> to the RTCWEB group to decide what is a trusted endpoint and what is n=
ot in
>>>> webrtc. As Bernard is stating, we could decide that there are other ke=
y
>>>> 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#en=
cryption
>>>>
>>>> Best regards
>>>>
>>>> Sergio
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>
>>> --
>> sent from my mobile
>>
>
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=C3=
=A0.
>
>

--000000000000f216040580e8518f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


"on the consensus not reached on this and other topic=
s."

[BA] Out of curiosity, what other topics do you=
 consider to be problematic within the framework?=C2=A0 I am aware of at le=
ast two others where implementers have chosen different paths than in the P=
ERC framework:

* Order of application of encryptio=
n versus FEC/RTX/RED
* Whole frame encryption versus payload encr=
yption

With respect to consensus, this is IETF las=
t call, one of whose purposes is to determine whether there is IETF consens=
us to publish this document as a Proposed Standard.=C2=A0 Are you saying th=
at you do not agree that there is an IETF consensus to publish this documen=
t as a Proposed Standard?=C2=A0 Or that there is no IETF consensus to publi=
sh *any* of the PERC WG output as a Proposed Standard?=C2=A0
On Sat, F=
eb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io> wrote:
=

+=
1 on ssrc rewriting, and on the consensus not reached on this and other top=
ics.

Sent from my iPhone

On 2 Feb 2019, at 17=
:18, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

+1, SSRC rewriting is pretty much fundamental to=
 all SFUs out there.

Lorenzo

Il 2 =
febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org> ha scritto:


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here, but the docu=
ment should be clearer.=C2=A0 The working group discussed SSRC rewriting se=
veral times, and concluded that SSRC rewriting could not be allowed in this=
 system.=C2=A0 This decision is reflected, e.g., in the fact that the Doubl=
e transform does not allow modification of SSRCs."
[BA]=C2=A0 Not being able to rewrite SSRCs has some major impl=
ications with respect to requirements on PERC endpoints.=C2=A0 Typically to=
day's MDD will switch between the simulcast streams provided by an endp=
oint, forwarding only a single stream to other participants, based on the b=
andwidth, resolution and framerates.=C2=A0 If rewriting of SSRCs is not pos=
sible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements fo=
r endpoints?=C2=A0 For example, should endpoints expect the MDD to use RID =
header extensions to identify the incoming simulcast streams?=C2=A0

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.=C2=
=A0 As a result, as noted in the WEBRTC specification Section 5.4.1, suppor=
t for reception of simulcast is optional. I am aware of two ORTC implementa=
tions that have attempted to support simulcast reception, neither of which =
is robust in scenarios with considerable loss and/or reordering.=C2=A0 And =
neither implementation supports the RID header extension on received simulc=
ast streams.




On Fri, Feb =
1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com=
> wrote:

 =20
   =20
 =20
  

    
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.ie=
tf.org/html/draft-ietf-rtcweb-security-arch-17 doc
      ?

    

    


    

    
   Opt=
imally, 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#encryp=
tion

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 M=
ail. Perdonate la brevit=C3=A0.


--000000000000f216040580e8518f--


From nobody Sat Feb  2 04:51:17 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E540130DEF; Sat,  2 Feb 2019 04:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME894gzj6U0l; Sat,  2 Feb 2019 04:51:06 -0800 (PST)
Received: from mail-vk1-xa42.google.com (mail-vk1-xa42.google.com [IPv6:2607:f8b0:4864:20::a42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9239128D09; Sat,  2 Feb 2019 04:51:05 -0800 (PST)
Received: by mail-vk1-xa42.google.com with SMTP id y14so2243463vkd.1; Sat, 02 Feb 2019 04:51:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iKufF17BUQNj9rN4Z8rYz7haZzn3+Ei3EifdXOO0Hjo=; b=h/5hKegAxoUs2YAhDKjDfrfL/o6jzSW8w3KzUCrnE4ApFh8G4LJdKUTn7Us49e82EC qjrUS0PhEJKGyvTnQlHRZ8wN0UK9RIOR4cdBW8MP7OVAZQnF5txsemgY78GHhzogVmrq 3lgE3SZXdsbDA+If+qXxxf/KdQ2WXv7idiX4dZaR23lrLN1jQXE+9vgrY4wfvyfc3ZyA jaYrrU4Q53fAwg7pH17rSzuAMnipAYGMycoOKWHZISkcY0EGZgew/qa5+qNa/jVKuSBp 21ib8kzOgi/mGWS6FT5xUNtwlAi96ADEX5zAVinKhOYdjeZv+2pBrx6fMHHGHFVO+2CV Y5vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iKufF17BUQNj9rN4Z8rYz7haZzn3+Ei3EifdXOO0Hjo=; b=IlABQS2cPuqoVjvbt+vTVAm1YhGmIo2KCBgyp/oDdFVk5HzvCVWyl9lVyAHI5iGygR KqT4XVQP4PkZoYYwzrdO9jCvglDchqmRJCDaradfoUaiTQm2YcGZisAqTfhIOOT0pdQQ gbDCT89f86OTmLTFgwVAr/VuY5fc3Qym0/Q8zhjZ9XDQQBRre91ieXjIneOtQP7Ae/bu R4S4o4p3zWChZt3QC6QIdKnj16To35m0WepKkSmZgltrTHgR7lbfFOkSV2SOOgx0O5d9 nMYLH012e1WpzUMn854kgyLjKXkavQ46GpYrpvfjUBV2A54REWQBquyV5UItdl0mI9cG o9VQ==
X-Gm-Message-State: AJcUuke1vG5UTFSAhX0u5TgryjlgqDSPU3TagRPdyLPmsmk3hXM0GIMz n0quTUIt9SkssmSNn6OvIrW/XOMR8/dmfBcRy/s=
X-Google-Smtp-Source: ALg8bN49nAgQVC4HlMeBLO42AouEkJ9eKXWo+kshVQjaa0SJwphgzfbwwPZSWe4ReZbFQjJblTMsGt3ODiRkH/YOWlg=
X-Received: by 2002:a1f:944f:: with SMTP id w76mr17763755vkd.77.1549111864569;  Sat, 02 Feb 2019 04:51:04 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>  
In-Reply-To: 
From: Bernard Aboba 
Date: Sat, 2 Feb 2019 07:58:38 -0500
Message-ID: 
To: Emil Ivov 
Cc: Alexandre GOUAILLARD , Emad Omara , IETF discussion list ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000067b57b0580e8b604"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 12:51:09 -0000

--00000000000067b57b0580e8b604
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Emil said:

"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."

[BA] Can you articulate why you consider SSRC rewriting essential to SFU
operation?

I can think of one scenario where SSRC rewriting does seem to be *required*
-  Massive Online Courses (MOOCs). In these scenarios, there can be
hundreds or even thousands of students, most of whom never speak during
class, and teachers, who send media frequently.  MOOCs can be implemented
via streaming media instead of RTP, but this complicates the interactive
aspect.

So there are implementations of MOOCs that use RTP, and I believe that SSRC
rewriting is an important part of the design of these systems. For example,
there are currently limitations in browsers as to the number of
transceivers that can be active, so that providing a transceiver for each
of the participants in the conference could conceivably cause the browser
to run out of memory.

This is circumvented by not exposing participants to the SSRCs of all of
the users.  For example, the SFU may only allocate SSRCs for the professor
and the "last N" students who have asked questions, so that a participant
will only be aware of those SSRCs plus their own, instead of potentially
needing to deal with the SSRCs of all the participants in the conference.
This also has the effect of limiting the transceivers needed, most of which
are in "recv-only" mode from the perspective of the course participants.

When students wish to ask a question, permission is requested to access
their devices (but not before).  Then once the student is speaking, their
SSRC is translated, so that participants do not necessary see a new SSRC
but only the SSRC of "the current speaking student".  Also, the SFU will
typically consume the RTCP packets from students who are sending.

On Sat, Feb 2, 2019 at 4:19 AM Emil Ivov  wrote:

> I want to second that as it is a particularly major problem: not allowing
> SSRC rewriting makes the entire framework unusable with SFU implementatio=
n
> I represent as well as every other SFU I am familiar with.
>
> I am also not sure that I agree with =E2=80=9CSSRC rewriting could not be=
 allowed=E2=80=9D
> is a conclusion that ever had any consensus in PERC, regardless of what W=
G
> leadership is trying to make everyone believe.
>
> On Sat 2 Feb 2019 at 06:21, Bernard Aboba  wrote=
:
>
>> 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 PE=
RC
>> endpoints need to be able to receive simulcast? If PERC endpoints do nee=
d
>> to be able to receive simulcast, what are the requirements for endpoints=
?
>> For example, should endpoints expect the MDD to use RID header extension=
s
>> 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, neit=
her
>> 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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>>> 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 betwee=
n
>>> a JavaScript application and a browser, the browser acts as the Trusted
>>> Endpoint for purposes of this framework (just as it acts as the endpoin=
t
>>> for DTLS-SRTP in one-to-one calls).
>>>
>>>
>>> If we decide to adopt perc (big if) in webrtc, shouldn't this be define=
d
>>> 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 no=
t 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 i=
s
>>> being done in EME:
>>>
>>>
>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#enc=
ryption
>>>
>>> Best regards
>>>
>>> Sergio
>>> _______________________________________________
>>> Perc mailing list
>>> Perc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>> --
> sent from my mobile
>

--00000000000067b57b0580e8b604
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Emil said:=C2=A0

"I want to second=
 that as it is a particularly major problem: not allowing SSRC rewriting ma=
kes the entire framework unusable with SFU implementation I represent as we=
ll as every other SFU I am familiar with."

[B=
A] Can you articulate why you consider SSRC rewriting essential to SFU oper=
ation?=C2=A0

I can think of one scenario where SSR=
C rewriting does seem to be *required* -=C2=A0 Massive Online Courses (MOOC=
s). In these scenarios, there can be hundreds or even thousands of students=
, most of whom never speak during class, and teachers, who send media frequ=
ently.=C2=A0 MOOCs can be implemented via streaming media instead of RTP, b=
ut this complicates the interactive aspect.=C2=A0=C2=A0

So there are implementations of MOOCs that use RTP, and I believe tha=
t SSRC rewriting is an important part of the design of these systems. For e=
xample, there are currently limitations in browsers as to the number of tra=
nsceivers that can be active, so that providing a transceiver for each of t=
he participants in the conference could conceivably cause the browser to ru=
n out of memory.=C2=A0

This is circumvented by not=
=C2=A0exposing participants to the SSRCs of all of the users.=C2=A0 For exa=
mple, the SFU may only allocate SSRCs for the professor and the "last =
N" students who have asked questions, so that a participant will only =
be aware of those SSRCs plus their own, instead of potentially needing to d=
eal with the SSRCs of all the participants in the conference.=C2=A0 This al=
so has the effect of limiting the transceivers needed, most of which are in=
 "recv-only" mode from the perspective of the course participants=
.=C2=A0

When students wish to ask a question, perm=
ission is requested to access their devices (but not before).=C2=A0 Then on=
ce the student is speaking, their SSRC is translated, so that participants =
do not necessary see a new SSRC but only the SSRC of "the current spea=
king student".=C2=A0 Also, the SFU will typically consume the RTCP pac=
kets from students who are sending.=C2=A0

On Sat, Feb 2, 2019 at 4:19 =
AM Emil Ivov <emcho@jitsi.org>=
 wrote:
I want to second that as it is a particularly major problem:=
 not allowing SSRC rewriting makes the entire framework unusable with SFU i=
mplementation I represent as well as every other SFU I am familiar with.

I am also not sure t=
hat I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=9D is a=
 conclusion that ever had any consensus in PERC, regardless of what WG lead=
ership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba <bernard.aboba@gma=
il.com> wrote:
Richard said:

"Again, the answer is clear here, but the document s=
hould be clearer.=C2=A0 The working group discussed SSRC rewriting several =
times, and concluded that SSRC rewriting could not be allowed in this syste=
m.=C2=A0 This decision is reflected, e.g., in the fact that the Double tran=
sform does not allow modification of SSRCs."

[BA]=C2=A0 Not being able to rewrite SSRCs has some major implicatio=
ns with respect to requirements on PERC endpoints.=C2=A0 Typically today=
9;s MDD will switch between the simulcast streams provided by an endpoint, =
forwarding only a single stream to other participants, based on the bandwid=
th, resolution and framerates.=C2=A0 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 endp=
oints?=C2=A0 For example, should endpoints expect the MDD to use RID header=
 extensions to identify the incoming simulcast streams?=C2=A0
Receiving of simulcast is tricky because the endpoint is receiv=
ing multiple streams with different sequence number spaces which may contai=
n holes because of reordering or loss. This not only complicates the applic=
ation of RTX, RED and FEC, but also the operation of the endpoint.=C2=A0 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 rob=
ust in scenarios with considerable loss and/or reordering.=C2=A0 And neithe=
r implementation supports the RID header extension on received simulcast st=
reams.




On Fri, Feb 1, 201=
9 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> w=
rote:

 =20
   =20
 =20
  

    
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.iet=
f.org/html/draft-ietf-rtcweb-security-arch-17 doc
      ?

    

    


    

    
   Opti=
mally, 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#encrypt=
ion

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile




--00000000000067b57b0580e8b604--


From nobody Sat Feb  2 07:37:08 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5782512426E; Sat,  2 Feb 2019 07:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B60IbvpegkZK; Sat,  2 Feb 2019 07:36:56 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730A21228B7; Sat,  2 Feb 2019 07:36:56 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id y185so6706359wmd.1; Sat, 02 Feb 2019 07:36:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/VcPNmgRXZEStF69U2xchXUqHWORq8Z/1hcgxmSsXuE=; b=kmy6hcKJGqWdu7gK5UpT2KnJN0TTZyAOYzG4B4ehs/2vZdyUQ2R0iD9J6MWKrsTI1f 99bw1JiozZd1xt/175VITsH8ze22cj0sQ17KBzncGU4o8hO6lLB2KgE5k6otNC1U+phA LCPWTxNVdsIj8ACixTmFrRH5+1ANIvZ2PIXvN49gsXdXPoBN8brqsFV6odtvJAWTu7Zk 5Q+MEe34xDFfzK824iwL1PBPFNuSSPI0AnMk+/1LQ0Huo1gtyOCv06B+n3LTFunxxPDl BOXfr1xzGllkIvKty3+ypu7iNYt28omubK0QK2jqzzwmuIadO8hOHbPq2VrOyyDtA69w Xk6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/VcPNmgRXZEStF69U2xchXUqHWORq8Z/1hcgxmSsXuE=; b=Z3AXDfE28FRClBISHpJ4EaQhfkFfwmBxZvtpDSy1H4UirH62OT6gg2kub2CppamZKf TwakvGp5pAIh6yo6R6TES2QlQZzk5l+1RKK6eJonrRmL5DbsY972fmLxZOvd0XHOTuzh AVgicTBiSrzqESjJ+gxHREfhHrHkcDMt5ysCgnwN4diW8yCYHsPmYHy5AzEFGs7reEhk WIWZQAAXDFYlLtHURvQ7i0yjWXBj1Tm2HLWRqd/+j+RypXlZhx0A/6E7av2ccgaigAtC wG0c1dT1OIeL/SDlKs2hmmznNzYt57HFHCTym+Z+z88GeDlRtBCLVeKD38fDGk7uZ8Mg 2tFQ==
X-Gm-Message-State: AHQUAuaSjxsnNBam7TpNaLNtGh8GSmGYgNmo71iSKCQTYVSULdX7wmTA rD3A4jrHqbkBBMdOB1YeU/4=
X-Google-Smtp-Source: AHgI3IbJAf72HJJlY6cDUJ+G7cOMQM89neJhCjrzFv5KMe5YqTsQ0maX8wQgf/TIznRPGRgAlvl+0w==
X-Received: by 2002:a1c:b1d5:: with SMTP id a204mr7064887wmf.32.1549121814839;  Sat, 02 Feb 2019 07:36:54 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id m4sm5190574wmi.3.2019.02.02.07.36.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 07:36:54 -0800 (PST)
To: Bernard Aboba , Alexandre GOUAILLARD 
Cc: IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, "hta@google.com" , Sergio Garcia Murillo , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>  
From: Sergio Garcia Murillo 
Message-ID: 
Date: Sat, 2 Feb 2019 16:41:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 15:36:59 -0000

On 02/02/2019 13:30, Bernard Aboba wrote:
> 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?


The consensus we reached in Prague almost two years ago was that despite 
many of us didn't like the solution and while it would huge impact to 
implement it in current deployed based, it was technically feasible and 
we would not oppose getting this go trough as that it could be possible 
to progress alternative solutions (namely PERC lite and js keying) in 
other forums.

However the end to end encryption with trusted application use case had 
to be removed from the w3c nv scope because it was against what has been 
defined within this group. Given that, I would say that the previous 
consensus has been broken.

Best regards

Sergio



From nobody Sat Feb  2 08:19:17 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA26124BE5; Sat,  2 Feb 2019 08:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8pvnCkDtRC2; Sat,  2 Feb 2019 08:19:12 -0800 (PST)
Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE3A124B0C; Sat,  2 Feb 2019 08:19:12 -0800 (PST)
Received: by mail-vk1-xa41.google.com with SMTP id b18so2300593vke.2; Sat, 02 Feb 2019 08:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ryrQeSUSyuZCS5e2Ug7U0Ln5bTAQvh5hScfDnjwep2I=; b=WndJiGljLbmsIUO6arlBGFQN1acq0S06GCbHzHO1ZJeB/pGDCVfPmzLLAHu/xeOmFa UFM3JoL2U97o+gNFT+PzzSVrW8Ny7KOaxw6C+cOUvB7+dH1XkwbiSj3wXo7Q2nCe4lwz GpWqldS43c8yV/MlDI/C9RuzQFLLL9DyG3x1PefG9Mo17xpKIgrLs8aGPQr7o1xKfhcL YwL6B+eR3Pt0ABSMVVn5j3QrPtlq71S5GNH6jAXMUbyYL7GJOwui6XDlp87URcBgnJee 6MeIdkn5RgZh4TodrqZUAAwJphhpj8FjFjMU4UrXghoidyIWnsKsN4vchj9ToXY8sZ+1 UN/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ryrQeSUSyuZCS5e2Ug7U0Ln5bTAQvh5hScfDnjwep2I=; b=JCU/I0hjTnVJZ461D6UqXlbDrHHh3a5NteECNNCE9vBlWJAn+TeWnY7peW6gwW19ke xczVtl+4w9xTq5Vjw+ZXutRZdF39c7sbHnxWXoY8vGX5wKQU1KrhLZfQadLT1CTBW2wv KQv6TeI4yK/xgK3PLsEkQeyYmkvC98W5BO/9a5pTuHhTDaFdjfOObOL6kZc86XinHgDO r4tHT0MkBwUonEaBTJpuYZxTfXaPw+Ujlz3xahYqxjKnTUmyyaIXZrKkFDeZjq61uVpm M4OuOG3cmyKf1Su/ZWcZbSyjzzbV/xoT9KRFvVHliUH/6nMO6R8Q859QvjtszE6URg+X gS6g==
X-Gm-Message-State: AHQUAuY8aTnCAxgcJpGdq0QDzAHypVZGJ1sXMYIE+/hEigjak64nPBec eoh0rz29AjfId75joMsy056b+yCRhC5Uh8giy0o=
X-Google-Smtp-Source: AHgI3Ib8t9nKM7sxrk5B8l+4pxyLnbDRnFQeWJDv2lTMIoGqSj6ALe4gAObxV02Mzi+0Xfe+f9unjqy/lfz0zmZum+Q=
X-Received: by 2002:a1f:6b14:: with SMTP id g20mr4465871vkc.47.1549124346665;  Sat, 02 Feb 2019 08:19:06 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>   
In-Reply-To: 
From: Bernard Aboba 
Date: Sat, 2 Feb 2019 11:18:55 -0500
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Alexandre GOUAILLARD , IETF discussion list ,  Emad Omara , Emil Ivov , perc@ietf.org,  "hta@google.com" ,  Sergio Garcia Murillo ,  Lorenzo Miniero 
Content-Type: multipart/alternative; boundary="0000000000006562ed0580eb9e4d"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 16:19:15 -0000

--0000000000006562ed0580eb9e4d
Content-Type: text/plain; charset="UTF-8"

Sergio said:

"However the end to end encryption with trusted application use case had
to be removed from the w3c nv scope because it was against what has been
defined within this group. Given that, I would say that the previous
consensus has been broken."

[BA] Here is the consensus determination posted on the W3C WEBRTC WG
mailing list relating to that discussion:
https://lists.w3.org/Archives/Public/public-webrtc/2018Dec/0041.html

As noted in this email, there was considerable confusion relating to the
posted use case, with individuals interpreting the use case (and the
associated requirements) very differently.

To be able to develop one or more alternative use cases, I was hoping to be
able to rely upon the PERC framework document to tease apart the issues.
Unfortunately the current framework document barely even mentions the
points that have proven most contentious.

At this point, it is very difficult for me to even pinpoint whether the
discussion represents a lack of consensus about the whole PERC architecture
(e.g. throw it all away and start over based on frame encryption), or some
portions of the architecture are considered salvageable (e.g. continue with
packet payload encryption but use "PERC-lite" instead of Double, possibly
with a different key management scheme).  Assuming that the problems are
more in the latter category, there are a few questions which it would be
nice to have an answer to:

1. What are the requirements for replacing the PERC key management scheme?
Do other key management standards (e.g. EME) meet those requirements?
2. Are the problems with "Double " addressable via adoption of alternatives
such as PERC-lite? Or is the problem more fundamental (e.g. requiring
adoption of encryption at the frame rather than packet payload level)?
3. Is lack of support for SSRC-rewriting a limitation for implementation of
key scenarios (e.g. MOOCs). Does this imply a set of implementation
requirements (e.g. simulcast reception and associated features) that are
unlikely to be fulfilled in practice?  Is there a viable alternative to
SSRC-rewriting (e.g. involving RIDs)?

Without a clear framework document clearly discussing the relationships
between the aspects of the PERC architecture, describing the design choices
and how things fit together, it is very difficult to figure a way out of
this swamp.

To some extent this debate reminds me of the discussions relating to IPsec
and key management proposals, but at least in that case we had a well
articulated framework document (RFC 4301) that helped make the architecture
understandable and enabled its evolution over time.







On Sat, Feb 2, 2019 at 10:36 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 02/02/2019 13:30, Bernard Aboba wrote:
> > 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?
>
>
> The consensus we reached in Prague almost two years ago was that despite
> many of us didn't like the solution and while it would huge impact to
> implement it in current deployed based, it was technically feasible and
> we would not oppose getting this go trough as that it could be possible
> to progress alternative solutions (namely PERC lite and js keying) in
> other forums.
>
> However the end to end encryption with trusted application use case had
> to be removed from the w3c nv scope because it was against what has been
> defined within this group. Given that, I would say that the previous
> consensus has been broken.
>
> Best regards
>
> Sergio
>
>
>

--0000000000006562ed0580eb9e4d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sergio said:=C2=A0

&qu=
ot;However the end to end encryption with trusted application use case had=
=C2=A0
to be removed from the w3c nv scope because it was against what=
 has been=C2=A0
defined within this group. Given that, I would say that =
the previous=C2=A0
consensus has been broken."

<=
/div>
[BA] Here is the consensus determination posted on the W3C WEBRTC=
 WG mailing list relating to that discussion:
<=
br>
As noted in this email, there was considerable confusion rela=
ting to the posted use case, with individuals interpreting the use case (an=
d the associated requirements) very differently.=C2=A0

=

To be able to develop one or more alternative use cases, I was hoping =
to=C2=A0be able to rely upon the PERC framework document to tease apart the=
 issues.=C2=A0 Unfortunately the current framework document barely even men=
tions the points that have proven most contentious.=C2=A0=C2=A0
<=
br>
At this point, it is very difficult for me to even pinpoint w=
hether the discussion represents a lack of consensus about the whole PERC a=
rchitecture (e.g. throw it all away and start over based on frame encryptio=
n), or some portions of the architecture are considered salvageable (e.g. c=
ontinue with packet payload encryption but use "PERC-lite" instea=
d of Double, possibly with a different key management scheme).=C2=A0 Assumi=
ng that the problems are more in the latter category, there are a few quest=
ions which it would be nice to have an answer to:=C2=A0

1. What are the requirements for replacing the PERC key management sc=
heme?=C2=A0 Do other key management standards (e.g. EME) meet those require=
ments?=C2=A0
2. Are the problems with "Double " address=
able via adoption of alternatives such as PERC-lite? Or is the problem more=
 fundamental (e.g. requiring adoption of encryption at the frame rather tha=
n packet payload level)?
3. Is lack of support for SSRC-rewriting=
 a limitation for implementation of key scenarios (e.g. MOOCs). Does this i=
mply a set of implementation requirements (e.g. simulcast reception and ass=
ociated features) that are unlikely to be fulfilled in practice?=C2=A0 Is t=
here a viable alternative to SSRC-rewriting (e.g. involving RIDs)?=C2=A0

Without a clear framework document clearly discussin=
g the relationships between the aspects of the PERC architecture, describin=
g the design choices and how things fit together, it is very difficult to f=
igure a way out of this swamp.=C2=A0

To some exten=
t this debate reminds me of the discussions relating to IPsec and key manag=
ement proposals, but at least in that case we had a well articulated framew=
ork document (RFC 4301) that helped make the architecture understandable an=
d enabled its evolution over time.=C2=A0






On Sat, =
Feb 2, 2019 at 10:36 AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 02/02/2019 13:3=
0, Bernard Aboba wrote:

> 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.=C2=A0 Are you saying that you do=
 not 

> agree that there is an IETF consensus to publish this document as a 
> Proposed Standard?=C2=A0 Or that there is no IETF consensus to publish=
 

> *any* of the PERC WG output as a Proposed Standard?





The consensus we reached in Prague almost two years ago was that despite 
many of us didn't like the solution and while it would huge impact to <=
br>
implement it in current deployed based, it was technically feasible and 
we would not oppose getting this go trough as that it could be possible 
to progress alternative solutions (namely PERC lite and js keying) in 

other forums.



However the end to end encryption with trusted application use case had 
to be removed from the w3c nv scope because it was against what has been 
defined within this group. Given that, I would say that the previous 

consensus has been broken.



Best regards



Sergio








--0000000000006562ed0580eb9e4d--


From nobody Sat Feb  2 08:41:39 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2C6124B0C for ; Sat,  2 Feb 2019 08:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxRp6RKf5kWY for ; Sat,  2 Feb 2019 08:41:26 -0800 (PST)
Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2321E1200D7 for ; Sat,  2 Feb 2019 08:41:26 -0800 (PST)
Received: by mail-vs1-xe44.google.com with SMTP id z3so6146837vsf.7 for ; Sat, 02 Feb 2019 08:41:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NWyhnXRdM3HutLGy5/SEGy4DESR7fimOUkOu3dP1iFI=; b=k7rfvV3sUKevMpGgt3J5K9ephgJ9CbFzHTgkrEo+reNmll/VoxMeA3bh2HK2ci/scV 1fAu+8L7BAPL8QaX0kSyzMyf+SZloZlbSCwoMFnzXCdrh6XcJkurpa2ZC3hsr+PQVSjl zi/tqY0+sx6lnrInAXW62U+LEcT4oDUUYIio5Bcww86+SxV3rgAmno/agyJmOp5SPnMO /+zwIqJ/xdVUmv9pBXnlMa/fVu0t1Ch8SDcuLEG93frt+uzTjddsLADq+u6yg87u5JKr 1g6zLQD5l9vf3S3sqXdrfIzPzWzdTdD1AmDecMeU3PFiGApl3PG6/UKa4cY5vFm/b+eT Zd9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NWyhnXRdM3HutLGy5/SEGy4DESR7fimOUkOu3dP1iFI=; b=NYA/XL99mLAXXgWlLAe3jLKktV4tjm47Zac0KrhKHicbvx/q/z1IOU2lwPhsod7ntH QLSfDscBIXPEKAGdXvnNPEl9IhuFoiNn13neaMG37yOfAXQwkwjNU1jFlFDRI6N9RnRf pxoY9YbVy/HEgKll/SpVX4FTlFSSVbUXfJ6UXDO8iq4sU1fDFJ0UpvmhrZ0T9oCrHpXl UWwnwCFn88bdCdudUOhg0gNNhGS4FZEmiDqebduvmufOPS4y/NisjdwPPXjb3t/01iZ4 ezcZToiKsYTBHQT2AhOF3JBPINpMUsgk/+zwHFe5bt1u33jv1CesYO0tqRU4Tfo98xmP sGXg==
X-Gm-Message-State: AJcUukdgDK2kaajOQD2ySGDZ+3Vk94SOCFm8OYHgK+TxG9l7prN6lyoi gmt3U7jayr0KVww6LQbqrzsLzUhCtxWNVWGmQ8LK1g==
X-Google-Smtp-Source: ALg8bN4WhHelyf6zgAOUMfEpWhAviMLF2DF4klwD1TIHuE7SYCsefvzK72Q5OW5oNJbnHhz8akHVAVWvpVNb4ejh17s=
X-Received: by 2002:a67:f943:: with SMTP id u3mr19615613vsq.149.1549125684922;  Sat, 02 Feb 2019 08:41:24 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   
In-Reply-To: 
From: Emil Ivov 
Date: Sat, 2 Feb 2019 16:41:12 +0000
Message-ID: 
To: Bernard Aboba 
Cc: Alexandre GOUAILLARD , Emad Omara , IETF discussion list ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000029aae20580ebee59"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 16:41:30 -0000

--00000000000029aae20580ebee59
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The scenario you outline may be one. I call that SSRC rewriting for Last N

Simulcast through SSRC rewriting (that you describe) is the one that
concerns us currently.



On Sat 2 Feb 2019 at 12:51, Bernard Aboba  wrote:

> Emil said:
>
> "I want to second that as it is a particularly major problem: not allowin=
g
> SSRC rewriting makes the entire framework unusable with SFU implementatio=
n
> I represent as well as every other SFU I am familiar with."
>
> [BA] Can you articulate why you consider SSRC rewriting essential to SFU
> operation?
>
> I can think of one scenario where SSRC rewriting does seem to be
> *required* -  Massive Online Courses (MOOCs). In these scenarios, there c=
an
> be hundreds or even thousands of students, most of whom never speak durin=
g
> class, and teachers, who send media frequently.  MOOCs can be implemented
> via streaming media instead of RTP, but this complicates the interactive
> aspect.
>
> So there are implementations of MOOCs that use RTP, and I believe that
> SSRC rewriting is an important part of the design of these systems. For
> example, there are currently limitations in browsers as to the number of
> transceivers that can be active, so that providing a transceiver for each
> of the participants in the conference could conceivably cause the browser
> to run out of memory.
>
> This is circumvented by not exposing participants to the SSRCs of all of
> the users.  For example, the SFU may only allocate SSRCs for the professo=
r
> and the "last N" students who have asked questions, so that a participant
> will only be aware of those SSRCs plus their own, instead of potentially
> needing to deal with the SSRCs of all the participants in the conference.
> This also has the effect of limiting the transceivers needed, most of whi=
ch
> are in "recv-only" mode from the perspective of the course participants.
>
> When students wish to ask a question, permission is requested to access
> their devices (but not before).  Then once the student is speaking, their
> SSRC is translated, so that participants do not necessary see a new SSRC
> but only the SSRC of "the current speaking student".  Also, the SFU will
> typically consume the RTCP packets from students who are sending.
>
> On Sat, Feb 2, 2019 at 4:19 AM Emil Ivov  wrote:
>
>> I want to second that as it is a particularly major problem: not allowin=
g
>> SSRC rewriting makes the entire framework unusable with SFU implementati=
on
>> I represent as well as every other SFU I am familiar with.
>>
>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could not b=
e
>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, re=
gardless of
>> what WG leadership is trying to make everyone believe.
>>
>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>> wrote:
>>
>>> 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, forwardin=
g
>>> only a single stream to other participants, based on the bandwidth,
>>> resolution and framerates.  If rewriting of SSRCs is not possible, do P=
ERC
>>> endpoints need to be able to receive simulcast? If PERC endpoints do ne=
ed
>>> to be able to receive simulcast, what are the requirements for endpoint=
s?
>>> For example, should endpoints expect the MDD to use RID header extensio=
ns
>>> 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 contai=
n
>>> 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, suppor=
t
>>> for reception of simulcast is optional. I am aware of two ORTC
>>> implementations that have attempted to support simulcast reception, nei=
ther
>>> of which is robust in scenarios with considerable loss and/or reorderin=
g.
>>> And neither implementation supports the RID header extension on receive=
d
>>> simulcast streams.
>>>
>>>
>>>
>>>
>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>> sergio.garcia.murillo@gmail.com> wrote:
>>>
>>>> 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 th=
e
>>>> Trusted Endpoint for purposes of this framework (just as it acts as th=
e
>>>> 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 th=
e
>>>>    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 thu=
s
>>>>    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 u=
p
>>>> to the RTCWEB group to decide what is a trusted endpoint and what is n=
ot in
>>>> webrtc. As Bernard is stating, we could decide that there are other ke=
y
>>>> 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#en=
cryption
>>>>
>>>> Best regards
>>>>
>>>> Sergio
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>
>>> --
>> sent from my mobile
>>
> --
sent from my mobile

--00000000000029aae20580ebee59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The scenario you outline may be one. I call that SSR=
C rewriting for Last N

Simulcast through SSRC rewriting (that you describe) is the one that c=
oncerns us currently.


On Sat 2 Feb 2=
019 at 12:51, Bernard Aboba <=
bernard.aboba@gmail.com> wrote:
Emil said:=C2=A0

"I want to se=
cond that as it is a particularly major problem: not allowing SSRC rewritin=
g makes the entire framework unusable with SFU implementation I represent a=
s well as every other SFU I am familiar with."

[BA] Can you articulate why you consider SSRC rewriting essential to SFU =
operation?=C2=A0

I can think of one scenario where=
 SSRC rewriting does seem to be *required* -=C2=A0 Massive Online Courses (=
MOOCs). In these scenarios, there can be hundreds or even thousands of stud=
ents, most of whom never speak during class, and teachers, who send media f=
requently.=C2=A0 MOOCs can be implemented via streaming media instead of RT=
P, but this complicates the interactive aspect.=C2=A0=C2=A0

<=
/div>
So there are implementations of MOOCs that use RTP, and I believe=
 that SSRC rewriting is an important part of the design of these systems. F=
or example, there are currently limitations in browsers as to the number of=
 transceivers that can be active, so that providing a transceiver for each =
of the participants in the conference could conceivably cause the browser t=
o run out of memory.=C2=A0

This is circumvented by=
 not=C2=A0exposing participants to the SSRCs of all of the users.=C2=A0 For=
 example, the SFU may only allocate SSRCs for the professor and the "l=
ast N" students who have asked questions, so that a participant will o=
nly be aware of those SSRCs plus their own, instead of potentially needing =
to deal with the SSRCs of all the participants in the conference.=C2=A0 Thi=
s also has the effect of limiting the transceivers needed, most of which ar=
e in "recv-only" mode from the perspective of the course particip=
ants.=C2=A0

When students wish to ask a question, =
permission is requested to access their devices (but not before).=C2=A0 The=
n once the student is speaking, their SSRC is translated, so that participa=
nts do not necessary see a new SSRC but only the SSRC of "the current =
speaking student".=C2=A0 Also, the SFU will typically consume the RTCP=
 packets from students who are sending.=C2=A0

On Sat, Feb 2, 2019 at 4=
:19 AM Emil Ivov <e=
mcho@jitsi.org> wrote:
I want to second that as it is a parti=
cularly major problem: not allowing SSRC rewriting makes the entire framewo=
rk 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 =E2=80=9CSSRC rewriting could not be=
 allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, rega=
rdless of what WG leadership is trying to make everyone believe.
=

On Sat 2 Feb 2019 at 06:21,=
 Bernard Aboba <bernard.aboba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here=
, but the document should be clearer.=C2=A0 The working group discussed SSR=
C rewriting several times, and concluded that SSRC rewriting could not be a=
llowed in this system.=C2=A0 This decision is reflected, e.g., in the fact =
that the Double transform does not allow modification of SSRCs."=
;

[BA]=C2=A0 Not being able to rewrite SSRCs has s=
ome major implications with respect to requirements on PERC endpoints.=C2=
=A0 Typically today's MDD will switch between the simulcast streams pro=
vided by an endpoint, forwarding only a single stream to other participants=
, based on the bandwidth, resolution and framerates.=C2=A0 If rewriting of =
SSRCs is not possible, do PERC endpoints need to be able to receive simulca=
st? If PERC endpoints do need to be able to receive simulcast, what are the=
 requirements for endpoints?=C2=A0 For example, should endpoints expect the=
 MDD to use RID header extensions to identify the incoming simulcast stream=
s?=C2=A0

Receiving of simulcast is tricky because =
the endpoint is receiving multiple streams with different sequence number s=
paces 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.=C2=A0 As a result, as noted in the WEBRTC specification Secti=
on 5.4.1, support for reception of simulcast is optional. I am aware of two=
 ORTC implementations that have attempted to support simulcast reception, n=
either of which is robust in scenarios with considerable loss and/or reorde=
ring.=C2=A0 And neither implementation supports the RID header extension on=
 received simulcast streams.




On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.muril=
lo@gmail.com> wrote:

 =20
   =20
 =20
  

    
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 othe=
r 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@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile




-- 
sent from my mobile


--00000000000029aae20580ebee59--


From nobody Sat Feb  2 08:46:35 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777F41200D7 for ; Sat,  2 Feb 2019 08:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xjp18GldoO5 for ; Sat,  2 Feb 2019 08:46:22 -0800 (PST)
Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7964A124B0C for ; Sat,  2 Feb 2019 08:46:22 -0800 (PST)
Received: by mail-vk1-xa43.google.com with SMTP id 197so2311424vkf.4 for ; Sat, 02 Feb 2019 08:46:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MN/iL8vg0fdky6WrYTaG/yjjmQDZMtpGCRPv5hXeKxs=; b=GnP2hmY3VZvLnSMX9NXIW+4Aov1bksdt7fZBTo4Sr3XTWurhBELo8koTfEi1/SUOGs 5kZXBVmsnVqxqbPVqrzIuiBARA10Xs2yu931v+2tUVjos5joEyZ4ZTSMGurwipvFJ8LJ wXAD/uPzsJwFvampKdmsWPrQWClr8B6nX6qaXGkd7DnBDAdLHkHtsL6S2zJITFDSHiCe Qpqh0Z1HiJCSQxIyc1VdXOiRrQimUXy/IAXYrk4a3eDQMzXvTUmo2vcVy4NMiWctyknj oqHxbGLC+r4FUgvbStpAu9+k3+stAkirCmwOGDz6/Suz4MrqnvoYD3wd1Zal/clXyypu hh0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MN/iL8vg0fdky6WrYTaG/yjjmQDZMtpGCRPv5hXeKxs=; b=I49lIkFj8gZxPfCG9knqNnghYBzGQHTCWsqMcBSxRGBj4Qmci4HkC7ssU/ZjenTJgI gXHa3rQtIs1QpLZH4zQ5MJeOBvlU4wAf/q/CQ2eszZnq//xz00pUUYr+xJ7Ci6sWSDaA oUoAgRwQ9+vrfOZ+INmZZ+kyAz6OnOP+BE+rGN9+yNahzD4Qnh+sezmQkWjKjVzHTP7e PDaWF03xNOxQFCfR5p99T57C579fw4/RxDzuNloWXSXgcs6AMPVHfnlp2oP8RFNeTBOp MI5S8qDb81F2WqLr+TjKoHu/E8fAzV1GpbBqaTZcg9h9hCkUWwOcWffB1OX2Rrnwct06 CgWg==
X-Gm-Message-State: AJcUukdjLbQCik9s1EviLgYXVoIC/V5CuU3q03vk7F825j5ULXOR/K56 LjlV9Y4cJ7XTeJxz9tQFXnHSV0gReKYsDP5CqGdUYA==
X-Google-Smtp-Source: ALg8bN4vJvc/7tCRg4i9haVivLB/cpIlIEIkSDd//bofJqqiU0tdOAnoPNjnY647yxAsr13i1Fxb1NAt3KW9yGtUB08=
X-Received: by 2002:a1f:7cca:: with SMTP id x193mr19123886vkc.89.1549125981258;  Sat, 02 Feb 2019 08:46:21 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>  
In-Reply-To: 
From: Emil Ivov 
Date: Sat, 2 Feb 2019 16:46:10 +0000
Message-ID: 
To: Bernard Aboba 
Cc: Alexandre GOUAILLARD , Emad Omara ,  IETF discussion list , Lorenzo Miniero ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d367ac0580ebffd4"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 16:46:27 -0000

--000000000000d367ac0580ebffd4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes pretty much those.

The need to do a triple encryption for example is a particularly egregious
consequence of the order problem. That=E2=80=99s a problem specific to the =
=E2=80=9Cdouble=E2=80=9D
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 Sat 2 Feb 2019 at 12:23, Bernard Aboba  wrote:

> "on the consensus not reached on this and other topics."
>
> [BA] Out of curiosity, what other topics do you consider to be problemati=
c
> within the framework?  I am aware of at least two others where implemente=
rs
> 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?
>
> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
> alex.gouaillard@cosmosoftware.io> wrote:
>
>> +1 on ssrc rewriting, and on the consensus not reached on this and other
>> topics.
>>
>> Sent from my iPhone
>>
>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote:
>>
>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>
>> Lorenzo
>>
>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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 wit=
h.
>>>
>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could not =
be
>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, r=
egardless of
>>> what WG leadership is trying to make everyone believe.
>>>
>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>> wrote:
>>>
>>>> Richard said:
>>>>
>>>> "Again, the answer is clear here, but the document should be clearer.
>>>> The working group discussed SSRC rewriting several times, and conclude=
d
>>>> that SSRC rewriting could not be allowed in this system.  This decisio=
n 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, forwardi=
ng
>>>> 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 n=
eed
>>>> to be able to receive simulcast, what are the requirements for endpoin=
ts?
>>>> For example, should endpoints expect the MDD to use RID header extensi=
ons
>>>> 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 conta=
in
>>>> holes because of reordering or loss. This not only complicates the
>>>> application of RTX, RED and FEC, but also the operation of the endpoin=
t.
>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, suppo=
rt
>>>> for reception of simulcast is optional. I am aware of two ORTC
>>>> implementations that have attempted to support simulcast reception, ne=
ither
>>>> of which is robust in scenarios with considerable loss and/or reorderi=
ng.
>>>> And neither implementation supports the RID header extension on receiv=
ed
>>>> simulcast streams.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>
>>>>> 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 t=
he
>>>>> Trusted Endpoint for purposes of this framework (just as it acts as t=
he
>>>>> 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 t=
he
>>>>>    browser.  However, this is unfortunately not possible if we wish t=
o
>>>>>    have a functional system.  Other network elements fall into two
>>>>>    categories: those which can be authenticated by the browser and th=
us
>>>>>    can be granted permissions to access sensitive resources, and thos=
e
>>>>>    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 othe=
r 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#e=
ncryption
>>>>>
>>>>> Best regards
>>>>>
>>>>> Sergio
>>>>> _______________________________________________
>>>>> Perc mailing list
>>>>> Perc@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>
>>>> --
>>> sent from my mobile
>>>
>>
>> --
>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=C3=
=A0.
>>
>> --
sent from my mobile

--000000000000d367ac0580ebffd4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes pretty much those.
=

The need to do a triple encryption for example =
is a particularly egregious consequence of the order problem. That=E2=80=99=
s a problem specific to the =E2=80=9Cdouble=E2=80=9D documents.

I would however also say that the d=
ecision to bake one specific way of performing key negotiation into the fra=
mework rather than leaving it open was both unnecessary and quite problemat=
ic.

Emil

<=
div class=3D"gmail_quote">
On Sat 2 Feb 2019 at 12:23, Bern=
ard Aboba <bernard.aboba@gmai=
l.com> wrote:
"on the consensus not reached on this and other topics."
<=
br>
[BA] Out of curiosity, what other topics do you consider to b=
e problematic within the framework?=C2=A0 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/R=
TX/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.=C2=A0 Are you saying that you do not =
agree that there is an IETF consensus to publish this document as a Propose=
d Standard?=C2=A0 Or that there is no IETF consensus to publish *any* of th=
e PERC WG output as a Proposed Standard?=C2=A0

On Sat, Feb 2, 2019 at =
5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io> wrote:=

+1 on ssrc rewriting, and on the consensus not reached on this and other=
 topics.

Sent from my iPhone

On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
+1, SSRC rewriting is pre=
tty much fundamental to all SFUs out there.

Lorenzo

Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org> ha scrit=
to:


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here, but the docu=
ment should be clearer.=C2=A0 The working group discussed SSRC rewriting se=
veral times, and concluded that SSRC rewriting could not be allowed in this=
 system.=C2=A0 This decision is reflected, e.g., in the fact that the Doubl=
e transform does not allow modification of SSRCs."
[BA]=C2=A0 Not being able to rewrite SSRCs has some major impl=
ications with respect to requirements on PERC endpoints.=C2=A0 Typically to=
day's MDD will switch between the simulcast streams provided by an endp=
oint, forwarding only a single stream to other participants, based on the b=
andwidth, resolution and framerates.=C2=A0 If rewriting of SSRCs is not pos=
sible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements fo=
r endpoints?=C2=A0 For example, should endpoints expect the MDD to use RID =
header extensions to identify the incoming simulcast streams?=C2=A0

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.=C2=
=A0 As a result, as noted in the WEBRTC specification Section 5.4.1, suppor=
t for reception of simulcast is optional. I am aware of two ORTC implementa=
tions that have attempted to support simulcast reception, neither of which =
is robust in scenarios with considerable loss and/or reordering.=C2=A0 And =
neither implementation supports the RID header extension on received simulc=
ast streams.




On Fri, Feb =
1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com=
> wrote:

 =20
   =20
 =20
  

    
On 01/02/2019 1=
7: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 do=
c
      ?

    

    


    

    
   Optimally, we would not rely on trust in any entities ot=
her 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/mast=
er/explainer.md#encryption

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 M=
ail. Perdonate la brevit=C3=A0.


-- 
sent from my mobile


--000000000000d367ac0580ebffd4--


From nobody Sat Feb  2 08:50:57 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDEA124BE5; Sat,  2 Feb 2019 08:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZHihqlhLvJb; Sat,  2 Feb 2019 08:50:54 -0800 (PST)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED941200D7; Sat,  2 Feb 2019 08:50:53 -0800 (PST)
Received: by mail-ua1-x929.google.com with SMTP id v24so3209482uap.13; Sat, 02 Feb 2019 08:50:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S2VOGI5KA8z7mKSOlpXtqX8hoQZqs9k3MCp8EP4eP2E=; b=MtVb4w4RpkC4zKQmhl2jzsFZ6JMp7YCtpncUqMUb4lv6pTae9sRJwLwzkJvwRrYHk4 kuLNlI2fkJzhjpkamcyLiUUh4F5u5Nc5yiMCEDj5xzYzyheeXspTUhfObwFWODP3muWk 57YKIr3WKRu2tiHs8MWOO36a6jfR7K7zOz7CFJrfFIFsR0K+7I5tX8IEFiTweH6UmmJY UCbP36969hUkVPJYvSko+FGoJs/BO4qRZP+nbpD00GfT8+pm3i6tJXMuWJKMY80wi0Hq mAxWvkxyDRWGFpJF9C/sfj1PZGuTc3p895NgvdvlcVO5lQkDOCtEnM3umckIgmSiXNeC 3d/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S2VOGI5KA8z7mKSOlpXtqX8hoQZqs9k3MCp8EP4eP2E=; b=WG26Bf4GA7XtvKnFKwepOlb+iBE4VEmtfaxhqK5wXugjFqx3182x0aoy6dpyKXCvLY ob//Hz58vXgiuoB262b+pEqXN60PebMu65/EzlMSAA8SwtuwRvU7wAYa3ZN0TFt27Ryv PIMGp8WzNtHSnJMGlkfGDhLyg+s3T4ut3iow2y7NsKkj+heGaE9p7UcRbhvVlc1PYCxw JyuzyikHngHsPGe3goLna/IcAtMcaR5zsS/eyshMOBc8W0cE36vJoFL0gPl/C6itufEl qIgmSdLPtkAowAXyiN93UEnnn4goXYI2ejR2+eOS8ahF4zE9YTcOz9/0iRWihw0lq/y0 7jGQ==
X-Gm-Message-State: AHQUAuYxr6WctB5FDsbKWwiPH3ytQSi7dfBIM7BwU7o6jR22h+QylCy7 CxspsOeEZFfu3ql3B0PtN9NgZkXjBHLBv6EFV2o=
X-Google-Smtp-Source: AHgI3Ib1y/XORF1kE1EoJRtBilbEXPa/jYL0xkPESediwEFEB+9boEeUDWX9PWcBT4tXIyO14Kv5Ihbxyf1CzX7+ysk=
X-Received: by 2002:ab0:59ef:: with SMTP id k44mr11645530uad.118.1549126252246;  Sat, 02 Feb 2019 08:50:52 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>   
In-Reply-To: 
From: Bernard Aboba 
Date: Sat, 2 Feb 2019 11:50:40 -0500
Message-ID: 
To: Emil Ivov 
Cc: Alexandre GOUAILLARD , Emad Omara ,  IETF discussion list , Lorenzo Miniero ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fa3f2b0580ec0f14"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 16:50:57 -0000

--000000000000fa3f2b0580ec0f14
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Emil said:

"The need to do a triple encryption for example is a particularly egregious
consequence of the order problem. That=E2=80=99s a problem specific to the =
=E2=80=9Cdouble=E2=80=9D
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".

On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:

> Yes pretty much those.
>
> The need to do a triple encryption for example is a particularly egregiou=
s
> consequence of the order problem. That=E2=80=99s a problem specific to th=
e =E2=80=9Cdouble=E2=80=9D
> 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 Sat 2 Feb 2019 at 12:23, Bernard Aboba  wrote=
:
>
>> "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 whe=
re
>> 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?
>>
>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
>> alex.gouaillard@cosmosoftware.io> wrote:
>>
>>> +1 on ssrc rewriting, and on the consensus not reached on this and othe=
r
>>> topics.
>>>
>>> Sent from my iPhone
>>>
>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote:
>>>
>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>
>>> Lorenzo
>>>
>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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 wi=
th.
>>>>
>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could not=
 be
>>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, =
regardless of
>>>> what WG leadership is trying to make everyone believe.
>>>>
>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>>> wrote:
>>>>
>>>>> Richard said:
>>>>>
>>>>> "Again, the answer is clear here, but the document should be
>>>>> clearer.  The working group discussed SSRC rewriting several times, a=
nd
>>>>> concluded that SSRC rewriting could not be allowed in this system.  T=
his
>>>>> decision is reflected, e.g., in the fact that the Double transform do=
es not
>>>>> allow modification of SSRCs."
>>>>>
>>>>> [BA]  Not being able to rewrite SSRCs has some major implications wit=
h
>>>>> respect to requirements on PERC endpoints.  Typically today's MDD wil=
l
>>>>> switch between the simulcast streams provided by an endpoint, forward=
ing
>>>>> 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 endpoi=
nts?
>>>>> For example, should endpoints expect the MDD to use RID header extens=
ions
>>>>> 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 cont=
ain
>>>>> holes because of reordering or loss. This not only complicates the
>>>>> application of RTX, RED and FEC, but also the operation of the endpoi=
nt.
>>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, supp=
ort
>>>>> for reception of simulcast is optional. I am aware of two ORTC
>>>>> implementations that have attempted to support simulcast reception, n=
either
>>>>> of which is robust in scenarios with considerable loss and/or reorder=
ing.
>>>>> And neither implementation supports the RID header extension on recei=
ved
>>>>> simulcast streams.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>>
>>>>>> 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 t=
hus
>>>>>>    can be granted permissions to access sensitive resources, and tho=
se
>>>>>>    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 oth=
er key
>>>>>> management solutions trusted (even in JS or WASM), as for for exampl=
e is
>>>>>> being done in EME:
>>>>>>
>>>>>>
>>>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md#=
encryption
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Sergio
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> Perc@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>
>>>>> --
>>>> sent from my mobile
>>>>
>>>
>>> --
>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=
=C3=A0.
>>>
>>> --
> sent from my mobile
>

--000000000000fa3f2b0580ec0f14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Emil said:

"The need to do a tripl=
e encryption for example is a particularly egregious consequence of the ord=
er problem. That=E2=80=99s a problem specific to the =E2=80=9Cdouble=E2=80=
=9D documents."

[BA] Can you describe how the=
 need for "triple encryption" arises?=C2=A0 The framework documen=
t doesn't even mention the issues with ordering of FEC/RTX/RED and encr=
yption, let alone the need for "triple encryption".=C2=A0

On=
 Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org> wrote:
Yes pretty much those.

The need to do a triple encr=
yption for example is a particularly egregious consequence of the order pro=
blem. That=E2=80=99s a problem specific to the =E2=80=9Cdouble=E2=80=9D doc=
uments.

I would however =
also say that the decision to bake one specific way of performing key negot=
iation into the framework rather than leaving it open was both unnecessary =
and quite problematic.

E=
mil

On Sat 2 Feb =
2019 at 12:23, Bernard Aboba <bernard.aboba@gmail.com> wrote:
"on the con=
sensus not reached on this and other topics."

[BA] =
Out of curiosity, what other topics do you consider to be problematic withi=
n the framework?=C2=A0 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

W=
ith 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.=C2=A0 Are you saying that you do not agree that there is=
 an IETF consensus to publish this document as a Proposed Standard?=C2=A0 O=
r that there is no IETF consensus to publish *any* of the PERC WG output as=
 a Proposed Standard?=C2=A0

On Sat, Feb 2, 2019 at 5:40 AM Alexandre G=
OUAILLARD <alex.gouaillard@cosmosoftware.io> wrote:
+1 on ssrc rewri=
ting, and on the consensus not reached on this and other topics.

Sent from my iPhone

On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com> wrote=
:

+1, SSRC rewritin=
g is pretty much fundamental to all SFUs out there.

Lorenzo

<=
div class=3D"gmail_quote">Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org> =
ha scritto:


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here, but the docu=
ment should be clearer.=C2=A0 The working group discussed SSRC rewriting se=
veral times, and concluded that SSRC rewriting could not be allowed in this=
 system.=C2=A0 This decision is reflected, e.g., in the fact that the Doubl=
e transform does not allow modification of SSRCs."
[BA]=C2=A0 Not being able to rewrite SSRCs has some major impl=
ications with respect to requirements on PERC endpoints.=C2=A0 Typically to=
day's MDD will switch between the simulcast streams provided by an endp=
oint, forwarding only a single stream to other participants, based on the b=
andwidth, resolution and framerates.=C2=A0 If rewriting of SSRCs is not pos=
sible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements fo=
r endpoints?=C2=A0 For example, should endpoints expect the MDD to use RID =
header extensions to identify the incoming simulcast streams?=C2=A0

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.=C2=
=A0 As a result, as noted in the WEBRTC specification Section 5.4.1, suppor=
t for reception of simulcast is optional. I am aware of two ORTC implementa=
tions that have attempted to support simulcast reception, neither of which =
is robust in scenarios with considerable loss and/or reordering.=C2=A0 And =
neither implementation supports the RID header extension on received simulc=
ast streams.




On Fri, Feb =
1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com=
> wrote:

 =20
   =20
 =20
  

    
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-rtc=
web-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/m=
edia-capabilities/blob/master/explainer.md#encryption

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile




--000000000000fa3f2b0580ec0f14--


From nobody Sat Feb  2 09:43:18 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB4126C7E for ; Sat,  2 Feb 2019 09:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOstqXKojNS4 for ; Sat,  2 Feb 2019 09:43:05 -0800 (PST)
Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D981277CC for ; Sat,  2 Feb 2019 09:43:05 -0800 (PST)
Received: by mail-vk1-xa43.google.com with SMTP id y14so2325305vky.9 for ; Sat, 02 Feb 2019 09:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lYFyNnQOmM8eKSn5EWNgJKvSHoYiYD3EaTd8Rgl/uHc=; b=ivuUgA0Hpxa5TjiAoYpGxNLVSRruNHaDonW2irtRDwaI3orretHYu/wNefM5dxK+L8 TSc78WeuThyY3GLZXaZ6xjPi/GPOh1oI5YwHd5jG76SigYdB+wY5q8yh2HVk0/AaJ/Fk dUVOS6jaaox2XModGCisaMwQo9VQzOGhUpSjbYE0CJavHop3vPMvFEt1r8gqKUrZvDkU wF/4gIF3M2QWYTVeLI3IRKOcHnvA9KMmn12WhJL6BP78IA5hpv+ar9HgKpnZAMh0T6IK O9KN7iEV0AW789pjKV3jK+HThmYPaVybRW4fB1/Ew83AiEeqSelTHyxNd5Yf17L2W4Mr CEqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lYFyNnQOmM8eKSn5EWNgJKvSHoYiYD3EaTd8Rgl/uHc=; b=WH7BM78z+Oe1eSASigCGvPaKMbR9PnMG1qN6Wtl2vazpdWCX2F77d7rvfM0yoDfan2 r04a9RVqwmVADxVAAb05nUiT0lpoq9sSnGE9pyQ99klAayXSIHrrEokfJZeF1LvVtsDB YTIrfFVJSrV4K/b64Sh6v5bXzDzfO9qmpUPrF6S2tPJQGILAfvMnA1yTCRlmbK927ta5 N/xF9w+C6NHJaHeOY5g0amdne7FXeyl4tB3N1/UHlX5ayMX6lMKyu67zNyfJKJ5L5ho9 SFRCbstCQ/e1aqlXh1waPIn80/2EXO7RWq+cV1A983Ii1FWjR/nZP63dcV9NcUNohznd 3EgQ==
X-Gm-Message-State: AJcUukcaYoxFDlenW9AtEaLFo15G+hubzOTbtluTYW26KjBYyibewcnQ CsGVkp7PA1YiPvdwBtwXqgxETLpd47Elw+h+Qmeb6Q==
X-Google-Smtp-Source: ALg8bN5SWnA7GEAOziCMeynoc4fckDJguA22rs/sxcCtGMT917zEflms3HSgLRO3WA4dm2sDwgvCAHe+LFqiUEByMk4=
X-Received: by 2002:a1f:8a8e:: with SMTP id m136mr19072317vkd.46.1549129384026;  Sat, 02 Feb 2019 09:43:04 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>    
In-Reply-To: 
From: Emil Ivov 
Date: Sat, 2 Feb 2019 17:42:51 +0000
Message-ID: 
To: Bernard Aboba 
Cc: Alexandre GOUAILLARD , Emad Omara ,  IETF discussion list , Lorenzo Miniero ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a57e910580eccad1"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 17:43:11 -0000

--000000000000a57e910580eccad1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat 2 Feb 2019 at 16:50, Bernard Aboba  wrote:

> Emil said:
>
> "The need to do a triple encryption for example is a particularly
> egregious consequence of the order problem. That=E2=80=99s a problem spec=
ific to
> the =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that this goal is a direct consequence of the framewor=
k=E2=80=99s
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 =E2=80=9Cwedging RTX and FEC=E2=80=9D as i=
t 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
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D goal, but also leaves RTX an=
d mostly FEC unprotected
and FEC receivers vulnerable to DoS. To this the proponents of this
approach simply replied with: =E2=80=9Cwell, those of you who use FEC/RTX w=
ill
simply do a third round of SRTP=E2=80=9D, 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



> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:
>
>> Yes pretty much those.
>>
>> The need to do a triple encryption for example is a particularly
>> egregious consequence of the order problem. That=E2=80=99s a problem spe=
cific to
>> the =E2=80=9Cdouble=E2=80=9D 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 ope=
n
>> was both unnecessary and quite problematic.
>>
>> Emil
>>
>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba 
>> wrote:
>>
>>> "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 wh=
ere
>>> 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 purpose=
s
>>> is to determine whether there is IETF consensus to publish this documen=
t as
>>> a Proposed Standard.  Are you saying that you do not agree that there i=
s an
>>> IETF consensus to publish this document as a Proposed Standard?  Or tha=
t
>>> there is no IETF consensus to publish *any* of the PERC WG output as a
>>> Proposed Standard?
>>>
>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
>>> alex.gouaillard@cosmosoftware.io> wrote:
>>>
>>>> +1 on ssrc rewriting, and on the consensus not reached on this and
>>>> other topics.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote:
>>>>
>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>>
>>>> Lorenzo
>>>>
>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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 w=
ith.
>>>>>
>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could no=
t be
>>>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC,=
 regardless of
>>>>> what WG leadership is trying to make everyone believe.
>>>>>
>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>>>> wrote:
>>>>>
>>>>>> 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 d=
oes 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 M=
DD will
>>>>>> switch between the simulcast streams provided by an endpoint, forwar=
ding
>>>>>> only a single stream to other participants, based on the bandwidth,
>>>>>> resolution and framerates.  If rewriting of SSRCs is not possible, d=
o 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 endpo=
ints?
>>>>>> For example, should endpoints expect the MDD to use RID header exten=
sions
>>>>>> 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 con=
tain
>>>>>> holes because of reordering or loss. This not only complicates the
>>>>>> application of RTX, RED and FEC, but also the operation of the endpo=
int.
>>>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, sup=
port
>>>>>> 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 reorde=
ring.
>>>>>> And neither implementation supports the RID header extension on rece=
ived
>>>>>> simulcast streams.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>>>
>>>>>>> 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 th=
ose
>>>>>>>    which cannot be authenticated and thus are untrusted.
>>>>>>>
>>>>>>>
>>>>>>> WebRTC already IdP as trusted for identity purposes, so it should b=
e
>>>>>>> up to the RTCWEB group to decide what is a trusted endpoint and wha=
t is not
>>>>>>> in webrtc. As Bernard is stating, we could decide that there are ot=
her key
>>>>>>> management solutions trusted (even in JS or WASM), as for for examp=
le is
>>>>>>> being done in EME:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.md=
#encryption
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Sergio
>>>>>>> _______________________________________________
>>>>>>> Perc mailing list
>>>>>>> Perc@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>
>>>>>> --
>>>>> sent from my mobile
>>>>>
>>>>
>>>> --
>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=
=C3=A0.
>>>>
>>>> --
>> sent from my mobile
>>
> --
sent from my mobile

--000000000000a57e910580eccad1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




<=
div>
On Sat 2 Feb 2019 at 16:50, Bernard Aboba <bernard.aboba@gmail.c=
om> wrote:
=
Emil said:

"The need to do a triple encryption for =
example is a particularly egregious consequence of the order problem. That=
=E2=80=99s a problem specific to the =E2=80=9Cdouble=E2=80=9D documents.&qu=
ot;

[BA] Can you describe how the need for "t=
riple encryption" arises?=C2=A0 The framework document doesn't eve=
n mention the issues with ordering of FEC/RTX/RED and encryption, let alone=
 the need for "triple encryption".=C2=A0
=


=
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 co=
de itself and by simply replacing the libsrtp library with a PERC-enabled o=
ne.=C2=A0

I don=E2=80=99=
t know that this goal is a direct consequence of the framework=E2=80=99s co=
nceptual approach (contrary to the imposition of key distribution and negot=
iation). I think it simply carries a promise for some minimal pragmatic val=
ue to some implementers.

The issue with this approach is that it leaves hop-by-hop protection mecha=
nisms such FEC and RTC unavailable to the SFU as they are usually performed=
 before SRTP, which would make them e2e encrypted.
<=
br>
The solution to that is simple. One merely needs=
 to perform e2e encryption first, then apply FEC and/or RTX and only then a=
pply the second (hop-by-hop) layer of SRTP.

This approach was referred to as =E2=80=9Cwedging RTX a=
nd FEC=E2=80=9D as it places them in between the two encryption operations.=


While wedging appeared =
to have overall support in hallway discussions by all SFU implementors exce=
pt 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.=C2=A0

It was quickly pointed out that this not onl=
y destroys the stated =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=
=80=9Cwell, those of you who use FEC/RTX will simply do a third round of SR=
TP=E2=80=9D, 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


<=
div>

On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org> wrote:
<=
/div>
Yes pretty much those.

The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem specif=
ic to the =E2=80=9Cdouble=E2=80=9D documents.

I would however also say that the decision to bake on=
e specific way of performing key negotiation into the framework rather than=
 leaving it open was both unnecessary and quite problematic.

Emil

On Sat 2 Feb 2019 at 12:23, Bernard Aboba <bernard.aboba@gma=
il.com> wrote:
"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?=C2=A0 I am aware of=
 at least two others where implementers have chosen different paths than in=
 the PERC framework:

* Order of application of enc=
ryption versus FEC/RTX/RED
* Whole frame encryption versus payloa=
d encryption

With respect to consensus, this is IE=
TF last call, one of whose purposes is to determine whether there is IETF c=
onsensus to publish this document as a Proposed Standard.=C2=A0 Are you say=
ing that you do not agree that there is an IETF consensus to publish this d=
ocument as a Proposed Standard?=C2=A0 Or that there is no IETF consensus to=
 publish *any* of the PERC WG output as a Proposed Standard?=C2=A0

On =
Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftwa=
re.io> wrote:
+1 on ssrc rewriting, and on the consensus not reach=
ed on this and other topics.

Sent from my iPhone
=


On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com=
> wrote:

+1, SSR=
C rewriting is pretty much fundamental to all SFUs out there.

Lorenz=
o

Il 2 febbraio 2019 10:19:06 CET, Emil I=
vov <emcho@jitsi.or=
g> ha scritto:


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here, but the docu=
ment should be clearer.=C2=A0 The working group discussed SSRC rewriting se=
veral times, and concluded that SSRC rewriting could not be allowed in this=
 system.=C2=A0 This decision is reflected, e.g., in the fact that the Doubl=
e transform does not allow modification of SSRCs."
[BA]=C2=A0 Not being able to rewrite SSRCs has some major impl=
ications with respect to requirements on PERC endpoints.=C2=A0 Typically to=
day's MDD will switch between the simulcast streams provided by an endp=
oint, forwarding only a single stream to other participants, based on the b=
andwidth, resolution and framerates.=C2=A0 If rewriting of SSRCs is not pos=
sible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements fo=
r endpoints?=C2=A0 For example, should endpoints expect the MDD to use RID =
header extensions to identify the incoming simulcast streams?=C2=A0

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.=C2=
=A0 As a result, as noted in the WEBRTC specification Section 5.4.1, suppor=
t for reception of simulcast is optional. I am aware of two ORTC implementa=
tions that have attempted to support simulcast reception, neither of which =
is robust in scenarios with considerable loss and/or reordering.=C2=A0 And =
neither implementation supports the RID header extension on received simulc=
ast streams.




On Fri, Feb =
1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com=
> wrote:

 =20
   =20
 =20
  

    
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/e=
xplainer.md#encryption

    

    
Best regards

    
Sergio

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 M=
ail. Perdonate la brevit=C3=A0.


-- 
sent=
 from my mobile





-- 
sent from my mobile


--000000000000a57e910580eccad1--


From nobody Sat Feb  2 10:54:06 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED11277CC; Sat,  2 Feb 2019 10:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmtKz9TVudvg; Sat,  2 Feb 2019 10:53:51 -0800 (PST)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590761228B7; Sat,  2 Feb 2019 10:53:51 -0800 (PST)
Received: by mail-vk1-xa2b.google.com with SMTP id n126so2342881vke.12; Sat, 02 Feb 2019 10:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oGSpckQ+JDYyVzeZSD6PWV7PhKRhGGCMXsKyGfNbnrg=; b=JCBx9YerF/oS3WcI5FQwaa4VTy05B4+146S8Wyng9mLtrLiBLJYzmRcmFcZBlgPZU5 D9lMb5271FPHCXCOY/+wmbe1dgUXtFkVB3Gi63QMseaUYr2IaRr3WND7TFosHGStlFBg tRa7pAJ1j6mNSnCF1Z8jEK8TT2UVys7I3Ml1F2T5CO+fYvRVy7pigi5ekUu3WUImYj9d QQ62DajFQuBAtV5o3GAPDQSa+tuZ0KI3ryqZ27niIlPk0wmELkWKAj+fqf9IJwsFDMz8 IwyI7wifsXi9LWzki4IQrUwwtdQBozCyv9B+E+qlnUUAwzS/j1BNC9X+OKl4w+0uj2BL ClEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oGSpckQ+JDYyVzeZSD6PWV7PhKRhGGCMXsKyGfNbnrg=; b=oVUUyQr/Uk5AiSO4Uh7SNU3tFsXljP4cex1Ot0rMmJotmtA7L4aKKQagg2WcYdXBAH gv7wPvBoefMOGxw8ydmIEnVRLNcPqy/5JC32t9Li1yZqtwi0OrD4pqSb3CKIuAmIyIyE iUQDR0hQMsMROitW+e6YUJN/oawIVMh1ZJXXW/OLGbIMabkmONKJ3jLGupJxGO/qgc+F BBD5pWL/mOy80Bpww0D2jC5J46xwjCvsHkPw53YpsLOdYb0kZftrqBz4UYI48LFcEuvX z1emezEs+SR5bG61h1cB70oSCwgR5mGGFXsT52VH/7qP0nmZRNHTlXbH8O1NcLigdD/D pRgA==
X-Gm-Message-State: AJcUukf1YBh9SyM+BGvAS/EbsGRdK+PYL9UQWBbIuk4OnQTc3v4OsXNO Leu6zSrXV0hIIdf8lXxa483vIA5hpSKDR6A2qhM=
X-Google-Smtp-Source: ALg8bN59g4C8LsDemMCtOvEdIDPWok+5+9BBcWdwwbUVqxjLmBlCC1eBWbCUEZepT6qqzbZsg7iEHox9EOsHruSHmzU=
X-Received: by 2002:a1f:f0d:: with SMTP id 13mr19072149vkp.21.1549133629830; Sat, 02 Feb 2019 10:53:49 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>     
In-Reply-To: 
From: Bernard Aboba 
Date: Sat, 2 Feb 2019 13:53:38 -0500
Message-ID: 
To: Emil Ivov 
Cc: Alexandre GOUAILLARD , Emad Omara ,  IETF discussion list , Lorenzo Miniero ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b73ce50580edc744"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 18:53:55 -0000

--000000000000b73ce50580edc744
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Emil said:

"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
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D goal, but also leaves RTX an=
d mostly FEC unprotected
and FEC receivers vulnerable to DoS. To this the proponents of this
approach simply replied with: =E2=80=9Cwell, those of you who use FEC/RTX w=
ill
simply do a third round of SRTP=E2=80=9D, thus arriving at a total of three
encryptions for every packet."

[BA] Thank you for this explanation.  The PERC Framework document has no
discussion of this problem at all.

"The discussions around this topic were highly contentious."

[BA] Since this IETF last call, wherein IETF-wide consensus is to be
determined, I take it you are against the "triple encryption" decision and
believe that FEC/RTX should be applied only to the encrypted payload and
then SRTP applied afterward?







On Sat, Feb 2, 2019 at 12:43 PM Emil Ivov  wrote:

>
>
> On Sat 2 Feb 2019 at 16:50, Bernard Aboba  wrote=
:
>
>> Emil said:
>>
>> "The need to do a triple encryption for example is a particularly
>> egregious consequence of the order problem. That=E2=80=99s a problem spe=
cific to
>> the =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that this goal is a direct consequence of the framew=
ork=E2=80=99s
> 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 encryptio=
n
> 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 =E2=80=9Cwedging RTX and FEC=E2=80=9D 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
> =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC/RTX=
 will
> simply do a third round of SRTP=E2=80=9D, thus arriving at a total of thr=
ee
> encryptions for every packet.
>
> The discussions around this topic were highly contentious.
>
> Hope this makes things clear,
> Emil
>
>
>
>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:
>>
>>> Yes pretty much those.
>>>
>>> The need to do a triple encryption for example is a particularly
>>> egregious consequence of the order problem. That=E2=80=99s a problem sp=
ecific to
>>> the =E2=80=9Cdouble=E2=80=9D 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 op=
en
>>> was both unnecessary and quite problematic.
>>>
>>> Emil
>>>
>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba 
>>> wrote:
>>>
>>>> "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 w=
here
>>>> 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 th=
is
>>>> 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?
>>>>
>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
>>>> alex.gouaillard@cosmosoftware.io> wrote:
>>>>
>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and
>>>>> other topics.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote=
:
>>>>>
>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>>>
>>>>> Lorenzo
>>>>>
>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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 =E2=80=9CSSRC rewriting could n=
ot be
>>>>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC=
, regardless of
>>>>>> what WG leadership is trying to make everyone believe.
>>>>>>
>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>>>>> wrote:
>>>>>>
>>>>>>> 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, forwa=
rding
>>>>>>> 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 d=
o need
>>>>>>> to be able to receive simulcast, what are the requirements for endp=
oints?
>>>>>>> For example, should endpoints expect the MDD to use RID header exte=
nsions
>>>>>>> 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 co=
ntain
>>>>>>> holes because of reordering or loss. This not only complicates the
>>>>>>> application of RTX, RED and FEC, but also the operation of the endp=
oint.
>>>>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, su=
pport
>>>>>>> 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 reord=
ering.
>>>>>>> And neither implementation supports the RID header extension on rec=
eived
>>>>>>> simulcast streams.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>>>>
>>>>>>>> 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 a=
s the
>>>>>>>> Trusted Endpoint for purposes of this framework (just as it acts a=
s 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 tha=
n the
>>>>>>>>    browser.  However, this is unfortunately not possible if we wis=
h 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 t=
hose
>>>>>>>>    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 a=
re 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.m=
d#encryption
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Sergio
>>>>>>>> _______________________________________________
>>>>>>>> Perc mailing list
>>>>>>>> Perc@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>>
>>>>>>> --
>>>>>> sent from my mobile
>>>>>>
>>>>>
>>>>> --
>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=
=C3=A0.
>>>>>
>>>>> --
>>> sent from my mobile
>>>
>> --
> sent from my mobile
>

--000000000000b73ce50580edc744
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Emil said:=C2=A0

"Applications wil=
l apply SRTP-double first and, those that need to use FEC and RTX would hav=
e to apply them only after.=C2=A0

It =
was quickly pointed out that this not only destroys the stated =E2=80=9Cdon=
=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC=
/RTX will simply do a third round of SRTP=E2=80=9D, thus arriving at a tota=
l of three encryptions for every packet."

[BA=
] Thank you for this explanation.=C2=A0 The PERC Framework document has no =
discussion of this problem at all.=C2=A0

"The=
 discussions around this topic were highly contentious."
[BA] Since this IETF last call, wherein IETF-wide consensus is =
to be determined, I take it you are against the "triple encryption&quo=
t; decision and believe that FEC/RTX should be applied only to the encrypte=
d payload and then SRTP applied afterward?=C2=A0

<=
br>




=

On Sat=
, Feb 2, 2019 at 12:43 PM Emil Ivov <=
emcho@jitsi.org> wrote:


On Sat 2 Feb 2019 at 16:50, Bernard Abo=
ba <bernard=
.aboba@gmail.com> wrote:
Emil said:

"The ne=
ed to do a triple encryption for example is a particularly egregious conseq=
uence of the order problem. That=E2=80=99s a problem specific to the =E2=80=
=9Cdouble=E2=80=9D documents."

[BA] Can you d=
escribe how the need for "triple encryption" arises?=C2=A0 The fr=
amework document doesn't even mention the issues with ordering of FEC/R=
TX/RED and encryption, let alone the need for "triple encryption"=
.=C2=A0

One of the goals that some members of the g=
roup seemed to have was to allow specific applications to become PERC-compl=
iant without changing the app code itself and by simply replacing the libsr=
tp library with a PERC-enabled one.=C2=A0

=

I don=E2=80=99t know that this goal is a direct consequen=
ce of the framework=E2=80=99s conceptual approach (contrary to the impositi=
on of key distribution and negotiation). I think it simply carries a promis=
e for some minimal pragmatic value to some implementers.

The issue with this approach is that it le=
aves hop-by-hop protection mechanisms such FEC and RTC unavailable to the S=
FU as they are usually performed before SRTP, which would make them e2e enc=
rypted.

The solution to =
that is simple. One merely needs to perform e2e encryption first, then appl=
y FEC and/or RTX and only then apply the second (hop-by-hop) layer of SRTP.=


This approach was refer=
red to as =E2=80=9Cwedging RTX and FEC=E2=80=9D as it places them in betwee=
n the two encryption operations.

While wedging appeared to have overall support in hallway discuss=
ions by all SFU implementors except potentially one, it was mysteriously re=
jected by a subset of the WG and replaced with the following:

Applications will apply SRTP-double f=
irst and, those that need to use FEC and RTX would have to apply them only =
after.=C2=A0

It was quic=
kly pointed out that this not only destroys the stated =E2=80=9Cdon=E2=80=
=99t-change-the-app=E2=80=9D goal, but also leaves RTX and mostly FEC unpro=
tected and FEC receivers vulnerable to DoS. To this the proponents of this =
approach simply replied with: =E2=80=9Cwell, those of you who use FEC/RTX w=
ill simply do a third round of SRTP=E2=80=9D, thus arriving at a total of t=
hree encryptions for every packet.

The discussions around this topic were highly contentious.
=


Hope this makes things clear,=

Emil


On Sat, =
Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org> wrote:
Yes pretty much tho=
se.

The need to do=
 a triple encryption for example is a particularly egregious consequence of=
 the order problem. That=E2=80=99s a problem specific to the =E2=80=9Cdoubl=
e=E2=80=9D documents.

I =
would however also say that the decision to bake one specific way of perfor=
ming key negotiation into the framework rather than leaving it open was bot=
h unnecessary and quite problematic.

Emil

On Sat 2 Feb 2019 at 12:23, Bernard Aboba <bernard.aboba@gmail.com> wrote:
=

&q=
uot;on the consensus not reached on this and other topics."

[BA] Out of curiosity, what other topics do you consider to be pro=
blematic within the framework?=C2=A0 I am aware of at least two others wher=
e implementers have chosen different paths than in the PERC framework:

* Order of application of encryption versus FEC/RTX/RE=
D
* Whole frame encryption versus payload encryption
With respect to consensus, this is IETF last call, one of whos=
e purposes is to determine whether there is IETF consensus to publish this =
document as a Proposed Standard.=C2=A0 Are you saying that you do not agree=
 that there is an IETF consensus to publish this document as a Proposed Sta=
ndard?=C2=A0 Or that there is no IETF consensus to publish *any* of the PER=
C WG output as a Proposed Standard?=C2=A0

On Sat, Feb 2, 2019 at 5:40 =
AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io> wrote:
<=
/div>
+1=
 on ssrc rewriting, and on the consensus not reached on this and other topi=
cs.

Sent from my iPhone

On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com=
> wrote:

+1, SSR=
C rewriting is pretty much fundamental to all SFUs out there.

Lorenz=
o

Il 2 febbraio 2019 10:19:06 CET, Emil I=
vov <emcho@jitsi.or=
g> ha scritto:


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here, but the docu=
ment should be clearer.=C2=A0 The working group discussed SSRC rewriting se=
veral times, and concluded that SSRC rewriting could not be allowed in this=
 system.=C2=A0 This decision is reflected, e.g., in the fact that the Doubl=
e transform does not allow modification of SSRCs."
[BA]=C2=A0 Not being able to rewrite SSRCs has some major impl=
ications with respect to requirements on PERC endpoints.=C2=A0 Typically to=
day's MDD will switch between the simulcast streams provided by an endp=
oint, forwarding only a single stream to other participants, based on the b=
andwidth, resolution and framerates.=C2=A0 If rewriting of SSRCs is not pos=
sible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements fo=
r endpoints?=C2=A0 For example, should endpoints expect the MDD to use RID =
header extensions to identify the incoming simulcast streams?=C2=A0

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.=C2=
=A0 As a result, as noted in the WEBRTC specification Section 5.4.1, suppor=
t for reception of simulcast is optional. I am aware of two ORTC implementa=
tions that have attempted to support simulcast reception, neither of which =
is robust in scenarios with considerable loss and/or reordering.=C2=A0 And =
neither implementation supports the RID header extension on received simulc=
ast streams.




On Fri, Feb =
1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com=
> wrote:

 =20
   =20
 =20
  

    
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 t=
rust 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@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
se=
nt from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 M=
ail. Perdonate la brevit=C3=A0.


-- 
sent from my mobile




-- 
sent from my mobile



--000000000000b73ce50580edc744--


From nobody Sat Feb  2 11:08:18 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331FF1228B7 for ; Sat,  2 Feb 2019 11:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level: 
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTnUv_yqUEhk for ; Sat,  2 Feb 2019 11:08:06 -0800 (PST)
Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629A31277CC for ; Sat,  2 Feb 2019 11:08:06 -0800 (PST)
Received: by mail-vs1-xe42.google.com with SMTP id t17so6261664vsc.8 for ; Sat, 02 Feb 2019 11:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xhx39yTIz6c9yDM5RUtmgeCrs8oCjei3eD0KLPyZ0e0=; b=WiEF1Ytf2DbGTd+CoZq0vm/X9qJaCNKmjgHymFp/RSuoZNq4Y27Q6NK8+Scc+sQ0nN AJk4EdBpejGecepmLUI1GksgEuMIay71dIT8uAy9EEivog3deoEj1LTMWP6eBL3jR0Nt 8w1JvL+5QunNTvqkbIbtOTSak5uoJFrbptlQePN5AyJwLwO89I4uETo8PK2O0FfA9ez0 gC2vMDdb8hjeKql0plh0qigLs1/4VjcEUpHmn4UzyRCKdpz3dJd0wnAOkr2UIXyGHFt+ WC9NPRNWVbl7xX1F6vyqBR4X1hQChnf3drueVf5/3Fz1sKBn/K3vUKzhAjNvhp5pzzCh 1r8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xhx39yTIz6c9yDM5RUtmgeCrs8oCjei3eD0KLPyZ0e0=; b=Mpy085e1G9aKGKs5P32dmFQPaGP6Lu02JwSJprsqbaCezraIsOb1w+lAaHReXYCrX3 VCr0aaii85xzm9jYGL+hTMmXJw9Ri+VzGAPrMwK5K/iQGLsJmBLOmS9hCbfhdJf2am0Q rmkRooRgw8TOtFlNjzV0hASuLwyAUxo8UWht64xoVFl0owpvjDX1D6DGTyko52+TMOQN JVM0X0JaVSKJV8bf+eQD0GaeFfIEg0Wj10faTjcz3lGyZH+qKmDIx9vmOHOp1BYbmn46 b3u35xLKrwgjymGCYYjESYWuKbWA3JL6Lsqe53lkS0sMz9iwiuIL3HXgYBxjH6IFZUpU P78g==
X-Gm-Message-State: AJcUukdm2/Noy38SSTW9bgbKwNCZYvDBWFUeR4zsAJp6v+dtGl+XQGVl KzCAOVzXNlwME31QqMwXMgx+TaE5XvknnNIkJkfqxw==
X-Google-Smtp-Source: ALg8bN6lzb65zttb4Bp/55yOdjzvdCUe4lWmSNUbPRaw/PMjHjsIjLMntm8tiUqjjhecGg+bEXk1lh64srY3hAvci94=
X-Received: by 2002:a67:784e:: with SMTP id t75mr17652011vsc.236.1549134484935;  Sat, 02 Feb 2019 11:08:04 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>      
In-Reply-To: 
From: Emil Ivov 
Date: Sat, 2 Feb 2019 19:07:52 +0000
Message-ID: 
To: Bernard Aboba 
Cc: Alexandre GOUAILLARD , Emad Omara ,  IETF discussion list , Lorenzo Miniero ,  Sergio Garcia Murillo , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000af3c230580edfa3a"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 19:08:11 -0000

--000000000000af3c230580edfa3a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat 2 Feb 2019 at 18:53, Bernard Aboba  wrote:

> Emil said:
>
> "Applications will apply SRTP-double first and, those that need to use FE=
C
> and RTX would have to apply them only after.
>
> It was quickly pointed out that this not only destroys the stated
> =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC/RTX=
 will
> simply do a third round of SRTP=E2=80=9D, thus arriving at a total of thr=
ee
> encryptions for every packet."
>
> [BA] Thank you for this explanation.  The PERC Framework document has no
> discussion of this problem at all.
>
> "The discussions around this topic were highly contentious."
>
> [BA] Since this IETF last call, wherein IETF-wide consensus is to be
> determined, I take it you are against the "triple encryption" decision an=
d
> believe that FEC/RTX should be applied only to the encrypted payload and
> then SRTP applied afterward?
>

That is correct.

Emil


>
>
>
>
>
>
> On Sat, Feb 2, 2019 at 12:43 PM Emil Ivov  wrote:
>
>>
>>
>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba 
>> wrote:
>>
>>> Emil said:
>>>
>>> "The need to do a triple encryption for example is a particularly
>>> egregious consequence of the order problem. That=E2=80=99s a problem sp=
ecific to
>>> the =E2=80=9Cdouble=E2=80=9D 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 th=
e
>> app code itself and by simply replacing the libsrtp library with a
>> PERC-enabled one.
>>
>> I don=E2=80=99t know that this goal is a direct consequence of the frame=
work=E2=80=99s
>> 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 seco=
nd
>> (hop-by-hop) layer of SRTP.
>>
>> This approach was referred to as =E2=80=9Cwedging RTX and FEC=E2=80=9D a=
s 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 rejecte=
d
>> by a subset of the WG and replaced with the following:
>>
>> Applications will apply SRTP-double first and, those that need to use FE=
C
>> and RTX would have to apply them only after.
>>
>> It was quickly pointed out that this not only destroys the stated
>> =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC/RT=
X will
>> simply do a third round of SRTP=E2=80=9D, thus arriving at a total of th=
ree
>> encryptions for every packet.
>>
>> The discussions around this topic were highly contentious.
>>
>> Hope this makes things clear,
>> Emil
>>
>>
>>
>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:
>>>
>>>> Yes pretty much those.
>>>>
>>>> The need to do a triple encryption for example is a particularly
>>>> egregious consequence of the order problem. That=E2=80=99s a problem s=
pecific to
>>>> the =E2=80=9Cdouble=E2=80=9D 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 o=
pen
>>>> was both unnecessary and quite problematic.
>>>>
>>>> Emil
>>>>
>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba 
>>>> wrote:
>>>>
>>>>> "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 t=
his
>>>>> document as a Proposed Standard.  Are you saying that you do not agre=
e 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?
>>>>>
>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
>>>>> alex.gouaillard@cosmosoftware.io> wrote:
>>>>>
>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and
>>>>>> other topics.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero 
>>>>>> wrote:
>>>>>>
>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>>>>
>>>>>> Lorenzo
>>>>>>
>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  ha
>>>>>> scritto:
>>>>>>>
>>>>>>> I want to second that as it is a particularly major problem: not
>>>>>>> allowing SSRC rewriting makes the entire framework unusable with SF=
U
>>>>>>> implementation I represent as well as every other SFU I am familiar=
 with.
>>>>>>>
>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could =
not be
>>>>>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PER=
C, regardless of
>>>>>>> what WG leadership is trying to make everyone believe.
>>>>>>>
>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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, forw=
arding
>>>>>>>> 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 end=
points?
>>>>>>>> For example, should endpoints expect the MDD to use RID header ext=
ensions
>>>>>>>> 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 c=
ontain
>>>>>>>> holes because of reordering or loss. This not only complicates the
>>>>>>>> application of RTX, RED and FEC, but also the operation of the end=
point.
>>>>>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, s=
upport
>>>>>>>> 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 reor=
dering.
>>>>>>>> And neither implementation supports the RID header extension on re=
ceived
>>>>>>>> simulcast streams.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> 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 th=
an the
>>>>>>>>>    browser.  However, this is unfortunately not possible if we wi=
sh to
>>>>>>>>>    have a functional system.  Other network elements fall into tw=
o
>>>>>>>>>    categories: those which can be authenticated by the browser an=
d 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 an=
d 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@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>>>
>>>>>>>> --
>>>>>>> sent from my mobile
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la
>>>>>> brevit=C3=A0.
>>>>>>
>>>>>> --
>>>> sent from my mobile
>>>>
>>> --
>> sent from my mobile
>>
> --
sent from my mobile

--000000000000af3c230580edfa3a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat =
2 Feb 2019 at 18:53, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Emil said:=C2=A0

"Appli=
cations will apply SRTP-double first and, those that need to use FEC and RT=
X would have to apply them only after.=C2=A0

It was quickly pointed out that this not only destroys the stated =
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D goal, but also leaves RTX an=
d mostly FEC unprotected and FEC receivers vulnerable to DoS. To this the p=
roponents of this approach simply replied with: =E2=80=9Cwell, those of you=
 who use FEC/RTX will simply do a third round of SRTP=E2=80=9D, thus arrivi=
ng at a total of three encryptions for every packet."

[BA] Thank you for this explanation.=C2=A0 The PERC Framework docu=
ment has no discussion of this problem at all.=C2=A0

"The discussions around this topic were highly contentious."

[BA] Since this IETF last call, wherein IETF-wide c=
onsensus is to be determined, I take it you are against the "triple en=
cryption" decision and believe that FEC/RTX should be applied only to =
the encrypted payload and then SRTP applied afterward?=C2=A0

That is correct.

Emil








On Sat, Feb 2, 2019 at 12:43 PM Emil Ivov <emcho@jitsi.org> wrote:
=


=

On S=
at 2 Feb 2019 at 16:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Emil sa=
id:

"The need to do a triple encryption for example=
 is a particularly egregious consequence of the order problem. That=E2=80=
=99s a problem specific to the =E2=80=9Cdouble=E2=80=9D documents."

[BA] Can you describe how the need for "triple =
encryption" arises?=C2=A0 The framework document doesn't even ment=
ion the issues with ordering of FEC/RTX/RED and encryption, let alone the n=
eed for "triple encryption".=C2=A0

One of=
 the goals that some members of the group seemed to have was to allow speci=
fic applications to become PERC-compliant without changing the app code its=
elf and by simply replacing the libsrtp library with a PERC-enabled one.=C2=
=A0

I don=E2=80=99t know=
 that this goal is a direct consequence of the framework=E2=80=99s conceptu=
al 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 i=
ssue 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 befor=
e SRTP, which would make them e2e encrypted.

The solution to that is simple. One merely needs to pe=
rform e2e encryption first, then apply FEC and/or RTX and only then apply t=
he second (hop-by-hop) layer of SRTP.

This approach was referred to as =E2=80=9Cwedging RTX and FEC=
=E2=80=9D as it places them in between the two encryption operations.
=


While wedging appeared to hav=
e overall support in hallway discussions by all SFU implementors except pot=
entially one, it was mysteriously rejected by a subset of the WG and replac=
ed with the following:

A=
pplications will apply SRTP-double first and, those that need to use FEC an=
d RTX would have to apply them only after.=C2=A0
It was quickly pointed out that this not only dest=
roys the stated =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D goal, but al=
so leaves RTX and mostly FEC unprotected and FEC receivers vulnerable to Do=
S. To this the proponents of this approach simply replied with: =E2=80=9Cwe=
ll, those of you who use FEC/RTX will simply do a third round of SRTP=E2=80=
=9D, thus arriving at a total of three encryptions for every packet.
<=
div dir=3D"auto">
The discussions around this to=
pic were highly contentious.

Hope this makes things clear,
Emil



On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org> w=
rote:
Yes pretty much those.

=

The need to do a triple encryption for example is a parti=
cularly egregious consequence of the order problem. That=E2=80=99s a proble=
m specific to the =E2=80=9Cdouble=E2=80=9D documents.

I would however also say that the decision to=
 bake one specific way of performing key negotiation into the framework rat=
her than leaving it open was both unnecessary and quite problematic.
<=
div dir=3D"auto">
Emil

On Sat 2 Feb 2019 at 12:23, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
"on the consensus not reached on this a=
nd other topics."

[BA] Out of curiosity, what other=
 topics do you consider to be problematic within the framework?=C2=A0 I am =
aware of at least two others where implementers have chosen different paths=
 than in the PERC framework:

* Order of applicatio=
n of encryption versus FEC/RTX/RED
* Whole frame encryption versu=
s payload encryption

With respect to consensus, th=
is is IETF last call, one of whose purposes is to determine whether there i=
s IETF consensus to publish this document as a Proposed Standard.=C2=A0 Are=
 you saying that you do not agree that there is an IETF consensus to publis=
h this document as a Proposed Standard?=C2=A0 Or that there is no IETF cons=
ensus to publish *any* of the PERC WG output as a Proposed Standard?=C2=A0<=
/div>

On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cos=
mosoftware.io> wrote:
+1 on ssrc rewriting, and on the consensus n=
ot reached on this and other topics.

Sent from my iPhone
<=
br>On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

<=
/div>
+1, SSRC rewriting is prett=
y much fundamental to all SFUs out there.

Lorenzo

Il 2 febbraio 2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org> ha scritt=
o:


I want to second that as it is a particularly major =
problem: not allowing SSRC rewriting makes the entire framework unusable wi=
th SFU implementation I represent as well as every other SFU I am familiar =
with.

I am also no=
t sure that I agree with =E2=80=9CSSRC rewriting could not be allowed=E2=80=
=9D is a conclusion that ever had any consensus in PERC, regardless of what=
 WG leadership is trying to make everyone believe.

On Sat 2 Feb 2019 at 06:21, Bernard Aboba=
 <bernard.a=
boba@gmail.com> wrote:
Richard said:

"Again, the answer is clear here, but the docu=
ment should be clearer.=C2=A0 The working group discussed SSRC rewriting se=
veral times, and concluded that SSRC rewriting could not be allowed in this=
 system.=C2=A0 This decision is reflected, e.g., in the fact that the Doubl=
e transform does not allow modification of SSRCs."
[BA]=C2=A0 Not being able to rewrite SSRCs has some major impl=
ications with respect to requirements on PERC endpoints.=C2=A0 Typically to=
day's MDD will switch between the simulcast streams provided by an endp=
oint, forwarding only a single stream to other participants, based on the b=
andwidth, resolution and framerates.=C2=A0 If rewriting of SSRCs is not pos=
sible, do PERC endpoints need to be able to receive simulcast? If PERC endp=
oints do need to be able to receive simulcast, what are the requirements fo=
r endpoints?=C2=A0 For example, should endpoints expect the MDD to use RID =
header extensions to identify the incoming simulcast streams?=C2=A0

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.=C2=
=A0 As a result, as noted in the WEBRTC specification Section 5.4.1, suppor=
t for reception of simulcast is optional. I am aware of two ORTC implementa=
tions that have attempted to support simulcast reception, neither of which =
is robust in scenarios with considerable loss and/or reordering.=C2=A0 And =
neither implementation supports the RID header extension on received simulc=
ast streams.




On Fri, Feb =
1, 2019 at 12:23 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com=
> wrote:

 =20
   =20
 =20
  

    
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/h=
tml/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@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
sent from my mobile



-- 
Inviato dal mio dispositivo Android con K-9 M=
ail. Perdonate la brevit=C3=A0.


-- 
sent from my mobile





-- 
sent from my mobile


-- 
sent from my mobile


--000000000000af3c230580edfa3a--


From nobody Sat Feb  2 12:27:04 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7611C130E68; Sat,  2 Feb 2019 12:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncuG6iwXYYZC; Sat,  2 Feb 2019 12:26:59 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA65130E64; Sat,  2 Feb 2019 12:26:58 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id r24so7058615wmh.0; Sat, 02 Feb 2019 12:26:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=n3OW/5XU7wMKLMmGgrvWrhIE1K4KFSWAFgRtx7+Sgak=; b=NzRGCXEdTtyNGWB7GXmgM0KkTdDHJsjpfLpFs+Zy1QkO9eMxM4pXmDu/tYNPJG4rmp ZxdvfwT3O3yKjemAtN3XejNtUI0uosnypOVuMPajmP14aofu7mno/sSYFEJEXj0M+dBf FfY3dTteO6HV55aJ2e7xrjgWTGmPdRwcDUGefND7cU4e/7nM9Xd3Xv5RK8H2hSIrfr5v M1uNQ+Eb2s+aQ0FPg2dPDdxcggq2/aK+sbcrMySXmdRXRCGM7q9WjvdSEUwOj1nU/9Mc BBJDLntSxeEhqwhGp0vu/Y0YTIWgSZLL9ScA+dECsXGrMmVSaXKOyzxrt6kbo/mxmymD w+Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=n3OW/5XU7wMKLMmGgrvWrhIE1K4KFSWAFgRtx7+Sgak=; b=NQtodgL255fM1YHxLL4Miphc78bgkKd134ek+ODDIcMPR45vx26+mmM6yV8ujWv0l0 +kjYhnJLHZlpIgQOCkl1KRWBl7oA+ZcAiSvJqdRw70Oka2L5gUz5IIyqldLgs3M+SXOX hsliLjgVxWJqqKKrE/vBnAO4DSyjFEr99hjfSuyq0BEnUZd+AiXT2UrG8M78sAZwPdFD NOr7bmE696atmpN5kh7Cwg0ZXXljPr8Wbfe+R2U8UxSFv8lT8NEnoV/N9v9Etn/1cxzv QgMYjp4nWRU3dve8vx4pc0wMByLUtddodeg5v52OJYDYm/H255A6hFKS/d0Vc+pEpImK 9npA==
X-Gm-Message-State: AHQUAubPbVe7kWcQiO60Nf1sRWz34zPz2hv/ZeVx1h5XBUXXzjYYfgji gNYseoHD6clfuNsPENCBd3U=
X-Google-Smtp-Source: AHgI3IZN5uJr9EaCb8Tu5XFv8ZGcRWXgswSptnlsisKooNpm89FM7XpG3nMA2yHaR3P3fsBeq1VQYA==
X-Received: by 2002:a1c:c543:: with SMTP id v64mr7003725wmf.123.1549139216908;  Sat, 02 Feb 2019 12:26:56 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id o8sm14425719wrx.15.2019.02.02.12.26.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 12:26:56 -0800 (PST)
To: Emil Ivov , Bernard Aboba 
Cc: Alexandre GOUAILLARD , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Sergio Garcia Murillo , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>     
From: Sergio Garcia Murillo 
Message-ID: 
Date: Sat, 2 Feb 2019 21:31:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A93F58CFC5624C20D7DF0060"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 20:27:04 -0000

This is a multi-part message in MIME format.
--------------A93F58CFC5624C20D7DF0060
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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:
>
>
> On Sat 2 Feb 2019 at 16:50, Bernard Aboba  > 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
>
>
>
>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov      > wrote:
>
>         Yes pretty much those.
>
>         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 Sat 2 Feb 2019 at 12:23, Bernard Aboba
>         > wrote:
>
>             "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?
>
>             On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD
>                          > wrote:
>
>                 +1 on ssrc rewriting, and on the consensus not reached
>                 on this and other topics.
>
>                 Sent from my iPhone
>
>                 On 2 Feb 2019, at 17:18, Lorenzo Miniero
>                 >
>                 wrote:
>
>>                 +1, SSRC rewriting is pretty much fundamental to all
>>                 SFUs out there.
>>
>>                 Lorenzo
>>
>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>                 > 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.
>>
>>                     On Sat 2 Feb 2019 at 06:21, Bernard Aboba
>>                     >                     > wrote:
>>
>>                         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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia
>>                         Murillo >                         > wrote:
>>
>>                             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@ietf.org 
>>                             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@ietf.org
> https://www.ietf.org/mailman/listinfo/perc



--------------A93F58CFC5624C20D7DF0060
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
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:

    

    

      
      

        


        

        


        

      

      

        
On Sat 2 Feb 2019 at 16:50, Bernard Aboba <bernard.aboba@gmail.com>
          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

          


          

          


          

        

      

      

        

          

            


              

                
On Sat, Feb 2, 2019 at
                  11:46 AM Emil Ivov <emcho@jitsi.org>
                  wrote:

                

                

                  

                    
Yes pretty much those.

                  

                  


                  

                  
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 Sat 2 Feb 2019 at 12:23, Bernard
                        Aboba <bernard.aboba@gmail.com>
                        wrote:

                      

                      

                        
"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? 

                        

                        

                        

                          
On Sat, Feb
                            2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>
                            wrote:

                          

                          

                            
+1 on ssrc rewriting, and on
                              the consensus not reached on this and
                              other topics.

                              

                              
Sent from my iPhone

                              


                                On 2 Feb 2019, at 17:18, Lorenzo Miniero
                                <lorenzo@meetecho.com>
                                wrote:

                                

                              

                              

                                
+1, SSRC rewriting is
                                  pretty much fundamental to all SFUs
                                  out there.

                                  

                                  Lorenzo

                                  

                                  
Il 2 febbraio
                                    2019 10:19:06 CET, Emil Ivov <emcho@jitsi.org>
                                    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.

                                      


                                        

                                          
On Sat 2 Feb
                                            2019 at 06:21, Bernard Aboba
                                            <bernard.aboba@gmail.com>
                                            wrote:

                                          

                                          

                                            
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
                                                Fri, Feb 1, 2019 at
                                                12:23 PM Sergio Garcia
                                                Murillo <sergio.garcia.murillo@gmail.com>
                                                wrote:

                                              

                                              

                                                

                                                  
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@ietf.org

                                                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@ietf.org
https://www.ietf.org/mailman/listinfo/perc


    

    


    

  


--------------A93F58CFC5624C20D7DF0060--


From nobody Sat Feb  2 12:43:04 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7790012F1AB; Sat,  2 Feb 2019 12:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W3zyDHfkWei; Sat,  2 Feb 2019 12:42:51 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE44130E6D; Sat,  2 Feb 2019 12:42:51 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id s76so653306ybs.10; Sat, 02 Feb 2019 12:42:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wM5K3DyEdJ1UJUK+K64sWjhZbAcDQ7t2uKv9G119VZE=; b=IdmzA6uGPXZcyhEabUwiLZfPfpPJn51VEPz5SWwLOXh75I71/6o2/HB3p+4VnCyJUp 7eTrW4yvv4ExDpv2rHgRJ3OcY8O3jxKDyW+F+peM4pbQkvi5SnIPDNnfNTyzXzqSIxHh OJz76ySICuAgVY6x6tENSrdnL2Emdhp1UxaOGwZqvMdl5VXWdVbICA4RxZe+5BYP511A X9tRxupMvCM3m3RE/06V74gwvD3lvSNssEK809krlr4fKr8oYufLiv1Y8SIn8imdkE6f XY+XUlfdyLcE7dvhPs0LTIfwfkAhtL7R/wilRKSrdnX5WzYEkMHfgvWuBopwZwP+75BB hbFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wM5K3DyEdJ1UJUK+K64sWjhZbAcDQ7t2uKv9G119VZE=; b=HoRqu2RliD0O53wcyiv9SCFllhSt7Oz3U1Tfi8rPJABvJw9+vi5GrW/2vyxNdi3Dzz xn2+284segowmpJyuv1KCPFx7ywEmc2iMlXG50D5JOyfzM+/Rc2JzThGy8z2Rwm2dB9b lJ1OXPSASbH7QAjTFUHQqhwTkyMFu82KernC9hNxxN5k7o5q7LtxvVmAWfFpOvmWgMNb k1EeM5L4VekCMHvAo7u4aQfUGJOgqveCo02oWo/OeT/Y1Px5FLjGmctoRlO4mxevT9Or DuO3hgE4o5gly2sJG+Wmk1O7oEgn/o/DkeUVsxZvoQ7IUI1mVmxelI8AUNnoCNZxzflm 5PAA==
X-Gm-Message-State: AHQUAuYSncC8nkv74H7QftiJWVUJAtkfBW0auQz6fxhl9oqBcFh3QjQu hpzb62wcKX48k8dGSxFM2QlUm5kC
X-Google-Smtp-Source: AHgI3IZdOui0XxByUMTRS+ZASSmTTcqJNT71WBa+ppNuncDGUaojLgWWfKvyG8syBdlXgNMHtJWKcA==
X-Received: by 2002:a25:76d0:: with SMTP id r199mr10838918ybc.70.1549140170047;  Sat, 02 Feb 2019 12:42:50 -0800 (PST)
Received: from ?IPv6:2600:380:4d18:80a5:b191:5743:b4d3:96d3? ([2600:380:4d18:80a5:b191:5743:b4d3:96d3]) by smtp.gmail.com with ESMTPSA id z2sm4248257ywe.32.2019.02.02.12.42.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 12:42:48 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-91A19C17-CF5D-4C74-B994-FF36330BF48C
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (16D39)
In-Reply-To: 
Date: Sat, 2 Feb 2019 15:42:46 -0500
Cc: Emil Ivov , Alexandre GOUAILLARD , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Sergio Garcia Murillo , Lorenzo Miniero 
Content-Transfer-Encoding: 7bit
Message-Id: <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com>
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>      
To: Sergio Garcia Murillo 
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 20:42:56 -0000

--Apple-Mail-91A19C17-CF5D-4C74-B994-FF36330BF48C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sergio -

In your opinion, what portions of PERC are salvageable, if any? Is this a si=
tuation where we need to start over or could some aspect of PERC (e.g. Doubl=
e if the triple encryption problem were fixed) be suitably modified and then=
 implemented?

> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo  wrote:
>=20
> I think Emil and Bernard have described quite precisely where we are and h=
ow we managed to get here.
>=20
> 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.
>=20
> Speaking from a WebRTC perspective, PERC, apart of have taken some controv=
ersial technical decisions (OHB as header, the ssrc rewriting issue and reve=
rse 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 t=
his group), like the role of the js app, the possibility of allowing key man=
agement in js, or the interaction with Idp and isolated media streams. Not t=
o speak about the recent discussions about full frame vs per packet encrypti=
on or QUIC.
>=20
> Best regards
> Sergio
>=20
>=20
>> On 02/02/2019 18:42, Emil Ivov wrote:
>>=20
>>=20
>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba  wrot=
e:
>>> Emil said:
>>>=20
>>> "The need to do a triple encryption for example is a particularly egregi=
ous consequence of the order problem. That=E2=80=99s a problem specific to t=
he =E2=80=9Cdouble=E2=80=9D documents."
>>>=20
>>> [BA] Can you describe how the need for "triple               encryption"=
 arises?  The framework document doesn't even mention the issues with orderi=
ng of FEC/RTX/RED and encryption, let alone the need for "triple encryption"=
.=20
>>=20
>> One of the goals that some members of the group seemed to have was to all=
ow specific applications to become PERC-compliant without changing the app c=
ode itself and by simply replacing the libsrtp library with a PERC-enabled o=
ne.=20
>>=20
>> I don=E2=80=99t know that this goal is a direct consequence of the framew=
ork=E2=80=99s conceptual approach (contrary to the imposition of key distrib=
ution and negotiation). I think it simply carries a promise for some minimal=
 pragmatic value to some implementers.
>>=20
>> The issue with this approach is that it leaves hop-by-hop protection mech=
anisms such FEC and RTC unavailable to the SFU as they are usually performed=
 before SRTP, which would make them e2e encrypted.
>>=20
>> The solution to that is simple. One merely needs to perform e2e encryptio=
n first, then apply FEC and/or RTX and only then apply the second (hop-by-ho=
p) layer of SRTP.
>>=20
>> This approach was referred to as =E2=80=9Cwedging RTX and FEC=E2=80=9D as=
 it places them in between the two encryption operations.
>>=20
>> While wedging appeared to have overall support in hallway discussions by a=
ll SFU implementors except potentially one, it was mysteriously rejected by a=
 subset of the WG and replaced with the following:
>>=20
>> Applications will apply SRTP-double first and, those that need to use FEC=
 and RTX would have to apply them only after.=20
>>=20
>> It was quickly pointed out that this not only destroys the stated =E2=80=9C=
don=E2=80=99t-change-the-app=E2=80=9D goal, but also leaves RTX and mostly FE=
C unprotected and FEC receivers vulnerable to DoS. To this the proponents of=
 this approach simply replied with: =E2=80=9Cwell, those of you who use FEC/=
RTX will simply do a third round of SRTP=E2=80=9D, thus arriving at a total o=
f three encryptions for every packet..
>>=20
>> The discussions around this topic were highly contentious.
>>=20
>> Hope this makes things clear,
>> Emil
>>=20
>>=20
>>>=20
>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:
>>>> Yes pretty much those.
>>>>=20
>>>> The need to do a triple encryption for example is a particularly egregi=
ous consequence of the order problem. That=E2=80=99s a problem specific to t=
he =E2=80=9Cdouble=E2=80=9D documents.
>>>>=20
>>>> I would however also say that the decision to bake one specific way of p=
erforming key negotiation into the framework rather than leaving it open was=
 both unnecessary and quite problematic.
>>>>=20
>>>> Emil
>>>>=20
>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba  wr=
ote:
>>>>> "on the consensus not reached on this and other topics."
>>>>>=20
>>>>> [BA] Out of curiosity, what other topics do you consider to be problem=
atic within the framework?  I am aware of at least two others where implemen=
ters have chosen different paths than in the PERC framework:
>>>>>=20
>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>> * Whole frame encryption versus payload encryption
>>>>>=20
>>>>> With respect to consensus, this is IETF last call, one of whose purpos=
es is to determine whether there is IETF consensus to publish this document a=
s a Proposed Standard.  Are you saying that you do not agree that there is a=
n IETF consensus to publish this document as a Proposed Standard?  Or that t=
here is no IETF consensus to publish *any* of the PERC WG output as a Propos=
ed Standard?=20
>>>>>=20
>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD  wrote:
>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and ot=
her topics.
>>>>>>=20
>>>>>> Sent from my iPhone
>>>>>>=20
>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote=
:
>>>>>>=20
>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.=

>>>>>>>=20
>>>>>>> Lorenzo
>>>>>>>=20
>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  ha scri=
tto:
>>>>>>>>=20
>>>>>>>> I want to second that as it is a particularly major problem: not al=
lowing SSRC rewriting makes the entire framework unusable with SFU implement=
ation I represent as well as every other SFU I am familiar with.
>>>>>>>>=20
>>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting could n=
ot be allowed=E2=80=9D is a conclusion that ever had any consensus in PERC, r=
egardless of what WG leadership is trying to make everyone believe.
>>>>>>>>=20
>>>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba  wrote:
>>>>>>>>> Richard said:
>>>>>>>>>=20
>>>>>>>>> "Again, the answer is clear here, but the document should be clear=
er.  The working group discussed SSRC rewriting several times, and concluded=
 that SSRC rewriting could not be allowed in this system.  This decision is r=
eflected, e.g., in the fact that the Double transform does not allow modific=
ation of SSRCs."
>>>>>>>>>=20
>>>>>>>>> [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 p=
articipants, based on the bandwidth, resolution and framerates.  If rewritin=
g of SSRCs is not possible, do PERC endpoints need to be able to receive sim=
ulcast? If PERC endpoints do need to be able to receive simulcast, what are t=
he requirements for endpoints?  For example, should endpoints expect the MDD=
 to use RID header extensions to identify the incoming simulcast streams?=20=

>>>>>>>>>=20
>>>>>>>>> Receiving of simulcast is tricky because the endpoint is receiving=
 multiple streams with different sequence number spaces which may contain ho=
les 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, a=
s noted in the WEBRTC specification Section 5.4.1, support for reception of s=
imulcast is optional. I am aware of two ORTC implementations that have attem=
pted to support simulcast reception, neither of which is robust in scenarios=
 with considerable loss and/or reordering.  And neither implementation suppo=
rts the RID header extension on received simulcast streams.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo  wrote:
>>>>>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>>>>> So I would propose we add something like the following to this d=
efinition:=20
>>>>>>>>>>>=20
>>>>>>>>>>> "In the context of WebRTC, where control of a session is divided=
 between a JavaScript application and a browser, the browser acts as the Tru=
sted Endpoint for purposes of this framework (just as it acts as the endpoin=
t for DTLS-SRTP in one-to-one calls).
>>>>>>>>>>=20
>>>>>>>>>> If we decide to adopt perc (big if) in webrtc, shouldn't this be d=
efined within the https://tools.ietf.org/html/draft-ietf-rtcweb-security-arc=
h-17 doc ?
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>    Optimally, we would not rely on trust in any entities other th=
an the
>>>>>>>>>>    browser.  However, this is unfortunately not possible if we wi=
sh to
>>>>>>>>>>    have a functional system.  Other network elements fall into tw=
o
>>>>>>>>>>    categories: those which can be authenticated by the browser an=
d thus
>>>>>>>>>>    can be granted permissions to access sensitive resources, and t=
hose
>>>>>>>>>>    which cannot be authenticated and thus are untrusted.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> 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 n=
ot in webrtc. As Bernard is stating, we could decide that there are other ke=
y management solutions trusted (even in JS or WASM), as for for example is b=
eing                                                     done in EME:
>>>>>>>>>>=20
>>>>>>>>>> https://github.com/WICG/media-capabilities/blob/master/explainer.=
md#encryption
>>>>>>>>>>=20
>>>>>>>>>> Best regards
>>>>>>>>>>=20
>>>>>>>>>> Sergio
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Perc mailing list
>>>>>>>>>> Perc@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>> --=20
>>>>>>>> sent from my mobile
>>>>>>>=20
>>>>>>> --=20
>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevi=
t=C3=A0.
>>>> --=20
>>>> sent from my mobile
>> --=20
>> sent from my mobile
>>=20
>>=20
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>=20

--Apple-Mail-91A19C17-CF5D-4C74-B994-FF36330BF48C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ser=
gio -

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 encry=
ption problem were fixed) be suitably modified and then implemented?

On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.c=
om> wrote:


 =20
    
 =20
 =20
    
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:
=

    

    

      
      

        


        

        


        

      

      

        
On Sat 2 Feb 2019 at 16:50, Bernard Aboba <bernard.aboba@gmail.com>
          wrote:

        

        

          
Emil said:
            


            

            
"The need to do a triple encryption for example is a
              particularly egregious consequence of the order problem.
              That=E2=80=99s a problem specific to the =E2=80=9Cdouble=E2=80=
=9D 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". <=
/div>
          

        

        


        

      

      

        

          
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=E2=80=99t know that this goal is a direct
            consequence of the framework=E2=80=99s conceptual approach (cont=
rary
            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 =E2=80=9Cwedgin=
g RTX
            and FEC=E2=80=9D 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 =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D=
 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: =E2=80=9Cwell, those of you who use FEC/RTX=

            will simply do a third round of SRTP=E2=80=9D, 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

          


          

          


          

        

      

      

        

          

            


              

                
On Sat, Feb 2, 2019 at=

                  11:46 AM Emil Ivov <emcho@jitsi.org>
                  wrote:

                

                

                  

                    
Yes pretty much those.

                  

                  


                  

                  
The need to do a triple encryption for
                    example is a particularly egregious consequence of
                    the order problem. That=E2=80=99s a problem specific to t=
he
                    =E2=80=9Cdouble=E2=80=9D 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 Sat 2 Feb 2019 at 12:23, Bernard
                        Aboba <bernard.aboba@gmail.com>
                        wrote:

                      

                      

                        
"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? 

                        

                        

                        

                          
On Sat, Feb
                            2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>
                            wrote:

                          

                          

                            
+1 on ssrc rewriting, and on
                              the consensus not reached on this and
                              other topics.

                              

                              
Sent from my iPhone

                              


                                On 2 Feb 2019, at 17:18, Lorenzo Miniero
                                <lorenzo@meetecho.com>
                                wrote:

                                

                              

                              

                                
+1, SSRC rewriting is
                                  pretty much fundamental to all SFUs
                                  out there.

                                  

                                  Lorenzo

                                  

                                  
Il 2 febbraio
                                    2019 10:19:06 CET, Emil Ivov <emcho=
@jitsi.org>
                                    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 =E2=80=9CSSRC
                                        rewriting could not be allowed=E2=80=
=9D
                                        is a conclusion that ever had
                                        any consensus in PERC,
                                        regardless of what WG leadership
                                        is trying to make everyone
                                        believe.

                                      


                                        

                                          
On Sat 2 Feb
                                            2019 at 06:21, Bernard Aboba
                                            <bernard.aboba@gmai=
l.com>
                                            wrote:

                                          

                                          

                                            
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 neithe=
r
                                                implementation supports
                                                the RID header extension
                                                on received simulcast
                                                streams.

                                              


                                              

                                              


                                              

                                              


                                              

                                            

                                            

                                            

                                              
On
                                                Fri, Feb 1, 2019 at
                                                12:23 PM Sergio Garcia
                                                Murillo <sergio.garcia.murillo@gmail.com>
                                                wrote:

                                              

                                              

                                                

                                                  
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 no=
t 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.m=
d#encryption

                                                  

                                                  
Best regards

                                                  
Sergio

                                                  

                                                

_______________________________________________

                                                Perc mailing list

                                                Perc@ietf.org

                                                https://www.ietf.org/mailman/listinfo/perc

                                              

                                            

                                          

                                        

                                      

                                      -- 

                                      
sent
                                        from my mobile

                                    

                                  

                                  

                                  -- 

                                  Inviato dal mio dispositivo Android
                                  con K-9 Mail. Perdonate la brevit=C3=A0.
                              

                            

                          

                        

                      

                    

                  

                  -- 

                  
sent
                    from my mobile

                

              

            

          

        

      

      -- 

      
sent from my mobile

      

      

      
_______________________________=
________________
Perc mailing list
Perc@iet=
f.org
https://www.ietf.org/mailman/listinfo/perc


    

    


    

 =20


=

--Apple-Mail-91A19C17-CF5D-4C74-B994-FF36330BF48C--


From nobody Sat Feb  2 13:33:17 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BABB130E9A; Sat,  2 Feb 2019 13:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLdyArWRcJ3Q; Sat,  2 Feb 2019 13:33:04 -0800 (PST)
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2887F130E91; Sat,  2 Feb 2019 13:33:04 -0800 (PST)
Received: by mail-wr1-x443.google.com with SMTP id q18so10640550wrx.9; Sat, 02 Feb 2019 13:33:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=NXS9uB9zPL2msZww5NFTNRrhiS7tIY4YDf/zsPU4WpM=; b=rXfT3avtJBtIO+gvraIaJ8j8su+uV1PGaEidkbXlpREcPm9i3uuJe6TqALjnqvI2zz ORhKKY/eRkvFowgnAT4D/Vf07DPAvsHSLZm+Yle0WEdDieRetTZMtgIbdn5cwB9H23Gf IL3Bj9nS2ktPy91bVjSRqK7T9UsDQqihbaS+3ks3mYyHP0uxI8XiWLN3FzlzW8qSjCak 0rNciyz30M58ybFX5DGUoKfkfGqLspwNYR6VxXDouwSkcsbZb0jqbWfn1J0H4Igq69lc 4KU2IFRDlpSNRbvWPMJrXedfdTtct1VDV3J1YCZrVe04fOPm/Rhn+1N0RqWId3HqVfRd GvUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=NXS9uB9zPL2msZww5NFTNRrhiS7tIY4YDf/zsPU4WpM=; b=dwQYytftk4UdPLfG5lKjns0DOecifiMwCISCKcTcTbDXwi9zc6+TDiYYn1NTw/YDx8 oaxciYcYJSISgap+IswVAw7k+ldDhRJTrQTo4wEecKnQED0lsqu33uxEesSO3GGESmDd S1JJs9N0SBuFqnCg/+UEm5iD1daIINIDt5DXOsUxs/D1wlNfp2azPBWB9GW/Ac5Cz4w1 cRM8gGVpOnG7KpZFL9/oalO7s39twwMgWyidkU876sQwATAitjIu5oi/FYVrdDSvR+Ad SirkI6hT1SnNrPOxSNjx04WYuZzMu3TgYECjOPl56jOR530/RtEPR/yepu65gzXVupR5 iqaw==
X-Gm-Message-State: AJcUukduyDLIF/xegEiglLX8YON+NRVy7cxj4BhOL7paJ829ReRiHWsx Q8VMn8VraCWOknGcshh6/ho=
X-Google-Smtp-Source: ALg8bN6UbdY+OIEZQGTl7DPQVrIZNDxqf9Ukvtr7oC1in+NzQ5oRKyKPBdNFLnWyqkwbC8cP3Wnanw==
X-Received: by 2002:adf:91a3:: with SMTP id 32mr39645512wri.99.1549143182356;  Sat, 02 Feb 2019 13:33:02 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id p10sm17343171wmd.14.2019.02.02.13.33.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 13:33:01 -0800 (PST)
From: Sergio Garcia Murillo 
To: Bernard Aboba , Sergio Garcia Murillo 
Cc: Emil Ivov , Alexandre GOUAILLARD , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io>
Message-ID: <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com>
Date: Sat, 2 Feb 2019 22:37:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io>
Content-Type: multipart/alternative; boundary="------------C40807DACF94C17BA19CA88D"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 02 Feb 2019 21:33:09 -0000

This is a multi-part message in MIME format.
--------------C40807DACF94C17BA19CA88D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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?
>>
>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo 
>> > > wrote:
>>
>>> 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:
>>>>
>>>>
>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba >>> > 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
>>>>
>>>>
>>>>
>>>>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov >>>     > wrote:
>>>>
>>>>         Yes pretty much those.
>>>>
>>>>         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 Sat 2 Feb 2019 at 12:23, Bernard Aboba
>>>>         >
>>>>         wrote:
>>>>
>>>>             "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?
>>>>
>>>>             On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD
>>>>             >>>             > wrote:
>>>>
>>>>                 +1 on ssrc rewriting, and on the consensus not
>>>>                 reached on this and other topics.
>>>>
>>>>                 Sent from my iPhone
>>>>
>>>>                 On 2 Feb 2019, at 17:18, Lorenzo Miniero
>>>>                 >>>                 > wrote:
>>>>
>>>>>                 +1, SSRC rewriting is pretty much fundamental to
>>>>>                 all SFUs out there.
>>>>>
>>>>>                 Lorenzo
>>>>>
>>>>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>>>>                 > 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.
>>>>>
>>>>>                     On Sat 2 Feb 2019 at 06:21, Bernard Aboba
>>>>>                     >>>>                     > wrote:
>>>>>
>>>>>                         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 Fri, Feb 1, 2019 at 12:23 PM Sergio
>>>>>                         Garcia Murillo
>>>>>                         >>>>                         >
>>>>>                         wrote:
>>>>>
>>>>>                             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@ietf.org 
>>>>>                             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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>>>

--------------C40807DACF94C17BA19CA88D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
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?

        


          On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
          wrote:

          

        

        

          

            
            
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:

            

            

              
              

                


                

                


                

              

              

                
On Sat 2 Feb 2019 at 16:50, Bernard Aboba
                  <bernard.aboba@gmail.com>
                  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

                  


                  

                  


                  

                

              

              

                

                  

                    


                      

                        
On Sat, Feb 2,
                          2019 at 11:46 AM Emil Ivov <emcho@jitsi.org>
                          wrote:

                        

                        

                          

                            
Yes pretty much those.

                          

                          


                          

                          
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 Sat 2 Feb 2019 at 12:23,
                                Bernard Aboba <bernard.aboba@gmail.com>
                                wrote:

                              

                              

                                
"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? 

                                

                                

                                

                                  
On
                                    Sat, Feb 2, 2019 at 5:40 AM
                                    Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>
                                    wrote:

                                  

                                  

                                    
+1 on ssrc
                                      rewriting, and on the consensus
                                      not reached on this and other
                                      topics.

                                      

                                      
Sent from my iPhone

                                      


                                        On 2 Feb 2019, at 17:18, Lorenzo
                                        Miniero <lorenzo@meetecho.com>
                                        wrote:

                                        

                                      

                                      

                                        
+1, SSRC
                                          rewriting is pretty much
                                          fundamental to all SFUs out
                                          there.

                                          

                                          Lorenzo

                                          

                                          
Il 2
                                            febbraio 2019 10:19:06 CET,
                                            Emil Ivov <emcho@jitsi.org>
                                            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.

                                              


                                                

                                                  
On Sat
                                                    2 Feb 2019 at 06:21,
                                                    Bernard Aboba <bernard.aboba@gmail.com>
                                                    wrote:

                                                  

                                                  

                                                    
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
                                                        Fri, Feb 1, 2019
                                                        at 12:23 PM
                                                        Sergio Garcia
                                                        Murillo <sergio.garcia.murillo@gmail.com>
                                                        wrote:

                                                      

                                                      

                                                        

                                                          
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@ietf.org

                                                        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@ietf.org
https://www.ietf.org/mailman/listinfo/perc


            

            


            

          

        

      

    

  


--------------C40807DACF94C17BA19CA88D--


From nobody Mon Feb  4 09:33:26 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDC0130EB7; Mon,  4 Feb 2019 09:33:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gorry Fairhurst 
To: 
Cc: ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154930159870.28630.16457371613620717540@ietfa.amsl.com>
Date: Mon, 04 Feb 2019 09:33:18 -0800
Archived-At: 
Subject: [Perc] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Feb 2019 17:33:19 -0000

Reviewer: Gorry Fairhurst
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information. The authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

There are two other IETF drafts cited normally by this document, also in last call.

This document defines a security architecture based around an IETF transport, 
but does not itself propose updates to the transport mechanisms. I did
not find additional transport concerns, but have a number of general 
comments I'd like you to consider in the LC.

----

General comments

Some keywords appear not defined before first used - whilst these are likely
to be well-known by the coimmunity of interest, it would none-the-less
be helpful to define these:

SRTP; RTCP; SIP; SDP.

In section 8.1, there is a sentence starting "Off-path atttackers may" ... while this
is lower case, the authors may wish toi consider using "could" to remove any
possibility of this being regarded as permissive.

In 8.1, the text "could incorrectly assuming their packets..." probably ought to
read could incorrectly assume their packets..." 

In section 8.2.1. there is a dscription of a resource consumption attack, but
no miitigation is described. It could be possible to consider using  rate-limiting 
of requests to reduce the impact - a mthod commonly suggested in other
attacks on the transport endpoints.





From nobody Thu Feb  7 12:18:57 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1B12DD85 for ; Thu,  7 Feb 2019 12:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQB-Lou6IELp for ; Thu,  7 Feb 2019 12:18:44 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530D012F1A5 for ; Thu,  7 Feb 2019 12:18:41 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id s13so2110847otq.4 for ; Thu, 07 Feb 2019 12:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZwclM8kDVtJzbS73vmgrHuBWF3GchFjMbAWvwjl1n/4=; b=wnE3/Wm4QK4p8KydZO8N2L5vfD6zKimvoButc40CSDCLm6jQOy4K7HM0vw8i732Ab3 qIBoVKJIbyxt+fOXBkZ1GJYRE8ssYv/l6W2jNQGyj7EVAiHStSkrJJuK8eO/ZZnX05CN iJHS6ji2+IwIpZwNEGTGyRFJTv6VbsGysw0Y0Fc0WGtj/in95NGnX7LHmxwGL80Rp9X1 3A66gLp/ajWWMntOZ/DDQpqqC83+vyPEAr0V/Q+gKCIM90XbkO+6g/n2+kEL+cjMIcAF cyUX/KCVJn4Fi4IBQeSJuOFve0B9vsHQJNxMzsJBy6jDY7yPIKQsahDuXhgaah61Rcim TKTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZwclM8kDVtJzbS73vmgrHuBWF3GchFjMbAWvwjl1n/4=; b=KhUBFN4C3Jcvln4/ZN2jUWwGGPvaBow1M+kJMiwApVD8iqF1WoYQji4O1jIi0i7FBs 7/FQ0p8bP9v79odIVKVEJtsL1wRblWNJ5/wEWx4iJARMcyyp9GrutqHP2hSwpN9TjY4L tU1qM2XvZRBmS3TB89Geb/rzA/C+kuiL9tnScWTRizA5T5+H4YCyG+MjBBLiBWK1ZMiE VzLMCg+4LgDZSMQO3GRDrRJXfz3hQXC6C7E6egbavI7och2Vt9lTiBvM4G1HlUkll2Rz /c555mXW9gXXKpvIHYVhSUV9cLjNRF1ip/z1yBfaZmBR/tUTlrUNnyfuJPbKv6Mu1Rys snIA==
X-Gm-Message-State: AHQUAuaeP8x8+EoRXZZ88cWRBNP4aE9wssvMy3AOeRJ6YM2NqG9UVmrh qdsq7wfoUFBU/Kp2I984ktyqezCOXKpfEUloCSgk9Q==
X-Google-Smtp-Source: AHgI3IZ6j5GUbtsmwP6Dcv316uztRjkE/DeWZXAXmT7YoJY47k8zeq0G0aIRTGRDn++UW+QjvFjaVY4RBDKYtAkAG6s=
X-Received: by 2002:a9d:3424:: with SMTP id v33mr9389766otb.167.1549570720331;  Thu, 07 Feb 2019 12:18:40 -0800 (PST)
MIME-Version: 1.0
References: <154007316490.13794.11476150183128445420@ietfa.amsl.com>
In-Reply-To: <154007316490.13794.11476150183128445420@ietfa.amsl.com>
From: Richard Barnes 
Date: Thu, 7 Feb 2019 15:18:18 -0500
Message-ID: 
To: Christer Holmberg 
Cc: gen-art@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org,  IETF discussion list , perc@ietf.org
Content-Type: multipart/alternative; boundary="000000000000570fe00581538c96"
Archived-At: 
Subject: Re: [Perc] Genart last call review of draft-ietf-perc-srtp-ekt-diet-09
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2019 20:18:47 -0000

--000000000000570fe00581538c96
Content-Type: text/plain; charset="UTF-8"

Hi Christer,

Sorry, just now seeing this.  Responses inline.  PR here:

https://github.com/ietf/perc-wg/pull/165

--RLB

On Sat, Oct 20, 2018 at 6:06 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-perc-srtp-ekt-diet-09
> Reviewer: Christer Holmberg
> Review Date: 2018-10-20
> IETF LC End Date: 2018-11-01
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is well written, and easy to read. But, I think some
> things still need to be clarified. I also have some editorial modification
> suggestions.
>
> Major issues:
> --------------
>
> Q1_1:
>
> The text in section 1 says that EKT removes the need for co-ordinating
> SSRCs,
> and that an endpoint can choose whatever value it wants.
>
> However, I can't find any explanation on how EKT removes that need.
>

The answer is toward the end of the introduction: "EKT does not control the
manner in which the SSRC is generated..." -- it just makes the distribution
of security information easier.  I extended that paragraph to clarify.



> Q1_3:
>
> The text in section 1 says that EKT is not intended to replace key
> establishment mechanisms, but to "be used in conjunction".
>
> However, there is no description on how that works in conjunction with
> existing
> mechanisms (e.g., together with SDP Offer/Answer), and whether existing
> mechanisms need to be modified in order to work in conjunction with EKT.
>
> Section 5.3 does say that the SDP O/A exchange is not affected. If that is
> true, then you need to describe how SSRC values etc signalled in SDP
> relate to
> values signalled using EKT, what happens if there are mismatches etc.
>

This document only defines one such augmentation -- the integration with
DTLS-SRTP.  I extended the relevant part of the introduction to say this.



> Minor issues:
> --------------
>
> Q1_2:
>
> The text in section 1 says:
>
>    "However, there are several cases in which conventional signaling
> systems
>    cannot easily provide all of the coordination required."
>
> I think some examples would be useful.
>

Disagree.


> Q1_4:
>
> The text in section 1 says that providing SSRCs etc using signaling systems
> cause layer violations.
>
> Is this layer violation described somewhere? If so, I think a reference
> would
> be useful.
>

I just deleted this sentence.  It wasn't adding much.



> Q4-2_1:
>
> The text in section 4.2 says:
>
>    "All of the received EKT parameter sets SHOULD be stored by all of the
>    participants in an SRTP session, for use in processing inbound SRTP
>    and SRTCP traffic."
>
> What is the reason for SHOULD, instead of MUST? What happens if an endpoint
> does NOT store the EKT parameter sets?
>

I think the SHOULD here is to allow, e.g., cache management.  Clarified the
consequences.



> Q4-2-1_2:
>
> The text in section 4.2.1 says:
>
>    "Outbound packets SHOULD continue to use the old SRTP Master Key for
>    250 ms after sending any new key."
>
> What is the reason for SHOULD, instead of MUST?
>

I don't think this should be a MUST.  For example, how accurately are you
going to measure compliance?  If the change-over is 10ms short 10% of the
time, is the endpoint out of compliance. Plus, there's minimal interop
impact; this just helps things go smoothly.



> Q4-3_2:
>
> The text in section 4.3 says:
>
>    "Section 4.2.1 recommends that SRTP senders continue using an old key
>    for some time after sending a new key in an EKT tag."
>
> The text in section 4.2.1 contains a SHOULD, so it is more than a
> recommendation.
>

According to RFC 2119, a SHOULD is precisely a recommendation:

"""
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
"""

https://tools.ietf.org/html/rfc2119#section-3



> Nits/editorial comments:
> --------------------------
>
> Q1_5:
>
> I think Section 1 should also indicate that EKT is an DTLS extension,
> similar
> to the Abstract. Otherwise, when you say that EKT is a way to distribute
> information, it is unclear why EKT doesn't violate layers.
>

Done.



> I think that Section 2 (Overview) could be combined with Section 1
> (Introduction). Introduction sections in RFCs typically provide both
> background, problem statement and an overview of the mechanism - and
> sometimes
> also the document structure.
>

Disagree.


> Q4_1:
>
> The text in section 4.1 says:
>
>    "EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
>    Identifier) or with SRTP's  [RFC3711], as those SRTP
>    features duplicate some of the functions of EKT.  Senders MUST NOT
>    include MKI when using EKT.  Receivers SHOULD simply ignore any MKI
>    field received if EKT is in use."
>
> I suggest to put this text in a dedicated Applicability section.
>

Disagree.


> Q4-1_1:
>
> The text in section 4.1 says:
>
>    "Together, these data elements are called an EKT parameter set.  Each
>    distinct EKT parameter set that is used MUST be associated with a
>    distinct SPI value to avoid ambiguity."
>
> I suggest to defined "EKT parameter set" in the same way as the other
> terminology. I.e.,
>
>   "EKT parameter set: The parameters indicated by the SPI"
>
> ....or something like that.
>

There's not a terminology section, so I didn't do exactly what you say.
But I pulled this out into a separate section so that it doesn't interrupt
the flow, and clarified that the SPI-params association is set up by the
DTLS-SRTP extension.


Q4-2-1_1:
>
> For the section names of sections 4.2.1 and 4.2.2, I suggest to talk about
> sending/transmitting and receiving instead of inbound and outbound.
>

Disagree


> Q4-3_1:
>
> In section 4.3, I  think the name of the section ("Implementation Notes")
> is a
> little confusing. Also, is there a reason why the text is not in section
> 4.2.1
> and/or 4.2.2?
>

Just folded this into section 4.2.2.



> Q4-4_1:
>
> Sections 4.4 and 4.4.1 have the same section names. Please change one of
> them
> (e.g., change 4.4.1 to "Default Cipher").
>

Changed to "AES Key Wrap"



> Q4-6_1:
>
> I think the text in section 4.6 should be placed in the Applicability
> section I
> suggested earlier (Q4_1).
>

Merged it into section 4.



> Q5_1:
>
> In section 5, I  suggest to change the section name to "DTLS-SRTP
> Considerations".
>

Disagree.


>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>

--000000000000570fe00581538c96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Christer,
Sorry, just now seeing this.=C2=A0 Responses inline.=C2=A0 PR h=
ere:


--RLB

On Sat, Oct 20, 2018 at 6:06 PM Christer Holmberg <christer.holmberg@ericsson.c=
om> wrote:
https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g=
t;.



Document: draft-ietf-perc-srtp-ekt-diet-09

Reviewer: Christer Holmberg

Review Date: 2018-10-20

IETF LC End Date: 2018-11-01

IESG Telechat date: Not scheduled for a telechat



Summary: The document is well written, and easy to read. But, I think some<=
br>
things still need to be clarified. I also have some editorial modification<=
br>
suggestions.



Major issues:

--------------



Q1_1:



The text in section 1 says that EKT removes the need for co-ordinating SSRC=
s,

and that an endpoint can choose whatever value it wants.



However, I can't find any explanation on how EKT removes that need.
=


The answer is toward the end of the introd=
uction: "EKT does not control the manner in which the SSRC is generate=
d..." -- it just makes the distribution of security information easier=
.=C2=A0 I extended that paragraph to clarify.

=C2=
=A0

Q1_3:



The text in section 1 says that EKT is not intended to replace key

establishment mechanisms, but to "be used in conjunction".



However, there is no description on how that works in conjunction with exis=
ting

mechanisms (e.g., together with SDP Offer/Answer), and whether existing

mechanisms need to be modified in order to work in conjunction with EKT.


Section 5.3 does say that the SDP O/A exchange is not affected. If that is<=
br>
true, then you need to describe how SSRC values etc signalled in SDP relate=
 to

values signalled using EKT, what happens if there are mismatches etc.

This document only defines one such augmenta=
tion -- the integration with DTLS-SRTP.=C2=A0 I extended the relevant part =
of the introduction to say this.

=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Minor issues:

--------------



Q1_2:



The text in section 1 says:



=C2=A0 =C2=A0"However, there are several cases in which conventional s=
ignaling systems

=C2=A0 =C2=A0cannot easily provide all of the coordination required."<=
br>


I think some examples would be useful.

=
Disagree.
=C2=A0

Q1_4:



The text in section 1 says that providing SSRCs etc using signaling systems=


cause layer violations.



Is this layer violation described somewhere? If so, I think a reference wou=
ld

be useful.

I just deleted this sentence=
.=C2=A0 It wasn't adding much.

=C2=A0

Q4-2_1:



The text in section 4.2 says:



=C2=A0 =C2=A0"All of the received EKT parameter sets SHOULD be stored =
by all of the

=C2=A0 =C2=A0participants in an SRTP session, for use in processing inbound=
 SRTP

=C2=A0 =C2=A0and SRTCP traffic."



What is the reason for SHOULD, instead of MUST? What happens if an endpoint=


does NOT store the EKT parameter sets?

=
I think the SHOULD here is to allow, e.g., cache management.=C2=A0 Clarifie=
d the consequences.

=C2=A0

Q4-2-1_2:



The text in section 4.2.1 says:



=C2=A0 =C2=A0"Outbound packets SHOULD continue to use the old SRTP Mas=
ter Key for

=C2=A0 =C2=A0250 ms after sending any new key."



What is the reason for SHOULD, instead of MUST?

I don't think this should be a MUST.=C2=A0 For example, how ac=
curately are you going to measure compliance?=C2=A0 If the change-over is 1=
0ms short 10% of the time, is the endpoint out of compliance. Plus, there&#=
39;s minimal interop impact; this just helps things go smoothly.
<=
div>
=C2=A0

Q4-3_2:



The text in section 4.3 says:



=C2=A0 =C2=A0"Section 4.2.1 recommends that SRTP senders continue usin=
g an old key

=C2=A0 =C2=A0for some time after sending a new key in an EKT tag."



The text in section 4.2.1 contains a SHOULD, so it is more than a

recommendation.

According to RFC 2119, =
a SHOULD is precisely a recommendation:

"&quo=
t;"
3. SHOULD=C2=A0=C2=A0 This word, or the adjective "=
RECOMMENDED", mean that there
=C2=A0=C2=A0 may exist valid reasons =
in particular circumstances to ignore a
=C2=A0=C2=A0 particular item, bu=
t the full implications must be understood and
=C2=A0=C2=A0 carefully we=
ighed before choosing a different course.
"""


=C2=A0

Nits/editorial comments:

--------------------------



Q1_5:



I think Section 1 should also indicate that EKT is an DTLS extension, simil=
ar

to the Abstract. Otherwise, when you say that EKT is a way to distribute
information, it is unclear why EKT doesn't violate layers.

Done.

=C2=A0

I think that Section 2 (Overview) could be combined with Section 1

(Introduction). Introduction sections in RFCs typically provide both

background, problem statement and an overview of the mechanism - and someti=
mes

also the document structure.

Disagree.<=
br>
=C2=A0

Q4_1:



The text in section 4.1 says:



=C2=A0 =C2=A0"EKT MUST NOT be used in conjunction with SRTP's MKI =
(Master Key

=C2=A0 =C2=A0Identifier) or with SRTP's <From, To> [RFC3711], as =
those SRTP

=C2=A0 =C2=A0features duplicate some of the functions of EKT.=C2=A0 Senders=
 MUST NOT

=C2=A0 =C2=A0include MKI when using EKT.=C2=A0 Receivers SHOULD simply igno=
re any MKI

=C2=A0 =C2=A0field received if EKT is in use."



I suggest to put this text in a dedicated Applicability section.

Disagree.
=C2=A0

Q4-1_1:



The text in section 4.1 says:



=C2=A0 =C2=A0"Together, these data elements are called an EKT paramete=
r set.=C2=A0 Each

=C2=A0 =C2=A0distinct EKT parameter set that is used MUST be associated wit=
h a

=C2=A0 =C2=A0distinct SPI value to avoid ambiguity."



I suggest to defined "EKT parameter set" in the same way as the o=
ther

terminology. I.e.,



=C2=A0 "EKT parameter set: The parameters indicated by the SPI"


....or something like that.

There's=
 not a terminology section, so I didn't do exactly what you say.=C2=A0 =
But I pulled this out into a separate section so that it doesn't interr=
upt the flow, and clarified that the SPI-params association is set up by th=
e DTLS-SRTP extension.
=C2=A0


Q4-2-1_1:



For the section names of sections 4.2.1 and 4.2.2, I suggest to talk about<=
br>
sending/transmitting and receiving instead of inbound and outbound.

Disagree
=C2=A0

Q4-3_1:



In section 4.3, I=C2=A0 think the name of the section ("Implementation=
 Notes") is a

little confusing. Also, is there a reason why the text is not in section 4.=
2.1

and/or 4.2.2?

Just folded this into sec=
tion 4.2.2.

=C2=A0

Q4-4_1:



Sections 4.4 and 4.4.1 have the same section names. Please change one of th=
em

(e.g., change 4.4.1 to "Default Cipher").
Changed to "AES Key Wrap"

=
=C2=A0

Q4-6_1:



I think the text in section 4.6 should be placed in the Applicability secti=
on I

suggested earlier (Q4_1).

Merged it int=
o section 4.

=C2=A0

Q5_1:



In section 5, I=C2=A0 suggest to change the section name to "DTLS-SRTP=


Considerations".

Disagree.
=C2=A0





_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




--000000000000570fe00581538c96--


From nobody Fri Feb  8 16:24:39 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5879130EC0; Fri,  8 Feb 2019 16:24:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar 
To: 
Cc: ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154967186390.31080.3030875691159376140@ietfa.amsl.com>
Date: Fri, 08 Feb 2019 16:24:23 -0800
Archived-At: 
Subject: [Perc] Genart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Feb 2019 00:24:24 -0000

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-perc-private-media-framework-??
Reviewer: Linda Dunbar
Review Date: 2019-02-08
IETF LC End Date: 2019-02-13
IESG Telechat date: Not scheduled for a telechat

Summary:
This document describes a solution framework for ensuring that media
confidentiality and integrity are maintained end-to-end.

Major issues:
 The SRTP Master Key described in Section 6.4 is not listed in the Figure 4 Key
 Inventory. What is the relationship between the KEK listed in the Figure 4 Key
 Inventory and the SRTP Master Key?

Section 6.3 talks about Key distributor sending KEK to endpoints.  Is it via
untrusted network?  how to prevent the KEK from leaking to other points?
 Is KEK same as EKT Key? if yes, why use two names? it is confusing.

Section 5: the first paragraph says that the "Key requirements are that
endpoint can verify it is connected to the correct Key Distributor..", But How?
can you include a reference to the method?

Minor issues:

Nits/editorial comments:
Section 3.2.2: is it a typo? extra "to" in the following sentence?
"...is necessary to for proper conference-to-endpoint mappings."

Best Regards,

Linda


From nobody Tue Feb 12 17:34:44 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF03A130ED9 for ; Tue, 12 Feb 2019 17:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4459wZ-h-JiF for ; Tue, 12 Feb 2019 17:34:37 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54726129284 for ; Tue, 12 Feb 2019 17:34:37 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id c123so363680pfb.0 for ; Tue, 12 Feb 2019 17:34:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Sr92MYK9tYu20k3hSwsImWjOfDXzbmg4/MLjRA1UVlk=; b=H7uQNkQuZaertPyksmtWq1JGlhpuTsK6mYayWCSfieseeyeIn+srCNeyBKBF32CwOr 5stQAzFpf3E34+LIecW5apBYbmVAzxx5A8oERKsI5P0kA9HGI7Oc7K/SMZa6MUfopJdj foW65ogacvNzFes+6h3+1qlp+Kd6YCQx1Ys3s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Sr92MYK9tYu20k3hSwsImWjOfDXzbmg4/MLjRA1UVlk=; b=FN0FsLXAifjy1l2W0CrFx3/86XxZ9Lcdmmtg9ggvkKEPHZe4iAeeWoU5UlQzMbOFKv xoNiTVQldd0tI1qoNei1XCn678tpoF6qpw6CspHnXgKfuVbkPbIyCvE+ORP02QPOoT5p jRSSsY9SV5T6rEVx7K3ABVp2eBVKoZo+sg5ROx0cKRdXfr31oIiHp5MqqpBH3Ik5jJiT 2ThJKOisfi5LIEjbqr6+W87Eh2R2SzM/YKgoAXb68WDGFJRIdNYmCGzT8pznqqj6Goea gfB87/XpH8i1znP/4eyzRzIOqwq0JB8B1x7dTx8KBhe6YRwxxZF9cRSsHgSoDoNCvxqY sINA==
X-Gm-Message-State: AHQUAuZSw0XqcGpNcaAAlcPq0kanV3dGJXPNrFRqCZQjRuzbi1OqKJkz JhDuq+JIQtD3Fyj9SGbHr5e8xw==
X-Google-Smtp-Source: AHgI3IZFcbr5GwghajshT+a4SKh1Jh20LXbg2pTDINH0SXOu1S7aQ7Zj9tuwkHMJSMf7Lwp56e0EmA==
X-Received: by 2002:aa7:84c7:: with SMTP id x7mr6839195pfn.180.1550021676266;  Tue, 12 Feb 2019 17:34:36 -0800 (PST)
Received: from ?IPv6:2601:647:4600:3f31:c5dc:6ac5:dc93:5194? ([2601:647:4600:3f31:c5dc:6ac5:dc93:5194]) by smtp.gmail.com with ESMTPSA id j6sm15872177pgq.33.2019.02.12.17.34.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 17:34:34 -0800 (PST)
From: Nils Ohlmeier 
Message-Id: <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_750CF8DA-C60A-47E6-8F52-538DF29AFAA5"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 12 Feb 2019 17:34:33 -0800
In-Reply-To: <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com>
Cc: Bernard Aboba , IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
To: Sergio Garcia Murillo 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 01:34:42 -0000

--Apple-Mail=_750CF8DA-C60A-47E6-8F52-538DF29AFAA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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).
  https://www.ietf.org/proceedings/95/minutes/minutes-95-perc =

=20
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
  https://www.ietf.org/proceedings/96/minutes/minutes-96-perc =

At IETF 98 SSRC immutability and RTX considerations were discussed but =
no proposal made on security implications
  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 =

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.
  https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01 =

  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc =

Best regards
  Nils & Suhas
  PERC WG chairs

> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo =
 wrote:
>=20
> PERC may be a valid solution for some scenarios, maybe SIP.
>=20
> 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.
>=20
> Best regards
>=20
> Sergio
>=20
>>=20
>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>> Sergio -
>>>=20
>>> 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?
>>>=20
>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo =
> wrote:
>>>=20
>>>> I think Emil and Bernard have described quite precisely where we =
are and how we managed to get here.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Best regards
>>>> Sergio
>>>>=20
>>>>=20
>>>> On 02/02/2019 18:42, Emil Ivov wrote:
>>>>>=20
>>>>>=20
>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba > wrote:
>>>>> Emil said:
>>>>>=20
>>>>> "The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents."
>>>>>=20
>>>>> [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".=20=

>>>>>=20
>>>>> 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.=20
>>>>>=20
>>>>> I don=E2=80=99t know that this goal is a direct consequence of the =
framework=E2=80=99s 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> This approach was referred to as =E2=80=9Cwedging RTX and FEC=E2=80=9D=
 as it places them in between the two encryption operations.
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>> Applications will apply SRTP-double first and, those that need to =
use FEC and RTX would have to apply them only after.=20
>>>>>=20
>>>>> It was quickly pointed out that this not only destroys the stated =
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, =
those of you who use FEC/RTX will simply do a third round of SRTP=E2=80=9D=
, thus arriving at a total of three encryptions for every packet..
>>>>>=20
>>>>> The discussions around this topic were highly contentious.
>>>>>=20
>>>>> Hope this makes things clear,
>>>>> Emil
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov > wrote:
>>>>> Yes pretty much those.
>>>>>=20
>>>>> The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Emil
>>>>>=20
>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba > wrote:
>>>>> "on the consensus not reached on this and other topics."
>>>>>=20
>>>>> [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:
>>>>>=20
>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>> * Whole frame encryption versus payload encryption
>>>>>=20
>>>>> 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?=20
>>>>>=20
>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD =
> wrote:
>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and =
other topics.
>>>>>=20
>>>>> Sent from my iPhone
>>>>>=20
>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero > wrote:
>>>>>=20
>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out =
there.
>>>>>>=20
>>>>>> Lorenzo
>>>>>>=20
>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov > 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.
>>>>>>=20
>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting =
could not be allowed=E2=80=9D is a conclusion that ever had any =
consensus in PERC, regardless of what WG leadership is trying to make =
everyone believe.
>>>>>>=20
>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba =
> wrote:
>>>>>> Richard said:
>>>>>>=20
>>>>>> "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."
>>>>>>=20
>>>>>> [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?=20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo =
> wrote:
>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>> So I would propose we add something like the following to this =
definition:=20
>>>>>>>=20
>>>>>>> "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).
>>>>>>=20
>>>>>> 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 ?
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>    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.
>>>>>>=20
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> =
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryp=
tion =

>>>>>> Best regards
>>>>>>=20
>>>>>> Sergio
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> Perc@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>> --=20
>>>>>> sent from my mobile
>>>>>>=20
>>>>>> --=20
>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la =
brevit=C3=A0.
>>>>> --=20
>>>>> sent from my mobile
>>>>> --=20
>>>>> sent from my mobile
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Perc mailing list
>>>>> Perc@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>=20
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc


--Apple-Mail=_750CF8DA-C60A-47E6-8F52-538DF29AFAA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


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
 =
 https://www.ietf.org/proceedings/96/minutes/minutes-96-perc

At IETF 98 =
SSRC immutability and RTX considerations were discussed but no proposal =
made on security implications
 =
 https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00<=
/span>

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.
 =
 https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7=
wkf4-bc

Best =
regards
  Nils =
& Suhas
  PERC =
WG chairs

On 2Feb, 2019, at 13:37, Sergio Garcia =
Murillo <sergio.garcia.murillo@gmail.com> wrote:


 =20
    
 =20
  
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?

        


          On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
          wrote:

          

        

        

          

            
            
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:

            

            

              
              

                


                

                


                

              

              

                
On Sat 2 Feb 2019 at 16:50, =
Bernard Aboba
                  <bernard.aboba@gmail.com>
                  wrote:

                

                

                  
Emil said:
                    


                    

                    
"The need to do a triple encryption =
for example
                      is a particularly egregious consequence of the
                      order problem. That=E2=80=99s a problem specific =
to the
                      =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that =
this goal is a
                    direct consequence of the framework=E2=80=99s =
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
                    =E2=80=9Cwedging RTX and FEC=E2=80=9D 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 =
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D
                    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:
                    =E2=80=9Cwell, those of you who use FEC/RTX will =
simply do a
                    third round of SRTP=E2=80=9D, 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

                  


                  

                  


                  

                

              

              

                

                  

                    


                      

                        
On Sat, =
Feb 2,
                          2019 at 11:46 AM Emil Ivov <emcho@jitsi.org>
                          wrote:

                        

                        

                          

                            
Yes pretty much =
those.

                          

                          


                          

                          
The need to do a =
triple
                            encryption for example is a particularly
                            egregious consequence of the order problem.
                            That=E2=80=99s a problem specific to the =
=E2=80=9Cdouble=E2=80=9D
                            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 Sat 2 Feb =
2019 at 12:23,
                                Bernard Aboba <bernard.aboba@gmail.com>
                                wrote:

                              

                              

                                
"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? 

                                

                                

                                

                                  
On=

                                    Sat, Feb 2, 2019 at 5:40 AM
                                    Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>
                                    wrote:

                                  

                                  

                                    
+1 on =
ssrc
                                      rewriting, and on the consensus
                                      not reached on this and other
                                      topics.

                                      

                                      
Sent from my iPhone

                                      


                                        On 2 Feb 2019, at 17:18, Lorenzo
                                        Miniero <lorenzo@meetecho.com>
                                        wrote:

                                        

                                      

                                      

                                        
+1, =
SSRC
                                          rewriting is pretty much
                                          fundamental to all SFUs out
                                          there.

                                          

                                          Lorenzo

                                          

                                          
Il =
2
                                            febbraio 2019 10:19:06 CET,
                                            Emil Ivov <emcho@jitsi.org>
                                            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 =E2=80=9CSSRC =
rewriting
                                                could not be allowed=E2=80=
=9D is
                                                a conclusion that ever
                                                had any consensus in
                                                PERC, regardless of what
                                                WG leadership is trying
                                                to make everyone
                                                believe.

                                              


                                                

                                                  
On Sat
                                                    2 Feb 2019 at 06:21,
                                                    Bernard Aboba <bernard.aboba@gmail.com>
                                                    wrote:

                                                  

                                                  

                                                    
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
                                                        Fri, Feb 1, 2019
                                                        at 12:23 PM
                                                        Sergio Garcia
                                                        Murillo <sergio.garcia.murillo@gmail.com>
                                                        wrote:

                                                      

                                                      

                                                        

                                                          
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-sec=
urity-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/m=
aster/explainer.md#encryption

                                                          
Best
                                                          regards
Sergio

                                                          

                                                        

_______________________________________________

                                                        Perc mailing
                                                        list

                                                        Perc@ietf.org

                                                        https://www.ietf.org/mailman/listinfo/perc

                                                      

                                                    

                                                  

                                                

                                              

                                              -- 

                                              
s=
ent
                                                from my mobile

                                            

                                          

                                          

                                          -- 

                                          Inviato dal mio dispositivo
                                          Android con K-9 Mail.
                                          Perdonate la brevit=C3=A0.
=

                                      

                                    

                                  

                                

                              

                            

                          

                          -- 

                          
sent
                            from my mobile

                        

                      

                    

                  

                

              

              -- 

              
sent from my mobile

              

              

              
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


            


            

          

        

      

    

  


_______________________________________________
Perc =
mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

=

--Apple-Mail=_750CF8DA-C60A-47E6-8F52-538DF29AFAA5--


From nobody Tue Feb 12 17:56:19 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7BC130E2E for ; Tue, 12 Feb 2019 17:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level: 
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydo3bqAi47mG for ; Tue, 12 Feb 2019 17:56:12 -0800 (PST)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B441295EC for ; Tue, 12 Feb 2019 17:56:11 -0800 (PST)
Received: by mail-it1-x135.google.com with SMTP id p4so104298itc.4 for ; Tue, 12 Feb 2019 17:56:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gtutGmdqitVsm1kdzU7+Plm9JxJMA0s1N1tiEPb4m1U=; b=AuwD80gFtcQP9xDjwWcadKYA35kVzMLddPd2As6G+8gYHGOG7lTtkQ5uwu8eRsSABc FRQY1B108+ppqFM8+hyWEvy6VKu61Nvd8W0Hz407gmC7ghZZwP4AwCEhOgUsu6chV+2d aea7A73L22qJuaRvjbk8aoUkPi4sBtgE4iJxanMDonp6B5rEkO1JFGLtqLXlf7SpEjPu U3dps0zmqL9XMUN2EIA5E1OtQx0ajnmzBnubqSDMj6QhsfgZXP3Y5NDeJV3yh9O9XktO h4LrTYyMeh52P9LGkoyiB6Tb+p5KBdvPPJys4bu6B1WF0hVNri5q+Rp/7X01tvJWje4X XFmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gtutGmdqitVsm1kdzU7+Plm9JxJMA0s1N1tiEPb4m1U=; b=NMXKcieGBHC9BstuNE+/ySzGof9zZDh6TFdsn9NiFZTKkKBKONl1ZzQtyTRRUnzul0 3PQP3yrLjHmeQk9vkM/3QSne+cMGaFVn1wUisRVrr4HYrSFzMi2yFxYjv/f3uzsPNwu+ ia/yQun4btAbCRgS3gTUwZKbHi87wI1BKsStVbNK4/MLBgfz7VI9iqMo5hG9qOS5/cMz 829dJJEzhaJ0zEEEup0WXXimxA0IzQ+EZPWaUZyQXA1BLbwi5tlC8uGaHDq5M2NWC1ND 3DeZcjDTXXhOuYX1mofDK4jeGIcmikow5ZZMkcAYTBECylEcw3cffgekelTE8QkDEI0u 5DtA==
X-Gm-Message-State: AHQUAuZ1w7jWfu2DMc6sRJCw/MNa4wByT8Vk6B6V3caBdTVNMw6j+6jF zhygfDfmb7QeNXEwWz8B54dGdPqxgFpUJQvX9QnOssejzA4=
X-Google-Smtp-Source: AHgI3IZCyTco4fogdbow1c/uKudBzNiCHloeflSUeTmaIHgNGY9fCUiloxhEU+yD6MaD2l5zgCVcnLXX/m/jzWlTDpk=
X-Received: by 2002:a24:738f:: with SMTP id y137mr973227itb.136.1550022969029;  Tue, 12 Feb 2019 17:56:09 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> 
In-Reply-To: 
From: Justin Uberti 
Date: Tue, 12 Feb 2019 17:55:57 -0800
Message-ID: 
To: perc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000076e30f0581bcd822"
Archived-At: 
Subject: [Perc] Fwd: Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 01:56:16 -0000

--00000000000076e30f0581bcd822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Within our team, we have evaluated this design carefully. Beyond the issues
noted here, we believe that the current design suffers from high overhead
(e.g. additional bytes on the wire), as well as latent issues that have not
yet been discussed.

On Tue, Feb 12, 2019 at 5:34 PM 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 the=
re
> 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).
>  https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
>
> 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
>  https://www.ietf.org/proceedings/96/minutes/minutes-96-perc
>
> At IETF 98 SSRC immutability and RTX considerations were discussed but no
> proposal made on security implications
>  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00
>
> 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.
>  https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01
>  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc
>
> Best regards
>  Nils & Suhas
>  PERC WG chairs
>
> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> 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 browse=
r,
> 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?
>
> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> 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* solutio=
n
> for end to end encryption for multiconferencing, as if there was a one si=
ze
> 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 issu=
e
> 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 n=
ot
> 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 isolate=
d
> 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:
>
>
>
> On Sat 2 Feb 2019 at 16:50, Bernard Aboba  wrote=
:
>
>> Emil said:
>>
>> "The need to do a triple encryption for example is a particularly
>> egregious consequence of the order problem. That=E2=80=99s a problem spe=
cific to
>> the =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that this goal is a direct consequence of the framew=
ork=E2=80=99s
> 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 encryptio=
n
> 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 =E2=80=9Cwedging RTX and FEC=E2=80=9D 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
> =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC/RTX=
 will
> simply do a third round of SRTP=E2=80=9D, thus arriving at a total of thr=
ee
> encryptions for every packet..
>
> The discussions around this topic were highly contentious.
>
> Hope this makes things clear,
> Emil
>
>
>
>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:
>>
>>> Yes pretty much those.
>>>
>>> The need to do a triple encryption for example is a particularly
>>> egregious consequence of the order problem. That=E2=80=99s a problem sp=
ecific to
>>> the =E2=80=9Cdouble=E2=80=9D 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 op=
en
>>> was both unnecessary and quite problematic.
>>>
>>> Emil
>>>
>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba 
>>> wrote:
>>>
>>>> "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 w=
here
>>>> 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 th=
is
>>>> 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?
>>>>
>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
>>>> alex.gouaillard@cosmosoftware.io >
>>>> wrote:
>>>>
>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and
>>>>> other topics.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote=
:
>>>>>
>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>>>
>>>>> Lorenzo
>>>>>
>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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 =E2=80=9CSSRC rewriting could n=
ot be
>>>>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC=
, regardless of
>>>>>> what WG leadership is trying to make everyone believe.
>>>>>>
>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>>>>> wrote:
>>>>>>
>>>>>>> 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, forwa=
rding
>>>>>>> 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 d=
o need
>>>>>>> to be able to receive simulcast, what are the requirements for endp=
oints?
>>>>>>> For example, should endpoints expect the MDD to use RID header exte=
nsions
>>>>>>> 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 co=
ntain
>>>>>>> holes because of reordering or loss. This not only complicates the
>>>>>>> application of RTX, RED and FEC, but also the operation of the endp=
oint.
>>>>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, su=
pport
>>>>>>> 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 reord=
ering.
>>>>>>> And neither implementation supports the RID header extension on rec=
eived
>>>>>>> simulcast streams.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>>>>
>>>>>>>> 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 a=
s the
>>>>>>>> Trusted Endpoint for purposes of this framework (just as it acts a=
s 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 tha=
n the
>>>>>>>>    browser.  However, this is unfortunately not possible if we wis=
h 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 t=
hose
>>>>>>>>    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 a=
re 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.m=
d#encryption
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Sergio
>>>>>>>> _______________________________________________
>>>>>>>> Perc mailing list
>>>>>>>> Perc@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>>
>>>>>>> --
>>>>>> sent from my mobile
>>>>>>
>>>>>
>>>>> --
>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=
=C3=A0.
>>>>>
>>>>> --
>>> sent from my mobile
>>>
>> --
> sent from my mobile
>
> _______________________________________________
> Perc mailing listPerc@ietf.orghttps://www.ietf.org/mailman/listinfo/perc
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>

--00000000000076e30f0581bcd822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Within our team, we have evaluated this design carefully. Beyond the=
 issues noted here, we believe that the current design suffers from high ov=
erhead (e.g. additional bytes on the wire), as well as latent issues that h=
ave not yet been discussed.

On Tue, Feb 12, 2019 at 5:34 PM Nils Ohlmeie=
r <nohlmeier@=
mozilla.com> 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 consens=
us and got adopted (after 4 design team meetings and 3 IETF meetings).
https://www.ietf.org/proceedings/95=
/minutes/minutes-95-perc
 
At IETF 96 the WG chairs=
 re-opened the discussions around SSRC mutability and Emil got asked to sub=
mit a draft on the security impact of SSRC mutability
 =C2=A0<=
a href=3D"https://www.ietf.org/proceedings/96/minutes/minutes-96-perc" styl=
e=3D"text-decoration:none" target=3D"_blank">https://www.ietf.org/proceedings/96/minutes/minutes-96=
-perc

At IETF 98 SSRC immutability and RTX considerations wer=
e discussed but no proposal made on security implications

At IETF 99 the double authors and Sergio pres=
ented 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 adopt=
ed.
 =C2=A0https://mailarchive.ietf.org/arch/msg/perc/3=
fPqYTE2qhT351nvp1b7wkf4-bc

Best regards
 =C2=A0Nils &am=
p; Suhas
 =C2=A0PERC WG chairs

On 2Feb, 2019, at 13:37, Sergio Garcia Murillo <sergio.garcia=
.murillo@gmail.com> wrote:


 =20
   =20
 =20
  
PERC may be a valid solution for some scenari=
os, 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:

      

      

       =20
        
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?

        


          On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.mur=
illo@gmail.com>
          wrote:

          

        

        

          

           =20
            
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:

            

            

             =20
              

                


                

                


                

              

              

                
On Sat 2 Feb 2019 at 16:50, Bernard Aboba
                  <bernard.aboba@gmail.com>
                  wrote:

                

                

                  
Emil said:
                    


                    

                    
"The need to do a triple encryption for examp=
le
                      is a particularly egregious consequence of the
                      order problem. That=E2=80=99s a problem specific to t=
he
                      =E2=80=9Cdouble=E2=80=9D documents."

                    


                    

                    
[BA] Can you describe how the need for "tripl=
e
                      encryption" arises?=C2=A0 The framework document
                      doesn't even mention the issues with ordering of
                      FEC/RTX/RED and encryption, let alone the need for
                      "triple encryption".=C2=A0

                  

                

                


                

              

              

                

                  
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.=C2=A0
                  


                  

                  
I don=E2=80=99t know that this goal is =
a
                    direct consequence of the framework=E2=80=99s conceptua=
l
                    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
                    =E2=80=9Cwedging RTX and FEC=E2=80=9D 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.=C2=A0

                  


                  

                  
It was quickly pointed out that this
                    not only destroys the stated =E2=80=9Cdon=E2=80=99t-cha=
nge-the-app=E2=80=9D
                    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:
                    =E2=80=9Cwell, those of you who use FEC/RTX will simply=
 do a
                    third round of SRTP=E2=80=9D, 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

                  


                  

                  


                  

                

              

              

                

                  

                    


                      

                        
On Sat, Feb 2=
,
                          2019 at 11:46 AM Emil Ivov <emcho@jitsi.org>
                          wrote:

                        

                        

                          

                            
Yes pretty much those.

                          

                          


                          

                          
The need to do a triple
                            encryption for example is a particularly
                            egregious consequence of the order problem.
                            That=E2=80=99s a problem specific to the =E2=80=
=9Cdouble=E2=80=9D
                            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 Sat 2 Feb 2019 at 12:23,
                                Bernard Aboba <bernard.aboba@gmail.com>
                                wrote:

                              

                              

                                
"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?=C2=A0=
 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.=C2=A0 Are you saying that you
                                    do not agree that there is an IETF
                                    consensus to publish this document
                                    as a Proposed Standard?=C2=A0 Or that
                                    there is no IETF consensus to
                                    publish *any* of the PERC WG output
                                    as a Proposed Standard?=C2=A0

                                

                                

                                

                                  
On
                                    Sat, Feb 2, 2019 at 5:40 AM
                                    Alexandre GOUAILLARD <alex.gouaillard@co=
smosoftware.io>
                                    wrote:

                                  

                                  

                                    
+1 on ssrc
                                      rewriting, and on the consensus
                                      not reached on this and other
                                      topics.

                                      

                                      
Sent from my iPhone
                                      


                                        On 2 Feb 2019, at 17:18, Lorenzo
                                        Miniero <lorenzo@meetecho.com>
                                        wrote:

                                        

                                      

                                      

                                        
+1, SSRC
                                          rewriting is pretty much
                                          fundamental to all SFUs out
                                          there.

                                          

                                          Lorenzo

                                          

                                          
Il 2
                                            febbraio 2019 10:19:06 CET,
                                            Emil Ivov <emcho@jitsi.org>
                                            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 =E2=80=9CSSRC rewritin=
g
                                                could not be allowed=E2=80=
=9D is
                                                a conclusion that ever
                                                had any consensus in
                                                PERC, regardless of what
                                                WG leadership is trying
                                                to make everyone
                                                believe.

                                              


                                                

                                                  
On Sat
                                                    2 Feb 2019 at 06:21,
                                                    Bernard Aboba <bernard.aboba@gmail=
.com>
                                                    wrote:

                                                  

                                                  

                                                    
Richar=
d
                                                      said:
                                                      


                                                      

                                                      
"Again,
                                                          the answer is
                                                          clear here,
                                                          but the
                                                          document
                                                          should be
                                                          clearer.=C2=A0 Th=
e
                                                          working group
                                                          discussed SSRC
                                                          rewriting
                                                          several times,
                                                          and concluded
                                                          that SSRC
                                                          rewriting
                                                          could not be
                                                          allowed in
                                                          this system.=C2=
=A0
                                                          This decision
                                                          is reflected,
                                                          e.g., in the
                                                          fact that the
                                                          Double
                                                          transform does
                                                          not allow
                                                          modification
                                                          of SSRCs.&=
quot;

                                                      


                                                      

                                                      
[BA]=C2=A0 Not
                                                        being able to
                                                        rewrite SSRCs
                                                        has some major
                                                        implications
                                                        with respect to
                                                        requirements on
                                                        PERC endpoints.=C2=
=A0
                                                        Typically
                                                        today's MDD wil=
l
                                                        switch between
                                                        the simulcast
                                                        streams provided
                                                        by an endpoint,
                                                        forwarding only
                                                        a single stream
                                                        to other
                                                        participants,
                                                        based on the
                                                        bandwidth,
                                                        resolution and
                                                        framerates.=C2=A0 I=
f
                                                        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?=C2=A0 Fo=
r
                                                        example, should
                                                        endpoints expect
                                                        the MDD to use
                                                        RID header
                                                        extensions to
                                                        identify the
                                                        incoming
                                                        simulcast
                                                        streams?=C2=A0
                                                      


                                                      

                                                      
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.=C2=A0
                                                        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.=C2=A0 A=
nd
                                                        neither
                                                        implementation
                                                        supports the RID
                                                        header extension
                                                        on received
                                                        simulcast
                                                        streams.

                                                      


                                                      

                                                      


                                                      

                                                      


                                                      

                                                    

                                                    

                                                    

                                                      
On
                                                        Fri, Feb 1, 2019
                                                        at 12:23 PM
                                                        Sergio Garcia
                                                        Murillo <sergio.garcia=
.murillo@gmail.com>
                                                        wrote:

                                                      

                                                      

                                                        

                                                          
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).

                                                          
<=
br>
                                                          
If we
                                                          decide to
                                                          adopt perc
                                                          (big if) in
                                                          webrtc,
                                                          shouldn't thi=
s
                                                          be defined
                                                          within the https://to=
ols.ietf.org/html/draft-ietf-rtcweb-security-arch-17
                                                          doc ?

                                                          


                                                          

                                                          
   Optimall=
y, 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#e=
ncryption

                                                          
Best
                                                          regards
Ser=
gio

                                                          

                                                        

_______________________________________________

                                                        Perc mailing
                                                        list

                                                        Perc@ietf.org

                                                        ht=
tps://www.ietf.org/mailman/listinfo/perc

                                                      

                                                    

                                                  

                                                

                                              

                                              -- 

                                              
sent
                                                from my mobile

                                            

                                          

                                          

                                          -- 

                                          Inviato dal mio dispositivo
                                          Android con K-9 Mail.
                                          Perdonate la brevit=C3=A0.

                                      

                                    

                                  

                                

                              

                            

                          

                          -- 

                          
sent
                            from my mobile

                        

                      

                    

                  

                

              

              -- 

              
sent from my mobil=
e

              

              

              
________________________________=
_______________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


            


            

          

        

      

    

  


_______________________________________________
Perc mailing list
Perc@ietf.org
https://=
www.ietf.org/mailman/listinfo/perc

_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc






--00000000000076e30f0581bcd822--


From nobody Wed Feb 13 02:37:47 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAD212894E for ; Wed, 13 Feb 2019 02:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7nJyo6fwxMq for ; Wed, 13 Feb 2019 02:37:36 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016101274D0 for ; Wed, 13 Feb 2019 02:37:35 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id n32so1907252qte.11 for ; Wed, 13 Feb 2019 02:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dK8cTkLZzUU2uobTxztM+JtTx6os4gyz9zNXgKTppvM=; b=dOGRGCwkzKdtkSTJNqQuyWnV/oUc0/cgO2jSBFzAoHNJJryHlt6N9QsBrYprxvAx3N gGujxYPQfoCDIjXTcHklcgiKOIKbJ3Uss1SLfvQrQN+o0PUpL/2dFED9PHMlMcesbYTi sThIs4QaG5b0wVSKj7wipkd23cNzQTX7ktj/oZrUNsew5/PEhT49cgDUj1s3MY8Zkq9O S2jUk+SbMw82+5Vif3iNaQ0CucINhjNR3zpDIkNFh0ci+mUGnK/51JXFaEhoLp8dCzYS 6fdxKqGIbYeAjr4txdha2ry3dh3SrlpgdSmxdHYuBN09iRfjDsmCYPzBs1BxqT74sVcD xZEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dK8cTkLZzUU2uobTxztM+JtTx6os4gyz9zNXgKTppvM=; b=ZYwBIARGqOL589gVm7bAkgOG0MQds9IqrsVixeT3odJz1PYbXz3YBzDfHJ6agsVj3H tkFG2t69ytdt2zujF6NPurBfX4veWEagDNCR4+gyXeaawGd926DfJ1OzCbsbqTkdeMWv o1xij9pR1myQxX6RXRu8t/pwyyWSQoGUkp4vstPdceZWDzfwXRaMTmWsQ+8rmbBsisSc VfaAMp1PahzMfeXl2f2958dngk4Zz1pd0IVCCFGYWO1N5qA1FJU6xQtJCdgw0zH8/nja AHj78wISXUPF1qMsEYuZ3MQnZZ2oN4yV80WWjbjavpFCzsQ/drBd07KLhSm9F1JRVVkD y2aQ==
X-Gm-Message-State: AHQUAuZqjLn0nSjWZW1YtBgAB051wQhcgTARItm39YONdePf0Vq5M+Zw Yo7DvDuHBvqh8tbFdleozz0yC3e/whpqal4L0rp5eQ==
X-Google-Smtp-Source: AHgI3IYtmXuIB5mj+QHfAZmu/f/eyVQCPROUp0YlOZpurHYrzLDryE2RVDYaPTbZ3MLZCFF5H/ZpHRJ/b4VzNW58Ars=
X-Received: by 2002:a0c:b6c3:: with SMTP id h3mr6336351qve.128.1550054254403;  Wed, 13 Feb 2019 02:37:34 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>
In-Reply-To: <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>
From: Emil Ivov 
Date: Wed, 13 Feb 2019 10:37:21 +0000
Message-ID: 
To: Nils Ohlmeier 
Cc: Sergio Garcia Murillo ,  Bernard Aboba , IETF discussion list ,  Emad Omara , perc@ietf.org, "hta@google.com" ,  Alexandre GOUAILLARD , Lorenzo Miniero 
Content-Type: multipart/alternative; boundary="0000000000003799490581c42123"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 10:37:41 -0000

--0000000000003799490581c42123
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nils,

I'd like to correct you on a point here:

On Wed, Feb 13, 2019 at 1:34 AM 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 the=
re
> 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).
>  https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
>
> 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
>  https://www.ietf.org/proceedings/96/minutes/minutes-96-perc
>
> At IETF 98 SSRC immutability and RTX considerations were discussed but no
> proposal made on security implications
>  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00
>

This is really quite misleading:

We did indeed have a discussion on this was on IETF 96 (Berlin) where I was
asked
to describe how this works in a draft, which we did:

https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

We then talked about it in Chicago (IETF 98) . No one implied security
issues any more. This never was a problem.

No decision was reached and the topic was left open but it had nothing to
do with the security implications of either approach and the lack of
consensus was primarily driven by implementation convenience.

The discussion then morphed into RTX/FEC handling for which we've also made
submissions.

https://mailarchive.ietf.org/arch/msg/perc/eR_1o1Aj8fDBmrEzA0jgL4IL1e4

Eventually, at some point the chairs decided to declare consensus where
there wasn't any and the WG just ploughed through. That's where I
personally disconnected and I have been waiting for last call to voice
these concerns ever since.

The entire WG mode of operation has been an egregious violation of the main
principles that the IETF stands for.

Regards,
Emil


>
> 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.
>  https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01
>  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc
>
> Best regards
>  Nils & Suhas
>  PERC WG chairs
>
> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> 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 browse=
r,
> 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?
>
> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> 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* solutio=
n
> for end to end encryption for multiconferencing, as if there was a one si=
ze
> 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 issu=
e
> 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 n=
ot
> 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 isolate=
d
> 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:
>
>
>
> On Sat 2 Feb 2019 at 16:50, Bernard Aboba  wrote=
:
>
>> Emil said:
>>
>> "The need to do a triple encryption for example is a particularly
>> egregious consequence of the order problem. That=E2=80=99s a problem spe=
cific to
>> the =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that this goal is a direct consequence of the framew=
ork=E2=80=99s
> 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 encryptio=
n
> 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 =E2=80=9Cwedging RTX and FEC=E2=80=9D 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
> =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC/RTX=
 will
> simply do a third round of SRTP=E2=80=9D, thus arriving at a total of thr=
ee
> encryptions for every packet..
>
> The discussions around this topic were highly contentious.
>
> Hope this makes things clear,
> Emil
>
>
>
>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov  wrote:
>>
>>> Yes pretty much those.
>>>
>>> The need to do a triple encryption for example is a particularly
>>> egregious consequence of the order problem. That=E2=80=99s a problem sp=
ecific to
>>> the =E2=80=9Cdouble=E2=80=9D 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 op=
en
>>> was both unnecessary and quite problematic.
>>>
>>> Emil
>>>
>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba 
>>> wrote:
>>>
>>>> "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 w=
here
>>>> 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 th=
is
>>>> 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?
>>>>
>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD <
>>>> alex.gouaillard@cosmosoftware.io >
>>>> wrote:
>>>>
>>>>> +1 on ssrc rewriting, and on the consensus not reached on this and
>>>>> other topics.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero  wrote=
:
>>>>>
>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out there.
>>>>>
>>>>> Lorenzo
>>>>>
>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov  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 =E2=80=9CSSRC rewriting could n=
ot be
>>>>>> allowed=E2=80=9D is a conclusion that ever had any consensus in PERC=
, regardless of
>>>>>> what WG leadership is trying to make everyone believe.
>>>>>>
>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba 
>>>>>> wrote:
>>>>>>
>>>>>>> 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, forwa=
rding
>>>>>>> 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 d=
o need
>>>>>>> to be able to receive simulcast, what are the requirements for endp=
oints?
>>>>>>> For example, should endpoints expect the MDD to use RID header exte=
nsions
>>>>>>> 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 co=
ntain
>>>>>>> holes because of reordering or loss. This not only complicates the
>>>>>>> application of RTX, RED and FEC, but also the operation of the endp=
oint.
>>>>>>> As a result, as noted in the WEBRTC specification Section 5.4.1, su=
pport
>>>>>>> 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 reord=
ering.
>>>>>>> And neither implementation supports the RID header extension on rec=
eived
>>>>>>> simulcast streams.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo <
>>>>>>> sergio.garcia.murillo@gmail.com> wrote:
>>>>>>>
>>>>>>>> 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 a=
s the
>>>>>>>> Trusted Endpoint for purposes of this framework (just as it acts a=
s 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 tha=
n the
>>>>>>>>    browser.  However, this is unfortunately not possible if we wis=
h 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 t=
hose
>>>>>>>>    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 a=
re 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.m=
d#encryption
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Sergio
>>>>>>>> _______________________________________________
>>>>>>>> Perc mailing list
>>>>>>>> Perc@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>>
>>>>>>> --
>>>>>> sent from my mobile
>>>>>>
>>>>>
>>>>> --
>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=
=C3=A0.
>>>>>
>>>>> --
>>> sent from my mobile
>>>
>> --
> sent from my mobile
>
> _______________________________________________
> Perc mailing listPerc@ietf.orghttps://www.ietf.org/mailman/listinfo/perc
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>
>
>

--=20
https://jitsi.org

--0000000000003799490581c42123
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nils,=C2=A0

I'd like to correct you on a point here:

On Wed, Feb 13, 20=
19 at 1:34 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Thank you for the input on the framewor=
k and the double documents from everyone.

The points raised by th=
e 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 I=
ETF 95 double had consensus and got adopted (after 4 design team meetings a=
nd 3 IETF meetings).
 
A=
t IETF 96 the WG chairs re-opened the discussions around SSRC mutability an=
d Emil got asked to submit a draft on the security impact of SSRC mutabilit=
y

At IETF 98 SSRC immutability and=
 RTX considerations were discussed but no proposal made on security implica=
tions
<=
div>
This is really quite misleading:

We did in=
deed have a discussion on this was on IETF 96 (Berlin) where I was askedto describe how this works in a draft, which we did:

https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

We then tal=
ked about it in Chicago (IETF 98) . No one implied security issues any more=
. This never was a problem.

No decision was reache=
d and the topic was left open but it had nothing to do with the security im=
plications of either approach and the lack of consensus was primarily drive=
n by implementation convenience.

The discussio=
n then morphed=C2=A0into RTX/FEC handling for which we've also made sub=
missions.


Eve=
ntually, at some point the chairs decided to declare consensus where there =
wasn't any and the WG just ploughed through. That's where I persona=
lly disconnected and I have been waiting for last call to voice these conce=
rns ever since.

The entire WG mode of operation ha=
s been an egregious violation of the main principles that the IETF stands f=
or.

Regards,
Emil
=C2=A0
=


At IETF 99 the double =
authors and Sergio presented a joint proposal. The WG chairs called for con=
sensus in the room and on the list and concluded that with rough consensus,=
 the proposal got adopted.

Best regard=
s
 =C2=A0Nils & Suhas
 =C2=A0PERC WG chairs

On 2Feb, 2019, at 13:37, Sergio Garcia=
 Murillo <sergio.garcia.murillo@gmail.com> wrote:


 =20
   =20
 =20
  
PERC may be a valid solution for some scenari=
os, 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:

      

      

       =20
        
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?

        


          On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.mur=
illo@gmail.com>
          wrote:

          

        

        

          

           =20
            
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:

            

            

             =20
              

                


                

                


                

              

              

                
On Sat 2 Feb 2019 at 16:50, Bernard Aboba
                  <bernard.aboba@gmail.com>
                  wrote:

                

                

                  
Emil said:
                    


                    

                    
"The need to do a triple encryption for examp=
le
                      is a particularly egregious consequence of the
                      order problem. That=E2=80=99s a problem specific to t=
he
                      =E2=80=9Cdouble=E2=80=9D documents."

                    


                    

                    
[BA] Can you describe how the need for "tripl=
e
                      encryption" arises?=C2=A0 The framework document
                      doesn't even mention the issues with ordering of
                      FEC/RTX/RED and encryption, let alone the need for
                      "triple encryption".=C2=A0

                  

                

                


                

              

              

                

                  
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.=C2=A0
                  


                  

                  
I don=E2=80=99t know that this goal is =
a
                    direct consequence of the framework=E2=80=99s conceptua=
l
                    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
                    =E2=80=9Cwedging RTX and FEC=E2=80=9D 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.=C2=A0

                  


                  

                  
It was quickly pointed out that this
                    not only destroys the stated =E2=80=9Cdon=E2=80=99t-cha=
nge-the-app=E2=80=9D
                    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:
                    =E2=80=9Cwell, those of you who use FEC/RTX will simply=
 do a
                    third round of SRTP=E2=80=9D, 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

                  


                  

                  


                  

                

              

              

                

                  

                    


                      

                        
On Sat, Feb 2=
,
                          2019 at 11:46 AM Emil Ivov <emcho@jitsi.org>
                          wrote:

                        

                        

                          

                            
Yes pretty much those.

                          

                          


                          

                          
The need to do a triple
                            encryption for example is a particularly
                            egregious consequence of the order problem.
                            That=E2=80=99s a problem specific to the =E2=80=
=9Cdouble=E2=80=9D
                            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 Sat 2 Feb 2019 at 12:23,
                                Bernard Aboba <bernard.aboba@gmail.com>
                                wrote:

                              

                              

                                
"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?=C2=A0=
 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.=C2=A0 Are you saying that you
                                    do not agree that there is an IETF
                                    consensus to publish this document
                                    as a Proposed Standard?=C2=A0 Or that
                                    there is no IETF consensus to
                                    publish *any* of the PERC WG output
                                    as a Proposed Standard?=C2=A0

                                

                                

                                

                                  
On
                                    Sat, Feb 2, 2019 at 5:40 AM
                                    Alexandre GOUAILLARD <alex.gouaillard@co=
smosoftware.io>
                                    wrote:

                                  

                                  

                                    
+1 on ssrc
                                      rewriting, and on the consensus
                                      not reached on this and other
                                      topics.

                                      

                                      
Sent from my iPhone

                                      


                                        On 2 Feb 2019, at 17:18, Lorenzo
                                        Miniero <lorenzo@meetecho.com>
                                        wrote:

                                        

                                      

                                      

                                        
+1, SSRC
                                          rewriting is pretty much
                                          fundamental to all SFUs out
                                          there.

                                          

                                          Lorenzo

                                          

                                          
Il 2
                                            febbraio 2019 10:19:06 CET,
                                            Emil Ivov <emcho@jitsi.org>
                                            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 =E2=80=9CSSRC rewritin=
g
                                                could not be allowed=E2=80=
=9D is
                                                a conclusion that ever
                                                had any consensus in
                                                PERC, regardless of what
                                                WG leadership is trying
                                                to make everyone
                                                believe.

                                              


                                                

                                                  
On Sat
                                                    2 Feb 2019 at 06:21,
                                                    Bernard Aboba <bernard.aboba@gmail=
.com>
                                                    wrote:

                                                  

                                                  

                                                    
Richar=
d
                                                      said:
                                                      


                                                      

                                                      
"Again,
                                                          the answer is
                                                          clear here,
                                                          but the
                                                          document
                                                          should be
                                                          clearer.=C2=A0 Th=
e
                                                          working group
                                                          discussed SSRC
                                                          rewriting
                                                          several times,
                                                          and concluded
                                                          that SSRC
                                                          rewriting
                                                          could not be
                                                          allowed in
                                                          this system.=C2=
=A0
                                                          This decision
                                                          is reflected,
                                                          e.g., in the
                                                          fact that the
                                                          Double
                                                          transform does
                                                          not allow
                                                          modification
                                                          of SSRCs.&=
quot;

                                                      


                                                      

                                                      
[BA]=C2=A0 Not
                                                        being able to
                                                        rewrite SSRCs
                                                        has some major
                                                        implications
                                                        with respect to
                                                        requirements on
                                                        PERC endpoints.=C2=
=A0
                                                        Typically
                                                        today's MDD wil=
l
                                                        switch between
                                                        the simulcast
                                                        streams provided
                                                        by an endpoint,
                                                        forwarding only
                                                        a single stream
                                                        to other
                                                        participants,
                                                        based on the
                                                        bandwidth,
                                                        resolution and
                                                        framerates.=C2=A0 I=
f
                                                        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?=C2=A0 Fo=
r
                                                        example, should
                                                        endpoints expect
                                                        the MDD to use
                                                        RID header
                                                        extensions to
                                                        identify the
                                                        incoming
                                                        simulcast
                                                        streams?=C2=A0
                                                      


                                                      

                                                      
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.=C2=A0
                                                        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.=C2=A0 A=
nd
                                                        neither
                                                        implementation
                                                        supports the RID
                                                        header extension
                                                        on received
                                                        simulcast
                                                        streams.

                                                      


                                                      

                                                      


                                                      

                                                      


                                                      

                                                    

                                                    

                                                    

                                                      
On
                                                        Fri, Feb 1, 2019
                                                        at 12:23 PM
                                                        Sergio Garcia
                                                        Murillo <sergio.garcia=
.murillo@gmail.com>
                                                        wrote:

                                                      

                                                      

                                                        

                                                          
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).

                                                          
<=
br>
                                                          
If we
                                                          decide to
                                                          adopt perc
                                                          (big if) in
                                                          webrtc,
                                                          shouldn't thi=
s
                                                          be defined
                                                          within the https://tools.ietf.org/html/d=
raft-ietf-rtcweb-security-arch-17
                                                          doc ?

                                                          


                                                          

                                                          
   Optimally, we would not rel=
y 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://githu=
b.com/WICG/media-capabilities/blob/master/explainer.md#encryption

                                                          
Best
                                                          regards
Ser=
gio

                                                          

                                                        

_______________________________________________

                                                        Perc mailing
                                                        list

                                                        Perc@ietf.org

                                                        ht=
tps://www.ietf.org/mailman/listinfo/perc

                                                      

                                                    

                                                  

                                                

                                              

                                              -- 

                                              
sent
                                                from my mobile

                                            

                                          

                                          

                                          -- 

                                          Inviato dal mio dispositivo
                                          Android con K-9 Mail.
                                          Perdonate la brevit=C3=A0.

                                      

                                    

                                  

                                

                              

                            

                          

                          -- 

                          
sent
                            from my mobile

                        

                      

                    

                  

                

              

              -- 

              
sent from my mobile

              

              

              
_______________________________________________
Perc mailing list
Perc@iet=
f.org
https://www.ietf.org/mailman/listinfo/perc


            


            

          

        

      

    

  


_______________________________________________
Perc mailing list
Perc@ietf.org
https://=
www.ietf.org/mailman/listinfo/perc



-- 
https://jitsi.org


--0000000000003799490581c42123--


From nobody Wed Feb 13 02:48:42 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A01128B01; Wed, 13 Feb 2019 02:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6M9SGmHIFIn; Wed, 13 Feb 2019 02:48:36 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C64E12894E; Wed, 13 Feb 2019 02:48:36 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id t200so1901117wmt.0; Wed, 13 Feb 2019 02:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=pcgX2fNhg73ex0iHwJHBSVwwrNPUDh+G9H73ZylV0Fo=; b=ONtX9YAflqcLNxwCSMtxdtf2SWdG8VQzejT6EpYLW5TpHkdAHRxM6t63iRl8qnSCfR HfRKDRA1qaYQomvu9Na0oKZDYhPk4iNBMTHEJpfjtyXsXWvT+yj8BmPyBU08jzm9QBta exeZdeELc0ohooAQfmwnjKjP0Y+fFTfVpeSpZOk9TRnNzlkP8cDGwZ8hJgaxIgtPCtW1 dxtrhHn9Im9FW6SI5IqKVlhWbMwInq6fPRJNBkfubT/fzhg0/PrjWU8jTUWQ9eIbuvd4 szJwgMg9UT/1Fu7ZjkG7QgHu23s/qq5o3g7yZYWGOjatI6eBlk78SQXTO30xwxeojLaH 8gIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=pcgX2fNhg73ex0iHwJHBSVwwrNPUDh+G9H73ZylV0Fo=; b=ReXEmHOCdywq5hsUk9QW2kOVcksqpDHodAOsUHSw/WFvdH1LbWPOZrFc5Q4iAj1DKr xLA6d/HLrwslOZVu5v7SKvbuiFDgpi/lpMvCH/WUsw8w6EYcr0bZ7ncmrcSRGfGphj/9 OQB2df61vkuGNJcfKkb+uavtw68YFN3KGwdKOHqdGg42f/Owwui+E+LHWXsR41IDWu3X 7j0wiaSV/3fdmmoNGCVpEZhGyH6MTHR20MH9J6EKVuomzBHX9t3sfqSfwj24xOUzghgS OWM/01IP/8VLp+YFX1j/AsO1FqHP+OJEkdbJzbbGoFv2H0GpENdZBAeWsojDNxNmLakK hEeg==
X-Gm-Message-State: AHQUAuZjvILFt7Zgi7pR4O53CYHL6J+JMEEbsYuB2y39T6BEfY4Lnq3c F9BNZkohcjWwU3Etbz9UzLg=
X-Google-Smtp-Source: AHgI3Ia0gErJF8LCvGgMUuuWJD1clr4ySoAKGF0y8mLCtLt88ir1TpFXLjCsGpib2PufelP13+gUpw==
X-Received: by 2002:a7b:c14f:: with SMTP id z15mr2641128wmi.141.1550054914233;  Wed, 13 Feb 2019 02:48:34 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id c129sm3480936wma.48.2019.02.13.02.48.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 02:48:33 -0800 (PST)
To: Nils Ohlmeier 
Cc: Bernard Aboba , IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>  <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>
From: Sergio Garcia Murillo 
Message-ID: <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com>
Date: Wed, 13 Feb 2019 11:53:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>
Content-Type: multipart/alternative; boundary="------------EDCFBC9DF8CBBA4A22A4F613"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 10:48:41 -0000

This is a multi-part message in MIME format.
--------------EDCFBC9DF8CBBA4A22A4F613
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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
https://datatracker.ietf.org/liaison/1614/

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).
> https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
>
> 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
> https://www.ietf.org/proceedings/96/minutes/minutes-96-perc
>
> At IETF 98 SSRC immutability and RTX considerations were discussed but 
> no proposal made on security implications
> https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00
>
> 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.
> https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01
> https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc
>
> Best regards
>  Nils & Suhas
>  PERC WG chairs
>
>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo 
>> > > wrote:
>>
>> 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?
>>>>
>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo 
>>>> >>> > wrote:
>>>>
>>>>> 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:
>>>>>>
>>>>>>
>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba 
>>>>>> > 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov >>>>>     > wrote:
>>>>>>
>>>>>>         Yes pretty much those.
>>>>>>
>>>>>>         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 Sat 2 Feb 2019 at 12:23, Bernard Aboba
>>>>>>         >>>>>         > wrote:
>>>>>>
>>>>>>             "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?
>>>>>>
>>>>>>             On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD
>>>>>>             >>>>>             > wrote:
>>>>>>
>>>>>>                 +1 on ssrc rewriting, and on the consensus not
>>>>>>                 reached on this and other topics.
>>>>>>
>>>>>>                 Sent from my iPhone
>>>>>>
>>>>>>                 On 2 Feb 2019, at 17:18, Lorenzo Miniero
>>>>>>                 >>>>>                 > wrote:
>>>>>>
>>>>>>>                 +1, SSRC rewriting is pretty much fundamental to
>>>>>>>                 all SFUs out there.
>>>>>>>
>>>>>>>                 Lorenzo
>>>>>>>
>>>>>>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>>>>>>                 > 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.
>>>>>>>
>>>>>>>                     On Sat 2 Feb 2019 at 06:21, Bernard Aboba
>>>>>>>                     >>>>>>                     > wrote:
>>>>>>>
>>>>>>>                         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 Fri, Feb 1, 2019 at 12:23 PM Sergio
>>>>>>>                         Garcia Murillo
>>>>>>>                         >>>>>>                         >
>>>>>>>                         wrote:
>>>>>>>
>>>>>>>                             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@ietf.org 
>>>>>>>                             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@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>
>>>>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/perc
>


--------------EDCFBC9DF8CBBA4A22A4F613
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
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

    

    
https://datatracker.ietf.org/liaison/1614/

    

    


    

    
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

      


        

          
On 2Feb, 2019, at 13:37, Sergio Garcia Murillo
            <sergio.garcia.murillo@gmail.com>
            wrote:

          

          

            
            

              
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?

                  


                    On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo
                    <sergio.garcia.murillo@gmail.com>
                    wrote:

                    

                  

                  

                    

                      
                      
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:

                      

                      

                        
                        

                          


                          

                          


                          

                        

                        

                          
On Sat 2 Feb 2019 at
                            16:50, Bernard Aboba <bernard.aboba@gmail.com>
                            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

                            


                            

                            


                            

                          

                        

                        

                          

                            

                              


                                

                                  
On
                                    Sat, Feb 2, 2019 at 11:46 AM Emil
                                    Ivov <emcho@jitsi.org>
                                    wrote:

                                  

                                  

                                    

                                      
Yes
                                        pretty much those.

                                    

                                    


                                    

                                    
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 Sat 2
                                          Feb 2019 at 12:23, Bernard
                                          Aboba <bernard.aboba@gmail.com>
                                          wrote:

                                        

                                        

                                          
"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? 

                                          

                                          

                                          

                                            
On Sat,
                                              Feb 2, 2019 at 5:40 AM
                                              Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>
                                              wrote:

                                            

                                            

                                              
+1
                                                on ssrc rewriting, and
                                                on the consensus not
                                                reached on this and
                                                other topics.

                                                

                                                
Sent
                                                  from my iPhone

                                                


                                                  On 2 Feb 2019, at
                                                  17:18, Lorenzo Miniero
                                                  <lorenzo@meetecho.com>
                                                  wrote:

                                                  

                                                

                                                

                                                  
+1, SSRC
                                                    rewriting is pretty
                                                    much fundamental to
                                                    all SFUs out there.

                                                    

                                                    Lorenzo

                                                    

                                                    
Il
                                                      2 febbraio 2019
                                                      10:19:06 CET, Emil
                                                      Ivov <emcho@jitsi.org> 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.

                                                        


                                                          

                                                          
On
                                                          Sat 2 Feb 2019
                                                          at 06:21,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo
                                                          <sergio.garcia.murillo@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
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@ietf.org

                                                          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@ietf.org
https://www.ietf.org/mailman/listinfo/perc


                      

                      


                      

                    

                  

                

              

            

            _______________________________________________

            Perc mailing list

            Perc@ietf.org

            https://www.ietf.org/mailman/listinfo/perc

          

        

      

      

    

    


    

  


--------------EDCFBC9DF8CBBA4A22A4F613--


From nobody Wed Feb 13 07:41:40 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529C9129441; Wed, 13 Feb 2019 07:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQS3ug5lLkvg; Wed, 13 Feb 2019 07:41:27 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5B3126C7E; Wed, 13 Feb 2019 07:41:27 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id f132so1307189pfa.6; Wed, 13 Feb 2019 07:41:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JMwo1BqN+JoO4dAyrwxU4GdPVoerYKLjVU88+rG9xcM=; b=CsYf2LQ6xOFSuTcEOoqW76Q6IVYnwYgTDqIBpV+8AQ2g2u1b3WvRcgE9p3QSBkYwu1 172IE326P7hpv3aN19qlOw5wrjY13yMj/Ezq9Hbgtsd4P3wGEJvbSm63f6f8rSCFSkEh VDrxYpNMTBY+EVJdGdsMpIGU1soX9SMX3mhohS2RHvQVB7YjYyhLVQySYBoTjp8d8ljO BexfDTYqXkLLVrT/9x6B7tS6Osr7s1qjU/kdQlsO6KkM84O/7dzsh4oG/1qsdrLLmoIk LLM0OOnynFUHimzOqmUvrDVBWXMUFlid5dh0AtCp3YWapkgHHdIeKftlM16WlNt2lEE/ KNZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JMwo1BqN+JoO4dAyrwxU4GdPVoerYKLjVU88+rG9xcM=; b=EhjQmFU0SiuxevYMkrLC2h1aCYK9U9ftyhWwYKH7uYDKcW31kyNqIc/EX4BLkWIgBD GEfr2TUdAXpHtC+nn5RURE7kwXx5LujxVUB3gb3yN0U+3KCZJLSNo0yei1ASKV1rFY14 9wpdJX4lHl7HNUhWrk7WTA9Gnoht6yr2h2iKAW8Do18Mne/lln6MYINn3lCN/ilwZU+X iA4CUPgVxOaLeHgCKtS1ZsuTRlliRYL5lZ3shJfAe+k5TJQoN9EChKxC3kLqbPikoflF Sw1GtIZqRSOlagiZCKaviJNuzBZZoby0lbgvvZNyh1ffKDSmArxt7awYaJ8DTEQSWSot 76BQ==
X-Gm-Message-State: AHQUAuZDFyWSGxlyE+LgWxDfdOZNXJSieRaVnoEN+KMpXghsW9J0rrr/ zpBRh16z4ErncJEC90ajF2Y=
X-Google-Smtp-Source: AHgI3IYuL2iA4tjOMtEii7GZJMtmpkHHOvMazXVy8cIEHgOBb+yTjgKSxtzT9A7f3g582GxuF8x5fw==
X-Received: by 2002:a63:a:: with SMTP id 10mr990755pga.121.1550072486500; Wed, 13 Feb 2019 07:41:26 -0800 (PST)
Received: from [192.168.1.104] (c-98-225-39-241.hsd1.wa.comcast.net. [98.225.39.241]) by smtp.gmail.com with ESMTPSA id m67sm28772602pfm.73.2019.02.13.07.41.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 07:41:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com>
Date: Wed, 13 Feb 2019 07:41:24 -0800
Cc: Nils Ohlmeier , IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
Content-Transfer-Encoding: quoted-printable
Message-Id: <632D3A5E-0F15-40D8-B6F8-1307ECDCDBC9@gmail.com>
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>  <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com>
To: Sergio Garcia Murillo 
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 15:41:30 -0000

On Feb 13, 2019, at 2:53 AM, Sergio Garcia Murillo  wrote:
>=20
> This liaison statement basically blows away any rough consensus from IETF 9=
9 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 s=
tudied without involving the PERC group.

[BA] Is there documentation on the PERC-lite proposal? Does it avoid the pro=
blems with FEC/RTX processing and Triple protection? Has it been deployed?=


From nobody Wed Feb 13 09:12:35 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C40130DE9; Wed, 13 Feb 2019 09:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juHU1o2xjzr8; Wed, 13 Feb 2019 09:12:30 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C137E1288BD; Wed, 13 Feb 2019 09:12:29 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id r2so3368940wrv.10; Wed, 13 Feb 2019 09:12:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=th4S9HwI226H+6alob99/9x0DAfJak5O+hPh1C7TbhM=; b=YLrSGKj81skwFpjwm6zzbZMbOdI1nUW7/2yJFYoGHoW7DQVZr51aYaTfp9r/VaTbzk y9q3GsKs8ygfflokeSKDfMMCqlpKTj/wt4wbLCqDVE7ojNrV6yoUQXWUSYUytVzrkzD9 Olw/1ymAlSch/bTOuRkBsjy4bj10BXNH7ummktrkbjlVwo+BEypOT7fxsV1VhkSg80L+ wH+pec0Z5eIiX6wcwc0WjENvWlplzJ/A7g7i7o/ZqxvUUaTWoqVdwgxB3zYIy/RkbiN9 e4J7ofPkQm5tlHX5YlJanpyCUUAzyzwBH2OY4/2w6Uk4onXcc+wf0JiJM2uDL4ICQ4IP KRDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=th4S9HwI226H+6alob99/9x0DAfJak5O+hPh1C7TbhM=; b=Fj/GAwPtH2KpXvwEtpQl1IT4wvFA5a5sfwqpH4vTFddryN6APBXDqI17nUPpabaAnu tBURaNE6Jo7Q4ApbHagZJOeeOCtkBY26SQ3/vUP3bz2N8G+Xsrd4UPAa0AnnNKvAbL0J skTQZzByjTVwkO/t3muRazkxN+LLOWkFGKPuPwy6gGqPnY5QpbAg7+HSHzKPkYK7fXQu 5qZaq3rpVXxnLpDknxZz7BxnYn1RSFdxE2kFSg94zAZvLAb9wmwYHwAdiZXDeSyzTUzr Y+sHoSSUiNITve3Q/ItVjGL9gEWVxlfRWS4QXJVsNsRfHJmOc7CBijV3qE5HArSKJ0oX fY2Q==
X-Gm-Message-State: AHQUAuaj4wgHRI88ebSMqI8x/2tu9DLpyWpZNw3zyl2bG80uo5KCj2kR fSoxcFfmfG2/ydaGNPS+Q1M9rijN
X-Google-Smtp-Source: AHgI3IZNwGdWcyBYTycVh8+uk1xcgc5w1Lp73sMTNsz6TW91Of96vSMXeGxNnDQhZOZrDWqNChI7sQ==
X-Received: by 2002:adf:eb85:: with SMTP id t5mr1162674wrn.157.1550077947910;  Wed, 13 Feb 2019 09:12:27 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id n3sm8673477wmf.46.2019.02.13.09.12.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 09:12:27 -0800 (PST)
From: Sergio Garcia Murillo 
To: Bernard Aboba 
Cc: Nils Ohlmeier , IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <632D3A5E-0F15-40D8-B6F8-1307ECDCDBC9@gmail.com>
Message-ID: <96e177cb-a407-bd41-767d-5f0951fb7ee8@gmail.com>
Date: Wed, 13 Feb 2019 18:17:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <632D3A5E-0F15-40D8-B6F8-1307ECDCDBC9@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 17:12:32 -0000

On 13/02/2019 16:41, Bernard Aboba wrote:
> On Feb 13, 2019, at 2:53 AM, Sergio Garcia Murillo  wrote:
>> 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.
> [BA] Is there documentation on the PERC-lite proposal?

The original proposal and slides can be found here:

https://docs.google.com/presentation/d/1cwwg36z8bZlgUaBifiuQU9vWhwx4fbbdIrlvQ77578M

https://www.dropbox.com/s/8qxielk88y1veol/draft-perc-lite.txt.pdf?dl=0

Also:

https://ieeexplore.ieee.org/document/8169749

https://ieeexplore.ieee.org/document/8169752


> Does it avoid the problems with FEC/RTX processing and Triple protection?

The information required to decrypt the outer payload is bundled withing 
the inner encrypted payload, so there is no issue with FEC/RTX, triple 
or ssrc rewriting. Only framemarking support is required.


> Has it been deployed?

As only frame marking is required, it is supported in Jitsi, Janus and 
Medooze SFUs. We have two deployments with PERC-Lite, one with VP8 and 
with Jitsi for Symphony and another one with VP9 SVC and Medooze. We are 
also working alternative per frame encryption methods for lower 
bandwidth overhead.


Best regards

Sergio




From nobody Wed Feb 13 09:27:16 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845D7130E69; Wed, 13 Feb 2019 09:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2ji27U0w5uF; Wed, 13 Feb 2019 09:27:02 -0800 (PST)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FCD131031; Wed, 13 Feb 2019 09:27:01 -0800 (PST)
Received: by mail-vk1-xa2a.google.com with SMTP id j68so715422vke.13; Wed, 13 Feb 2019 09:27:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c7QKiGoJ+ZBPPaJs6IK7hvpk+lULpQIQGXYUopohJP0=; b=oZA1BwDjTJBdHjDcjjk581PK+6pC+l7gu3snp2RYKZyPqqolxCRv7S3ZFUH8wCGT2f 46rcqlbP32LWAxneUxZ6ZIAv+AkVqOZfY8VHgbz6n2ABAXlQhNj/SuB/dvmSJvv/GWNa 7J5JWFP4eojVjTuDXnijO82k0b0MrBDq/avw9LgXzFlIpeI5S76HqYtPY1yh2nUkefj6 ArMgNuBbjpVczDT88d2qQqjBFnSHYwj0QKh+oCJYLf62qH3Gny8teKRivu16J56oBhD9 xbmr8Zq3sC8ZEMJDrr+8dzkfyovJpwlj7k1dAYwuB7JEBUkLa7TMTa/3dGzWGne7/cP8 DK8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c7QKiGoJ+ZBPPaJs6IK7hvpk+lULpQIQGXYUopohJP0=; b=t4dw641O0uEG/yRPvusI97Gd5H/dvP01b+32YEFPKpfrw4rqbQbdiBb1mhow44XwDj CkPoNQL8rFnomBfdHoBOzXe50Hd/lRHj7wzhg8wGAZA8qzMVTAKi0/KR4mVo7APBaQMq ngySe71h2Z6l6Xi8Bgak9ga1CkKqrRev9RnZC7NnPvHkXmfN9FIvEcOKgAFfGMn2lgfn TUJLr+0l9tGuM57aKsps8gp88cZz5r/uZBz2n0dfv+GLVJKLNju7B5JMm4Z9mNI55z/x SvOeH9QYy2AlCwwT65vz3xfVVjDSY35CAx9frw5guaglDylQjOGmBRYVf9lipq5uJuZL rkbg==
X-Gm-Message-State: AHQUAubBAfyORHBY/yD0v1hFzJJ756W3Ag0TPxrMay6UlBEypxyxpU6H vyUer5dYovXhhILjzyX1dq3fvZqGHfEiaBYFUx0=
X-Google-Smtp-Source: AHgI3IYMgGDehT35104FoMDeuMFKBPAfvb2rPdbqdH/bvV+vm8S7HU9GHnX0UdHZpajqbhbThSAarRxPisVzY4bTvyE=
X-Received: by 2002:a1f:250:: with SMTP id 77mr686324vkc.21.1550078820055; Wed, 13 Feb 2019 09:27:00 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <632D3A5E-0F15-40D8-B6F8-1307ECDCDBC9@gmail.com> <96e177cb-a407-bd41-767d-5f0951fb7ee8@gmail.com>
In-Reply-To: <96e177cb-a407-bd41-767d-5f0951fb7ee8@gmail.com>
From: Bernard Aboba 
Date: Wed, 13 Feb 2019 09:26:48 -0800
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Alexandre GOUAILLARD , Emad Omara ,  Emil Ivov , IETF discussion list , Lorenzo Miniero ,  Nils Ohlmeier , "hta@google.com" , perc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007180050581c9d9f0"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 17:27:04 -0000

--0000000000007180050581c9d9f0
Content-Type: text/plain; charset="UTF-8"

On Wed, Feb 13, 2019 at 9:12 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>
> We have two deployments with PERC-Lite, one with VP8 and with Jitsi for
> Symphony and another one with VP9 SVC and Medooze.


[BA] Wow. That makes PERC-lite the defacto standard for Finance. How do you
deal with the SSRC immutability issue?

>
>
>

--0000000000007180050581c9d9f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Wed, Feb 13, 2019 at 9:12 AM Sergio Garcia Murill=
o <sergio.garcia.muri=
llo@gmail.com> wrote:


We have two deployments with PERC-Lite, one with VP8 and with Jitsi for=
 Symphony and another one with VP9 SVC and Medooze.=C2=A0

[BA] Wow. That makes PERC-lite the=
 defacto standard for Finance. How do you deal with the SSRC immutability i=
ssue?=C2=A0


=



--0000000000007180050581c9d9f0--


From nobody Wed Feb 13 09:34:56 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1765F1289FA; Wed, 13 Feb 2019 09:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Via5hqJwhmjO; Wed, 13 Feb 2019 09:34:51 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAE1129532; Wed, 13 Feb 2019 09:34:50 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id q18so3457673wrx.9; Wed, 13 Feb 2019 09:34:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=YRyFsGfji58KKsr85pdsBWkAdTVcI5ACh7faWRvhcMg=; b=cflE7k67CfszM3uVBp3hyAul9AAVdcLnNVbdETtziKxH+wGItoFrPuhw6zmehwIG7z WEZjD+MrCfS59yKMGcGfla6uw2SZwEoy7NCNX+QmI6kIX9tfQ0vnAgBGE2xGZ0pCxGVg bEMaZejK22pyqesUkhuAiYHVdzQw0/UIzYjtcmsuYxY+5BDp1dpMusizgCroCwDzKYFG Ne1qwbkRWC7oy+/7k3kQe+OKa3ndxJTm998p6IGfAVxEtt4Ri2No+srCgT3+cng/Nyhq 97KkIQQeaqOoMv/8usI1ON0b9KW8QqGOTMP9Pk133B5m6QRsjrn7oDNdFhpBLYwNUP3b 3y5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=YRyFsGfji58KKsr85pdsBWkAdTVcI5ACh7faWRvhcMg=; b=d+qy8qaBeaPntczqcDq7tob2dUWq5Sj+CUc2bSCDodmONBRkldEUDXeQnIY4yNIOTq 4T9C/B/6LVGkSlD9AYRMansVWbOfpH0ge/VRrMQtrn70kvqi5PiBu02bK+tU+G81UneE 3VuV+RZCkiOtv0zQ2FqWEv8xCblqHGI57LrGr+boXaMHw8d7sqUkAKKO5dIjBneGPKcO /L1L1ERYnmlBbJQ1/aVX8PNq858VZCgkG0OSydwMMdsIOaw1W18rcZqTD8j8HRQxxg/B Bg1Tkp/e8IY6zbII2STXs6nP1zx1Qwna27uU5pvGtrOrhVqp633krLq8IkeOuMfm+otk LmxA==
X-Gm-Message-State: AHQUAuanpd9WpZhxGx3rCODL5HeJqeP745sH/+Pq0EESdGKTiwTGXypg tbQRvirzgDsoEdlzc+DiZ5ttOpXQ
X-Google-Smtp-Source: AHgI3IZo0IrbWicuePoN63jQt9oZlZWuMc4d9mcSvrMt8WW91a7VRSWRRL0fcNBikUhK2x5GSaNzYA==
X-Received: by 2002:a5d:4804:: with SMTP id l4mr1329691wrq.177.1550079289030;  Wed, 13 Feb 2019 09:34:49 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id h62sm9868828wmf.11.2019.02.13.09.34.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 09:34:48 -0800 (PST)
To: Bernard Aboba 
Cc: Alexandre GOUAILLARD , Emad Omara , Emil Ivov , IETF discussion list , Lorenzo Miniero , Nils Ohlmeier , "hta@google.com" , perc@ietf.org
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <632D3A5E-0F15-40D8-B6F8-1307ECDCDBC9@gmail.com> <96e177cb-a407-bd41-767d-5f0951fb7ee8@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <41224dad-ee0c-a128-850b-c3e0770a74fe@gmail.com>
Date: Wed, 13 Feb 2019 18:39:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D2D57FB9009D5D02B0A5406E"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 17:34:54 -0000

This is a multi-part message in MIME format.
--------------D2D57FB9009D5D02B0A5406E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 13/02/2019 18:26, Bernard Aboba wrote:
> On Wed, Feb 13, 2019 at 9:12 AM Sergio Garcia Murillo 
>  > wrote:
>
>
>     We have two deployments with PERC-Lite, one with VP8 and with
>     Jitsi for Symphony and another one with VP9 SVC and Medooze. 
>
>
> [BA] Wow. That makes PERC-lite the defacto standard for Finance. How 
> do you deal with the SSRC immutability issue?


The original rtp packet payload (without extension headers) is included 
in the outer encrypted payload, so any rtp params may be changed by the 
SFU as it would normally do. We proposed this to be consistent with perc 
double so it was less disruptive, but we have been working on 
alternative encryption algorithms with less overhead including full 
frame encryption ones.

Best regards

Sergio


--------------D2D57FB9009D5D02B0A5406E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 13/02/2019 18:26, Bernard Aboba
      wrote:

    

    

      
      

        
On Wed, Feb 13, 2019 at 9:12 AM Sergio Garcia
          Murillo <sergio.garcia.murillo@gmail.com>
          wrote:

      

      

        

          

            

            We have two deployments with PERC-Lite, one with VP8 and
            with Jitsi for Symphony and another one with VP9 SVC and
            Medooze. 

          


          

          
[BA] Wow. That makes PERC-lite the defacto
            standard for Finance. How do you deal with the SSRC
            immutability issue? 

          

        

      

    

    


    

    
The original rtp packet payload (without extension headers) is
      included in the outer encrypted payload, so any rtp params may be
      changed by the SFU as it would normally do. We proposed this to be
      consistent with perc double so it was less disruptive, but we have
      been working on alternative encryption algorithms with less
      overhead including full frame encryption ones.

    

    
Best regards

    
Sergio

    

  


--------------D2D57FB9009D5D02B0A5406E--


From nobody Wed Feb 13 12:52:35 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C744312E7C1 for ; Wed, 13 Feb 2019 12:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9f68Ja2x0Nd for ; Wed, 13 Feb 2019 12:52:29 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE491200D7 for ; Wed, 13 Feb 2019 12:52:28 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id y185so2761205wmd.1 for ; Wed, 13 Feb 2019 12:52:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=1xCeu+6chdQasJRVqrlePIXj6qOxK2dFV93JIKkEb+o=; b=booUs/AAIZdgnykfE2u97BPC5X4GT0HJFo9O0/fptkPh2ZEU7zgVZSVEJGTyyCCZTz 6vdUXBywe0pohBpO/arh5tTqxiGSS75y7LqLe8jS4Iz7T2rIKSwGYD5Ty3wk42lRmBbb qAPTPXM31ZksPmNo6DUPfCCPhZucwPijWqMjGaHztuoHlUoqP6AUUWjRIv3a986dqTey QPNQVZlewQ3mPhpWw0f3zkrV0nhIlAdAa9y7mz63MU4qLvU0rbVwbtGyYpNTq+wuTmYy gNGhRDS/ZBFhOQl5cg4HS4EBK9q5MfGJwyPh2QyuqeWaxPlS1typdVCz0C1jkXmqf8Zu +GVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=1xCeu+6chdQasJRVqrlePIXj6qOxK2dFV93JIKkEb+o=; b=s1Hfc78f9DmiWlpODkNotzjpU1xAOwozzIJboR4Mxftvyc/lJ6Bq2fSVw7/oL+hnSR mZ0kW3pXCybkxydUHrqWSCf7AI0GPKZjWGa8Kqx9vJ9S9b92Q7jE2odtwctLPRBUk6uO qRwCp9lEMbDvi5yk7TrYaqIRBSGT0zUD78e5Lc1PYo7XDWMBwRUjy8qLJwO/YvgSupkY T755urnbrkLlS4Lj9IupGShuye+5E7BzSUmE70VYqRRoaZFli5DMTfI9gcWbuUmWWx0V IBbuW00D1dvRRtKUYmEbif9B6o0pKY7c04fcIYk1Etar/QYddgYv6uYrwnmHHQqFRFCD OOFA==
X-Gm-Message-State: AHQUAuanyWUrSbeq+Ywr/bOst1WzL7YiTBrXgeBfHJ3CxyL3SysQNb29 tglSm1s2ho4eO+dVonyjmT3zNiQm
X-Google-Smtp-Source: AHgI3IZlrXxw5Q3FWBLBptVpe53cXDwVghcXWZx68XfDIHErHgKq7yKc5UctPh+RcbMTawqGZAc5vQ==
X-Received: by 2002:a1c:4c0e:: with SMTP id z14mr38970wmf.81.1550091146159; Wed, 13 Feb 2019 12:52:26 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id t5sm202502wmg.43.2019.02.13.12.52.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 12:52:25 -0800 (PST)
To: "perc@ietf.org" 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com>
From: Sergio Garcia Murillo 
Message-ID: <376e72e7-e9ff-bcd3-5305-0b241901e7bc@gmail.com>
Date: Wed, 13 Feb 2019 21:57:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com>
Content-Type: multipart/alternative; boundary="------------8CF825DD59E13BA05127F96A"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 20:52:34 -0000

This is a multi-part message in MIME format.
--------------8CF825DD59E13BA05127F96A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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.
>
>> On Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo 
>> > > wrote:
>>
>> 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
>> https://datatracker.ietf.org/liaison/1614/
>>
>> 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).
>>> https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
>>>
>>> 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
>>> https://www.ietf.org/proceedings/96/minutes/minutes-96-perc
>>>
>>> At IETF 98 SSRC immutability and RTX considerations were discussed 
>>> but no proposal made on security implications
>>> https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00
>>>
>>> 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.
>>> https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01
>>> https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc
>>>
>>> Best regards
>>>  Nils & Suhas
>>>  PERC WG chairs
>>>
>>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo 
>>>> >>> > wrote:
>>>>
>>>> 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?
>>>>>>
>>>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo 
>>>>>> >>>>> > wrote:
>>>>>>
>>>>>>> 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:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba 
>>>>>>>> > 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov >>>>>>>     > wrote:
>>>>>>>>
>>>>>>>>         Yes pretty much those.
>>>>>>>>
>>>>>>>>         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 Sat 2 Feb 2019 at 12:23, Bernard Aboba
>>>>>>>>         >>>>>>>         > wrote:
>>>>>>>>
>>>>>>>>             "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?
>>>>>>>>
>>>>>>>>             On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD
>>>>>>>>             >>>>>>>             > wrote:
>>>>>>>>
>>>>>>>>                 +1 on ssrc rewriting, and on the consensus not
>>>>>>>>                 reached on this and other topics.
>>>>>>>>
>>>>>>>>                 Sent from my iPhone
>>>>>>>>
>>>>>>>>                 On 2 Feb 2019, at 17:18, Lorenzo Miniero
>>>>>>>>                 >>>>>>>                 > wrote:
>>>>>>>>
>>>>>>>>>                 +1, SSRC rewriting is pretty much fundamental
>>>>>>>>>                 to all SFUs out there.
>>>>>>>>>
>>>>>>>>>                 Lorenzo
>>>>>>>>>
>>>>>>>>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>>>>>>>>                 > 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.
>>>>>>>>>
>>>>>>>>>                     On Sat 2 Feb 2019 at 06:21, Bernard Aboba
>>>>>>>>>                     >>>>>>>>                     > wrote:
>>>>>>>>>
>>>>>>>>>                         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 Fri, Feb 1, 2019 at 12:23 PM Sergio
>>>>>>>>>                         Garcia Murillo
>>>>>>>>>                         >>>>>>>>                         >
>>>>>>>>>                         wrote:
>>>>>>>>>
>>>>>>>>>                             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@ietf.org 
>>>>>>>>>                             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@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>
>>>>>>>
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/perc
>


--------------8CF825DD59E13BA05127F96A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
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.

        


          

            
On Feb 13, 2019, at 4:53 AM, Sergio Garcia
              Murillo <sergio.garcia.murillo@gmail.com>
              wrote:

            

            

              
              

                
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

                

                
https://datatracker.ietf.org/liaison/1614/

                

                


                

                
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

                  


                    

                      
On 2Feb, 2019, at 13:37, Sergio
                        Garcia Murillo <sergio.garcia.murillo@gmail.com>
                        wrote:

                      

                      

                        
                        

                          
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?

                              


                                On Feb 2, 2019, at 3:31 PM, Sergio
                                Garcia Murillo <sergio.garcia.murillo@gmail.com>
                                wrote:

                                

                              

                              

                                

                                  
                                  
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:

                                  

                                  

                                    
                                    

                                      


                                      

                                      


                                      

                                    

                                    

                                      
On Sat 2
                                        Feb 2019 at 16:50, Bernard Aboba
                                        <bernard.aboba@gmail.com>
                                        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

                                        


                                        

                                        


                                        

                                      

                                    

                                    

                                      

                                        

                                          


                                            

                                              
On
                                                Sat, Feb 2, 2019 at
                                                11:46 AM Emil Ivov <emcho@jitsi.org>
                                                wrote:

                                              

                                              

                                                

                                                  
Yes pretty
                                                    much those.

                                                

                                                


                                                

                                                
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 Sat 2
                                                      Feb 2019 at 12:23,
                                                      Bernard Aboba <bernard.aboba@gmail.com>
                                                      wrote:

                                                    

                                                    

                                                      
"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? 

                                                      

                                                      

                                                      

                                                        
On
                                                          Sat, Feb 2,
                                                          2019 at 5:40
                                                          AM Alexandre
                                                          GOUAILLARD
                                                          <alex.gouaillard@cosmosoftware.io>
                                                          wrote:

                                                        

                                                        

                                                          
+1 on
                                                          ssrc
                                                          rewriting, and
                                                          on the
                                                          consensus not
                                                          reached on
                                                          this and other
                                                          topics.

                                                          

                                                          
Sent
                                                          from my iPhone

                                                          


                                                          On 2 Feb 2019,
                                                          at 17:18,
                                                          Lorenzo
                                                          Miniero <lorenzo@meetecho.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
+1,
                                                          SSRC rewriting
                                                          is pretty much
                                                          fundamental to
                                                          all SFUs out
                                                          there.

                                                          

                                                          Lorenzo

                                                          

                                                          
Il
                                                          2 febbraio
                                                          2019 10:19:06
                                                          CET, Emil Ivov
                                                          <emcho@jitsi.org>
                                                          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.

                                                          


                                                          

                                                          
On
                                                          Sat 2 Feb 2019
                                                          at 06:21,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo
                                                          <sergio.garcia.murillo@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
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@ietf.org

                                                          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@ietf.org
https://www.ietf.org/mailman/listinfo/perc


                                  

                                  


                                  

                                

                              

                            

                          

                        

                        _______________________________________________

                        Perc mailing list

                        Perc@ietf.org

                        https://www.ietf.org/mailman/listinfo/perc

                      

                    

                  

                  

                

                


                

              

              _______________________________________________

              Perc mailing list

              Perc@ietf.org

              https://www.ietf.org/mailman/listinfo/perc

            

          

        

        

      

    

    


    

  


--------------8CF825DD59E13BA05127F96A--


From nobody Wed Feb 13 13:41:18 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C931128766; Wed, 13 Feb 2019 11:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf-V_u9btHrZ; Wed, 13 Feb 2019 11:57:10 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F142B1200B3; Wed, 13 Feb 2019 11:57:09 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1DJuuJG013744 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Feb 2019 13:56:58 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550087822; bh=w7sVhmLWARcNbvpBuTw1RVWJTK6ycFUKI8aBbtWJPJk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=RS91qnwqJKHtc3SNqcfo63GOTJzmGGeA3xZ4mbg56AVq+lZ3Pc4YUS1IlLNLPJOf7 Dk8emfSwH7zb07+Paw+dZnN6wgm1BQISj9NPzG/rhOGbOWw1NxgtLj6Ll3a9P8qUrC 32MUN9pQxIlHsjdvpy9Ib3XZJ0GoaPRrmA5BqeeY=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell 
Message-Id: <7098107A-1CFC-4074-9B45-DB09CCD2E9F1@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A9D41907-527F-4B0C-A4BF-9DF2F4A8E35B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 13 Feb 2019 13:56:54 -0600
In-Reply-To: 
Cc: Nils Ohlmeier , IETF discussion list , Justin Uberti , Sergio Garcia Murillo , Emad Omara , Emil Ivov , perc@ietf.org, Harald Tveit Alvestrand , "pthatcher@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero , The IESG 
To: Bernard Aboba 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
X-Mailman-Approved-At: Wed, 13 Feb 2019 13:41:15 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 19:57:16 -0000

--Apple-Mail=_A9D41907-527F-4B0C-A4BF-9DF2F4A8E35B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_85D56B92-C7EE-48F7-872A-CC9E957793DD"


--Apple-Mail=_85D56B92-C7EE-48F7-872A-CC9E957793DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Bernard,

Full disclosure: I asked the chairs to send that email. I gather from =
your response that you saw it as an attempt to shut down discussion. I =
don=E2=80=99t think that is the case at all.

I interpreted Nils=E2=80=99s email to be providing useful context about =
the discussions that occurred in the working group. I hope that context =
will be useful to people evaluating the current discussion. Several of =
the points currently under discussion were discussed in the WG, and they =
made tradeoffs. Not everyone was happy about each tradeoffs; that=E2=80=99=
s the =E2=80=9Crough=E2=80=9D in rough consensus.

It=E2=80=99s perfectly reasonable to open those issues again if new =
information has come up since then, or if people who were not =
participants in the WG have opinions to offer.  But we should also be =
careful about simply replaying the same discussions over again. I =
don=E2=80=99t mean to say that the entire discussion falls into the =
second category; I think we have some of both.

I would encourage participants in this discussion to focus on what we =
might have learned since the WG discussions, whether that means new =
implementation experience, new voices, new analyses, etc.

Thanks!

Ben.



> On Feb 12, 2019, at 9:10 PM, Bernard Aboba  =
wrote:
>=20
> Nils --
>=20
> This is IETF Last Call.  Its purpose is to determine if there is IETF =
consensus to publish the PERC documents (and the framework, in =
particular) as proposed standards.
>=20
> As described on this list, a number of potential implementers have =
seriously considered the PERC framework, but for reasons described in =
the IETF last call comments, they have encountered problems that have =
either prevented them from implementing the framework at all, or have =
caused them to choose a modified approach to one or more parts of it.
>=20
> The overall picture is therefore not one of "rough consensus" in the =
IETF community - but rather of problems with the work that have caused =
implementers to seek alternatives either within the IETF or outside of =
it. In at least one case, such an implementation has achieved =
considerable usage, and other alternative implementations appear =
inevitable. Overall, this level of dissent is relatively rare within an =
IETF last call - and so is something for the IESG to take note of.
>=20
> I will let the disputants speak for themselves, but the statements =
made in this IETF last call appear to indicate at least the following =
points of contention:
>=20
> 1.  Problems with implementation of "Double" to the issues encountered =
with attempted support for FEC/RTX/RED, and the potential need for =
"triple protection".  These problems appear to have been fixed by =
implementers who have taken an alternative approach (e.g. "PERC-LITE").  =
The perceived excessive overhead of "Triple" has also lead to =
consideration of alternatives with respect to the scope of encryption =
(e.g. frame encryption versus payload encryption).
>=20
> 2. Problems with SSRC-based key identification (leading to the =
requirement for immutability).  The effects of SSRC immutability have =
been pointed out, namely the inability to  support some scenarios (such =
as MOOCs) and also a requirement for support of simulcast reception that =
is perceived of as difficult to meet (e.g. multiple implementations that =
are less than robust). I'll let the implementers describe how their =
alternatives to dealing with this problem, but some of these have been =
transport independent so as to not allow for dependencies on =
RTP-specific constructs such as the SSRC.
>=20
> 3. Problems with the DTLS-EKT Diet key management scheme.  I believe =
that this issue may be the impetus for the use of alternative approaches =
taken with respect to key management (e.g. consideration of EME).
>=20
> Given this level of dissent, there would seem to be little chance that =
the PERC framework as currently described in the WG documents will ever =
be widely implemented. But despite that, it does seem possible for the =
WG to make a meaningful contribution - by laying out the problem and =
solution requirements well enough to guide future discussions.  The =
current PERC Framework document does not accomplish this goal.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> In trying to understand the issues, it is
>=20
>=20
>  PERC framework document were to at least layout the basic principles =
that such experiments need to follow.
>=20
> As an example, it would be helpful to understand the implications of =
utilizing alternative key management schemes.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Tue, Feb 12, 2019 at 5:34 PM Nils Ohlmeier > wrote:
> Thank you for the input on the framework and the double documents from =
everyone.
>=20
> 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.
>=20
>=20
> 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).
>   https://www.ietf.org/proceedings/95/minutes/minutes-95-perc =

>=20
> 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
>   https://www.ietf.org/proceedings/96/minutes/minutes-96-perc =

> At IETF 98 SSRC immutability and RTX considerations were discussed but =
no proposal made on security implications
>   https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 =

> 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.
>   https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01 =

>   =
https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc =

> Best regards
>   Nils & Suhas
>   PERC WG chairs
>=20
>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo =
> wrote:
>>=20
>> PERC may be a valid solution for some scenarios, maybe SIP.
>>=20
>> 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.
>>=20
>> Best regards
>>=20
>> Sergio
>>=20
>>>=20
>>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>>> Sergio -
>>>>=20
>>>> 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?
>>>>=20
>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo =
> wrote:
>>>>=20
>>>>> I think Emil and Bernard have described quite precisely where we =
are and how we managed to get here.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Best regards
>>>>> Sergio
>>>>>=20
>>>>>=20
>>>>> On 02/02/2019 18:42, Emil Ivov wrote:
>>>>>>=20
>>>>>>=20
>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba =
> wrote:
>>>>>> Emil said:
>>>>>>=20
>>>>>> "The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents."
>>>>>>=20
>>>>>> [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".
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> I don=E2=80=99t know that this goal is a direct consequence of =
the framework=E2=80=99s 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> This approach was referred to as =E2=80=9Cwedging RTX and FEC=E2=80=
=9D as it places them in between the two encryption operations.
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> Applications will apply SRTP-double first and, those that need to =
use FEC and RTX would have to apply them only after.
>>>>>>=20
>>>>>> It was quickly pointed out that this not only destroys the stated =
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, =
those of you who use FEC/RTX will simply do a third round of SRTP=E2=80=9D=
, thus arriving at a total of three encryptions for every packet..
>>>>>>=20
>>>>>> The discussions around this topic were highly contentious.
>>>>>>=20
>>>>>> Hope this makes things clear,
>>>>>> Emil
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov > wrote:
>>>>>> Yes pretty much those.
>>>>>>=20
>>>>>> The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Emil
>>>>>>=20
>>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba =
> wrote:
>>>>>> "on the consensus not reached on this and other topics."
>>>>>>=20
>>>>>> [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:
>>>>>>=20
>>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>>> * Whole frame encryption versus payload encryption
>>>>>>=20
>>>>>> 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?
>>>>>>=20
>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD =
> wrote:
>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this =
and other topics.
>>>>>>=20
>>>>>> Sent from my iPhone
>>>>>>=20
>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero > wrote:
>>>>>>=20
>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out =
there.
>>>>>>>=20
>>>>>>> Lorenzo
>>>>>>>=20
>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov > 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.
>>>>>>>=20
>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting =
could not be allowed=E2=80=9D is a conclusion that ever had any =
consensus in PERC, regardless of what WG leadership is trying to make =
everyone believe.
>>>>>>>=20
>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba =
> wrote:
>>>>>>> Richard said:
>>>>>>>=20
>>>>>>> "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."
>>>>>>>=20
>>>>>>> [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?
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo =
> wrote:
>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>> So I would propose we add something like the following to this =
definition:
>>>>>>>>=20
>>>>>>>> "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).
>>>>>>>=20
>>>>>>> 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 ?
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>    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.
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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:
>>>>>>>=20
>>>>>>> =
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryp=
tion =

>>>>>>> Best regards
>>>>>>>=20
>>>>>>> Sergio
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Perc mailing list
>>>>>>> Perc@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>> --
>>>>>>> sent from my mobile
>>>>>>>=20
>>>>>>> --
>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la =
brevit=C3=A0.
>>>>>> --
>>>>>> sent from my mobile
>>>>>> --
>>>>>> sent from my mobile
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> Perc@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>=20
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/perc =

>=20


--Apple-Mail=_85D56B92-C7EE-48F7-872A-CC9E957793DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Bernard,

Full =
disclosure: I asked the chairs to send that email. I gather from your =
response that you saw it as an attempt to shut down discussion. I =
don=E2=80=99t think that is the case at all.

I interpreted Nils=E2=80=99=
s email to be providing useful context about the discussions that =
occurred in the working group. I hope that context will be useful to =
people evaluating the current discussion. Several of the points =
currently under discussion were discussed in the WG, and they made =
tradeoffs. Not everyone was happy about each tradeoffs; that=E2=80=99s =
the =E2=80=9Crough=E2=80=9D in rough consensus.

It=E2=80=99s perfectly reasonable to =
open those issues again if new information has come up since then, or if =
people who were not participants in the WG have opinions to offer. =
 But we should also be careful about simply replaying the same =
discussions over again. I don=E2=80=99t mean to say that the entire =
discussion falls into the second category; I think we have some of =
both.

I would =
encourage participants in this discussion to focus on what we might have =
learned since the WG discussions, whether that means new implementation =
experience, new voices, new analyses, etc.

Thanks!

Ben.



On Feb =
12, 2019, at 9:10 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Nils --

This is IETF Last Call.  Its purpose is to determine if =
there is IETF consensus to publish the PERC documents (and the =
framework, in particular) as proposed standards. 

As described on this =
list, a number of potential implementers have seriously considered the =
PERC framework, but for reasons described in the IETF last call =
comments, they have encountered problems that have either prevented them =
from implementing the framework at all, or have caused them to choose a =
modified approach to one or more parts of it. 

The overall picture is =
therefore not one of "rough consensus" in the IETF community - but =
rather of problems with the work that have caused implementers to seek =
alternatives either within the IETF or outside of it. In at least one =
case, such an implementation has achieved considerable usage, and other =
alternative implementations appear inevitable. Overall, this level of =
dissent is relatively rare within an IETF last call - and so is =
something for the IESG to take note of. 

I will let the =
disputants speak for themselves, but the statements made in this IETF =
last call appear to indicate at least the following points of =
contention: 

1.  Problems with implementation of "Double" to the =
issues encountered with attempted support for FEC/RTX/RED, and the =
potential need for "triple protection".  These problems appear to =
have been fixed by implementers who have taken an alternative approach =
(e.g. "PERC-LITE").  The perceived excessive overhead of "Triple" =
has also lead to consideration of alternatives with respect to the scope =
of encryption (e.g. frame encryption versus payload =
encryption). 

2. Problems with SSRC-based key identification (leading to =
the requirement for immutability).  The effects of SSRC =
immutability have been pointed out, namely the inability to  =
support some scenarios (such as MOOCs) and also a requirement for =
support of simulcast reception that is perceived of as difficult to meet =
(e.g. multiple implementations that are less than robust). I'll let the =
implementers describe how their alternatives to dealing with this =
problem, but some of these have been transport independent so as to not =
allow for dependencies on RTP-specific constructs such as the =
SSRC.  

3. Problems with the DTLS-EKT Diet key management =
scheme.  I believe that this issue may be the impetus for the use =
of alternative approaches taken with respect to key management (e.g. =
consideration of EME). 

Given this level of dissent, there =
would seem to be little chance that the PERC framework as currently =
described in the WG documents will ever be widely implemented. But =
despite that, it does seem possible for the WG to make a meaningful =
contribution - by laying out the problem and solution requirements =
well enough to guide future discussions.  The current PERC =
Framework document does not accomplish this goal. 








 



In trying to understand the issues, it =
is 


 PERC framework document were to =
at least layout the basic principles that such experiments need to =
follow. 

As=
 an example, it would be helpful to understand the implications of =
utilizing alternative key management schemes. 










On Tue, Feb =
12, 2019 at 5:34 PM Nils Ohlmeier <nohlmeier@mozilla.com> 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).
  https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
 
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
  https://www.ietf.org/proceedings/96/minutes/minutes-96-perc

At IETF 98 SSRC immutability and RTX considerations were =
discussed but no proposal made on security implications
  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00<=
/span>

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.
  https://datatracker.ietf.org/meeting/99/materials/minutes-99-pe=
rc-01
  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7=
wkf4-bc

Best regards
  Nils & Suhas
  PERC WG chairs

On 2Feb, =
2019, at 13:37, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:


 =20
   =20
 =20
  
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:

      

      

       =20
        
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?

        


          On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
          wrote:

          

        

        

          

           =20
            
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:

            

            

             =20
              

                


                

                


                

              

              

                
On Sat 2 Feb 2019 at 16:50, =
Bernard Aboba
                  <bernard.aboba@gmail.com>
                  wrote:

                

                

                  
Emil said:
                    


                    

                    
"The need to do a triple encryption =
for example
                      is a particularly egregious consequence of the
                      order problem. That=E2=80=99s a problem specific =
to the
                      =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that =
this goal is a
                    direct consequence of the framework=E2=80=99s =
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
                    =E2=80=9Cwedging RTX and FEC=E2=80=9D 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 =
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D
                    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:
                    =E2=80=9Cwell, those of you who use FEC/RTX will =
simply do a
                    third round of SRTP=E2=80=9D, 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

                  


                  

                  


                  

                

              

              

                

                  

                    


                      

                        
On Sat, =
Feb 2,
                          2019 at 11:46 AM Emil Ivov <emcho@jitsi.org>
                          wrote:

                        

                        

                          

                            
Yes pretty much =
those.

                          

                          


                          

                          
The need to do a =
triple
                            encryption for example is a particularly
                            egregious consequence of the order problem.
                            That=E2=80=99s a problem specific to the =
=E2=80=9Cdouble=E2=80=9D
                            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 Sat 2 Feb =
2019 at 12:23,
                                Bernard Aboba <bernard.aboba@gmail.com>
                                wrote:

                              

                              

                                
"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? 

                                

                                

                                

                                  
On=

                                    Sat, Feb 2, 2019 at 5:40 AM
                                    Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io>
                                    wrote:

                                  

                                  

                                    
+1 on =
ssrc
                                      rewriting, and on the consensus
                                      not reached on this and other
                                      topics.

                                      

                                      
Sent from my =
iPhone

                                      


                                        On 2 Feb 2019, at 17:18, Lorenzo
                                        Miniero <lorenzo@meetecho.com>
                                        wrote:

                                        

                                      

                                      

                                        
+1, =
SSRC
                                          rewriting is pretty much
                                          fundamental to all SFUs out
                                          there.

                                          

                                          Lorenzo

                                          

                                          
Il =
2
                                            febbraio 2019 10:19:06 CET,
                                            Emil Ivov <emcho@jitsi.org>
                                            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 =E2=80=9CSSRC =
rewriting
                                                could not be allowed=E2=80=
=9D is
                                                a conclusion that ever
                                                had any consensus in
                                                PERC, regardless of what
                                                WG leadership is trying
                                                to make everyone
                                                believe.

                                              


                                                

                                                  
On Sat
                                                    2 Feb 2019 at 06:21,
                                                    Bernard Aboba <bernard.aboba@gmail..com>
                                                    wrote:

                                                  

                                                  

                                                    
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
                                                        Fri, Feb 1, 2019
                                                        at 12:23 PM
                                                        Sergio Garcia
                                                        Murillo <sergio.garcia..murillo@gmail.com>
                                                        wrote:

                                                      

                                                      

                                                        

                                                          
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-a=
rch-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/e=
xplainer.md#encryption

                                                          
Best
                                                          regards
Sergio

                                                          

                                                        

_______________________________________________

                                                        Perc mailing
                                                        list

                                                        Perc@ietf.org

                                                        https://www.ietf.org/mailman/listinfo/perc

                                                      

                                                    

                                                  

                                                

                                              

                                              -- 

                                              
sent
                                                from my mobile

                                            

                                          

                                          

                                          -- 

                                          Inviato dal mio dispositivo
                                          Android con K-9 Mail.
                                          Perdonate la brevit=C3=A0.
=

                                      

                                    

                                  

                                

                              

                            

                          

                          -- 

                          
sent
                            from my mobile

                        

                      

                    

                  

                

              

              -- 

              
sent from my =
mobile

              

              

              
______________________=
_________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


            


            

          

        

      

    

  


_______________________________________________
Perc =
mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc




=

--Apple-Mail=_85D56B92-C7EE-48F7-872A-CC9E957793DD--

--Apple-Mail=_A9D41907-527F-4B0C-A4BF-9DF2F4A8E35B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxkdoYACgkQgFZKbJXz
1A1RHA//cSGUn/NwJ8uyEHnscmEwB5dslrMn2c5FVzlhByW42L04YgWrFJ/MvMDC
19947LJCN7piEfKv5V42s8JqohlbQi2O9PFHAwnmiFcV8+u5HttCpW8uYofwJlww
SCA+uszJkU4GuUyPh9rMZJe+/63oS+uYekY61owAYrVeilWmWH2sOvDBjMXOOv4g
KxeW5mgiatbZjIT4eqNGywQ2Moeb2QUC/yT4HR5uf6lWycEf8jEVmYYmf0CL1k2M
tNFVsDallc59Ou6JfU6oOBQhnsimBxybO/bzg0hY63J9A5XVqqzRn2i77loNE3BL
RS5CQukWTEMDo5PRlb/+lmurobV53cI88wiTgJcyQ/W2LU6APUixYsOY0NtC7kAJ
3tjc7nRO4wHUjPZ60j5ZrdKgFjSiGglrQ/qbFe4cKjx9wNSulmeJY2A7LqBp0vOf
YbQq6QNHZAJBNxSN5MDryLhyY8gLgiQ6OFRpEz36/EWvKQNxFif24bZrvnA1jume
R+HL8VE8s0KIKnsUBRXxc4t9Jp0YDFKhEGomw5RbAR/HaAQNFEu0PYXHtnGxBi9e
xBzbdbkp60/OXxl/UBVrspIPJ55sFFicts09KlvEKQZq2YEzeDhMA0ppeQPW/pXY
VBHY3pvOKlcR2kJHJUvP1SSFxn6nNcCmdY1IQo/s4hx6OkRKQp4=
=PlTJ
-----END PGP SIGNATURE-----

--Apple-Mail=_A9D41907-527F-4B0C-A4BF-9DF2F4A8E35B--


From nobody Wed Feb 13 13:41:25 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CAE12DF71; Wed, 13 Feb 2019 12:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd9D3m7gadW9; Wed, 13 Feb 2019 12:22:00 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D82128766; Wed, 13 Feb 2019 12:21:59 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1DKLl6k017967 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Feb 2019 14:21:50 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550089313; bh=XD560baG3KCer97YBe7cKrsNuvCWJ8KwYvYkiQ4dZTU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=m9h6GC4xxhZm+MFt72PAjEd6XniOGIdd9Faw5wssc4Z/AS6adOyen0GfWXEje9cHK 8+0kS2c9umVhsMFjG4m9jiRqeAXdpxFGTBurRUmzeNLOHGzA9ChRAHMfmldErBT0dN W4fz2i+kKoTrM17br8GprDaubx8HzSjui49DMS3k=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell 
Message-Id: <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4F3AE084-960A-496C-926B-4049A8A45332"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 13 Feb 2019 14:21:46 -0600
In-Reply-To: <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com>
Cc: Nils Ohlmeier , IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, Harald Tveit Alvestrand , Alexandre GOUAILLARD , Lorenzo Miniero , Bernard Aboba 
To: Sergio Garcia Murillo 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>  <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
X-Mailman-Approved-At: Wed, 13 Feb 2019 13:41:15 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 20:22:05 -0000

--Apple-Mail=_4F3AE084-960A-496C-926B-4049A8A45332
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_411A4D87-E3EC-4C08-9286-2D12C28187C4"


--Apple-Mail=_411A4D87-E3EC-4C08-9286-2D12C28187C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

(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.

> On Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo =
 wrote:
>=20
> You are missing an important piece on the timeline:
>=20
> Statement from the IETF ART and SEC Area Directors regarding the =
"Trusted application, untrusted intermediary" use case
> https://datatracker.ietf.org/liaison/1614/ =

>=20
> 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.
>=20
> Best regards
> Sergio
>=20
> On 13/02/2019 2:34, Nils Ohlmeier wrote:
>> Thank you for the input on the framework and the double documents =
from everyone.
>>=20
>> 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.
>>=20
>>=20
>> 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).
>>   https://www.ietf.org/proceedings/95/minutes/minutes-95-perc =

>>=20
>> 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
>>   https://www.ietf.org/proceedings/96/minutes/minutes-96-perc =

>> At IETF 98 SSRC immutability and RTX considerations were discussed =
but no proposal made on security implications
>>   https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 =

>> 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.
>>   =
https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01 =

>>   =
https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc =

>> Best regards
>>   Nils & Suhas
>>   PERC WG chairs
>>=20
>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo =
> wrote:
>>>=20
>>> PERC may be a valid solution for some scenarios, maybe SIP.
>>>=20
>>> 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.
>>>=20
>>> Best regards
>>>=20
>>> Sergio
>>>=20
>>>>=20
>>>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>>>> Sergio -
>>>>>=20
>>>>> 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?
>>>>>=20
>>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo =
> wrote:
>>>>>=20
>>>>>> I think Emil and Bernard have described quite precisely where we =
are and how we managed to get here.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Best regards
>>>>>> Sergio
>>>>>>=20
>>>>>>=20
>>>>>> On 02/02/2019 18:42, Emil Ivov wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba =
> wrote:
>>>>>>> Emil said:
>>>>>>>=20
>>>>>>> "The need to do a triple encryption for example is a =
particularly egregious consequence of the order problem. That=E2=80=99s =
a problem specific to the =E2=80=9Cdouble=E2=80=9D documents."
>>>>>>>=20
>>>>>>> [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".
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> I don=E2=80=99t know that this goal is a direct consequence of =
the framework=E2=80=99s 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> This approach was referred to as =E2=80=9Cwedging RTX and FEC=E2=80=
=9D as it places them in between the two encryption operations.
>>>>>>>=20
>>>>>>> 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:
>>>>>>>=20
>>>>>>> Applications will apply SRTP-double first and, those that need =
to use FEC and RTX would have to apply them only after.
>>>>>>>=20
>>>>>>> It was quickly pointed out that this not only destroys the =
stated =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =
=E2=80=9Cwell, those of you who use FEC/RTX will simply do a third round =
of SRTP=E2=80=9D, thus arriving at a total of three encryptions for =
every packet..
>>>>>>>=20
>>>>>>> The discussions around this topic were highly contentious.
>>>>>>>=20
>>>>>>> Hope this makes things clear,
>>>>>>> Emil
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov > wrote:
>>>>>>> Yes pretty much those.
>>>>>>>=20
>>>>>>> The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> Emil
>>>>>>>=20
>>>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba =
> wrote:
>>>>>>> "on the consensus not reached on this and other topics."
>>>>>>>=20
>>>>>>> [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:
>>>>>>>=20
>>>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>>>> * Whole frame encryption versus payload encryption
>>>>>>>=20
>>>>>>> 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?
>>>>>>>=20
>>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD =
> wrote:
>>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this =
and other topics.
>>>>>>>=20
>>>>>>> Sent from my iPhone
>>>>>>>=20
>>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero > wrote:
>>>>>>>=20
>>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out =
there.
>>>>>>>>=20
>>>>>>>> Lorenzo
>>>>>>>>=20
>>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov > 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.
>>>>>>>>=20
>>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting =
could not be allowed=E2=80=9D is a conclusion that ever had any =
consensus in PERC, regardless of what WG leadership is trying to make =
everyone believe.
>>>>>>>>=20
>>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba =
> wrote:
>>>>>>>> Richard said:
>>>>>>>>=20
>>>>>>>> "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."
>>>>>>>>=20
>>>>>>>> [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?
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo =
> wrote:
>>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>>> So I would propose we add something like the following to this =
definition:
>>>>>>>>>=20
>>>>>>>>> "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).
>>>>>>>>=20
>>>>>>>> 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 ?
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>    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.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> 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:
>>>>>>>>=20
>>>>>>>> =
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryp=
tion =

>>>>>>>> Best regards
>>>>>>>>=20
>>>>>>>> Sergio
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> Perc mailing list
>>>>>>>> Perc@ietf.org 
>>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>>> --
>>>>>>>> sent from my mobile
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la =
brevit=C3=A0.
>>>>>>> --
>>>>>>> sent from my mobile
>>>>>>> --
>>>>>>> sent from my mobile
>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Perc mailing list
>>>>>>> Perc@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>=20
>>> _______________________________________________
>>> Perc mailing list
>>> Perc@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/perc =

>>=20
>=20
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc


--Apple-Mail=_411A4D87-E3EC-4C08-9286-2D12C28187C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

(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.

On Feb 13, 2019, at 4:53 AM, =
Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:


 =20
    
 =20
  

    
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

    

    
https://datatracker.ie=
tf.org/liaison/1614/

    

    


    

    
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).

      
  https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
 

      
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

      
  https://www.ietf.org/proceedings/96/minutes/minutes-96-perc

      

      
At IETF 98 SSRC immutability and RTX =
considerations were discussed but no proposal made on security =
implications

      
  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00<=
/span>

      

      
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.

      
  https://datatracker.ietf.org/meeting/99/materials/minutes-99-pe=
rc-01

      
  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7=
wkf4-bc

      

      
Best regards

      
  Nils & Suhas

      
  PERC WG chairs

      


        

          
On 2Feb, 2019, at 13:37, Sergio Garcia Murillo
            <sergio.garcia.murillo@gmail.com>
            wrote:

          

          

            
            
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?

                  


                    On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo
                    <sergio.garcia.murillo@gmail.com>
                    wrote:

                    

                  

                  

                    

                      
                      
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:

                      

                      

                        
                        

                          


                          

                          


                          

                        

                        

                          
On Sat 2 Feb 2019 =
at
                            16:50, Bernard Aboba <bernard.aboba@gmail.com>
                            wrote:

                          

                          

                            
Emil said:
                              


                              

                              
"The need to do a triple
                                encryption for example is a particularly
                                egregious consequence of the order
                                problem. That=E2=80=99s a problem =
specific to
                                the =E2=80=9Cdouble=E2=80=9D =
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=E2=80=99t =
know that
                              this goal is a direct consequence of the
                              framework=E2=80=99s 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 =E2=80=9Cwedging RTX and =
FEC=E2=80=9D 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 =E2=80=9Cdon=E2=80=99t-change-the=
-app=E2=80=9D 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: =E2=80=9Cwell,=
 those
                              of you who use FEC/RTX will simply do a
                              third round of SRTP=E2=80=9D, 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

                            


                            

                            


                            

                          

                        

                        

                          

                            

                              


                                

                                  
On=

                                    Sat, Feb 2, 2019 at 11:46 AM Emil
                                    Ivov <emcho@jitsi.org>
                                    wrote:

                                  

                                  

                                    

                                      
Yes
                                        pretty much those.

                                    

                                    


                                    

                                    
The =
need to
                                      do a triple encryption for example
                                      is a particularly egregious
                                      consequence of the order problem.
                                      That=E2=80=99s a problem specific =
to the
                                      =E2=80=9Cdouble=E2=80=9D =
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 =
Sat 2
                                          Feb 2019 at 12:23, Bernard
                                          Aboba <bernard.aboba@gmail.com>
                                          wrote:

                                        

                                        

                                          
"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? 

                                          

                                          

                                          

                                            
On Sat,
                                              Feb 2, 2019 at 5:40 AM
                                              Alexandre GOUAILLARD =
<alex.gouaillard@cosmosoftware.io>
                                              wrote:

                                            

                                            

                                              
+1
                                                on ssrc rewriting, and
                                                on the consensus not
                                                reached on this and
                                                other topics.

                                                

                                                
Sent
                                                  from my iPhone

                                                


                                                  On 2 Feb 2019, at
                                                  17:18, Lorenzo Miniero
                                                  <lorenzo@meetecho.com>
                                                  wrote:

                                                  

                                                

                                                

                                                  
+1, SSRC
                                                    rewriting is pretty
                                                    much fundamental to
                                                    all SFUs out =
there.

                                                    

                                                    Lorenzo
=

                                                    

                                                    
Il
                                                      2 febbraio 2019
                                                      10:19:06 CET, Emil
                                                      Ivov <emcho@jitsi.org> 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 =E2=80=9CSS=
RC
                                                          rewriting
                                                          could not be
                                                          allowed=E2=80=9D=
 is a
                                                          conclusion
                                                          that ever had
                                                          any consensus
                                                          in PERC,
                                                          regardless of
                                                          what WG
                                                          leadership is
                                                          trying to make
                                                          everyone
                                                          believe.

                                                        


                                                          

                                                          
On
                                                          Sat 2 Feb 2019
                                                          at 06:21,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia =
Murillo
                                                          <sergio.garcia.murillo@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
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-sec=
urity-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/m=
aster/explainer.md#encryption

                                                          
Best
                                                          regards
Sergio

                                                          

                                                          

_______________________________________________

                                                          Perc mailing
                                                          list

                                                          Perc@ietf.org

                                                          https://www.ietf.org/mailman/listinfo/perc

                                                          

                                                          

                                                          

                                                          

                                                        

                                                        -- 
=

                                                        
s=
ent
                                                          from my =
mobile

                                                      

                                                    

                                                    

                                                    -- 

                                                    Inviato dal mio
                                                    dispositivo Android
                                                    con K-9 Mail.
                                                    Perdonate la
                                                    brevit=C3=A0.

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                    -- 

                                    
sent
                                      from my mobile

                                  

                                

                              

                            

                          

                        

                        -- 

                        
sent from my
                          mobile

                        

                        

                        
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


                      


                      

                    

                  

                

              

            

            _______________________________________________
=

            Perc mailing list

            Perc@ietf.org

            https://www.ietf.org/m=
ailman/listinfo/perc

          

        

      

      

    


    

  


_______________________________________________
Perc =
mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

=

--Apple-Mail=_411A4D87-E3EC-4C08-9286-2D12C28187C4--

--Apple-Mail=_4F3AE084-960A-496C-926B-4049A8A45332
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxkfFoACgkQgFZKbJXz
1A2JXA/+PwpBJRAzPF5HhdNwGRsHbXjF4mLkUdbINJ93EuehbQCGPy+lXehH7jxp
tmsg4Rr/SF1O1F6UePxK/m02yyYy6Nyf0nNr31NZr4ROdT8UFAVPNz0Tw4k6HhHY
OmRURPAsmPSaBKgbInjB/nW+m8a1l8KW63uv1IpZgQXFnXRUCJ5Gj7q/W7y02+fy
oP1+x3jzcTMowtaef664lckVVykW8Z8BHmsljcFgsfwtgX32Jps0GuALCdwkB0jk
d/fWwC61EKN48yxiCqwVyRSg7Rv4xUgJ7cQ1tBRvpg3Z3P8Jxirv8jWlmKrGIrTx
rTpbPPHbqj6KHfX2ulnsuyFyrb0EByzTMNEVhTRSpHa4DK1udTmE64tfE72g5QaE
Y+7P+P2H3FpmOHu+EeM5ePuTIhLulZKsVbuN0mpAVXaqyk25p8VeePsUOQDnp4hx
qJkSTT5s7gG9gEHCz01Xrz7RsYJ6yhJPNthS/wNlQd8crgNmdU/dhDlNxdKl/v64
NIqatwlFTwuNTPg67YUKlh1sWRj+0v6pQhAChQ5gBti8PU2bs/6D6bcm+zGyRq6H
5SHb0IvAlsxUUdAIq1cMraLUPO/U8VyKZPDdy5yFhvXuN4OHKK5CFmsV1UW5bjao
RkgHgmDW1qd/ObqQ3LdYDhpGqoY3Bx7EbqHDQydXizveAV6/WXY=
=7KuI
-----END PGP SIGNATURE-----

--Apple-Mail=_4F3AE084-960A-496C-926B-4049A8A45332--


From nobody Wed Feb 13 14:48:59 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7BF130DC8 for ; Wed, 13 Feb 2019 14:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOivYGEOouJA for ; Wed, 13 Feb 2019 14:48:43 -0800 (PST)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B5112F1A6 for ; Wed, 13 Feb 2019 14:48:43 -0800 (PST)
Received: by mail-pg1-x544.google.com with SMTP id r11so1868773pgp.6 for ; Wed, 13 Feb 2019 14:48:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2DSAxrkfhnwLxT4l48gTDM709be8iD9fr6bGbaHa6js=; b=T4D+DDc10G9IO2CDiKW8ZcF2bnOKEO0+VYBvlYYhZ9qGoKMwcsLU4CpM8+/WMfLWeO rdCT0H4HfWilKYxJzaLT9FrvfZotsMfZusgvHz0oqWd3i9aDKFsltOMJz76C0w0Rv45b GCNmodXJyxqa7WivWymNoYD3M2tkEwocpT0ns=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2DSAxrkfhnwLxT4l48gTDM709be8iD9fr6bGbaHa6js=; b=B+iirEo6VsU4ZmJJioqtoJCKCFT6VtEUgCjvITmd6TdYVCM34a55SSiVfXFuDbiIEo P/3rZ/S7u2dzki59ZQOU/FkEOsM1xZv5NCj+xiCIaqXu0trsB5vWULySYMRbtpjRHZDY EhNIPRLOVuccvYq723ZSSFlvdrDwxBstljjV41xcd9tYeuwZEzXpXF4MWxHGrrMm58A6 DPDSlonIOFgvr6zC5JllnV6BryviYiWVqeZIibGonZ2d5Q3JqO92GGwIQV8q0pzMGGTk zv05RevsRNROO9l1LG4gWdMFKelXrogvEBaEvP1+XIfVJoIuyPYYbcjVrhr47+rVWtFD hhZQ==
X-Gm-Message-State: AHQUAuY8IN96w9Ri6OZZQE6k5xbmitI1EX3u/jXKQP8KFGTQ+AFlJQn4 FDMVnTzfhak28m5nBjPEzrNoJg==
X-Google-Smtp-Source: AHgI3IZiDk/wOUb43aqUqL7ZKrN073GMDttT+CAZJPtzBpFQWwCCX0Fy8PoerCMtEFJYBnTVeSkNHQ==
X-Received: by 2002:a63:7044:: with SMTP id a4mr499479pgn.359.1550098122934; Wed, 13 Feb 2019 14:48:42 -0800 (PST)
Received: from ?IPv6:2620:101:80fc:224:8d26:fbf4:28ef:eeba? ([2620:101:80fc:224:8d26:fbf4:28ef:eeba]) by smtp.gmail.com with ESMTPSA id o2sm475277pfa.149.2019.02.13.14.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 14:48:41 -0800 (PST)
From: Nils Ohlmeier 
Message-Id: <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F1B83B78-B8AA-411F-8C8F-F30E4E28C8D3"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 13 Feb 2019 14:48:39 -0800
In-Reply-To: 
Cc: Sergio Garcia Murillo , Bernard Aboba , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
To: Emil Ivov 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <8e40d0db-cacb-db93-f2fe-db5b4a7cf7cf@gmail.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 22:48:48 -0000

--Apple-Mail=_F1B83B78-B8AA-411F-8C8F-F30E4E28C8D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Emil,

> On 13Feb, 2019, at 02:37, Emil Ivov  wrote:
>=20
> On Wed, Feb 13, 2019 at 1:34 AM Nils Ohlmeier > wrote:
> Thank you for the input on the framework and the double documents from =
everyone.
>=20
> 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.
>=20
>=20
> 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).
>   https://www.ietf.org/proceedings/95/minutes/minutes-95-perc =

> =20
> 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
>   https://www.ietf.org/proceedings/96/minutes/minutes-96-perc =

> At IETF 98 SSRC immutability and RTX considerations were discussed but =
no proposal made on security implications
>   https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 =

>=20
> This is really quite misleading:
>=20
> We did indeed have a discussion on this was on IETF 96 (Berlin) where =
I was asked
> to describe how this works in a draft, which we did:
>=20
> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 =

>=20
> We then talked about it in Chicago (IETF 98) . No one implied security =
issues any more. This never was a problem.

I wasn=E2=80=99t a WG chair at the time but quoting from the IETF 96 =
meeting minutes section about =E2=80=9CSSRC Immutability Discussion":

"- Emil asked to submit draft explaining the impact of ssrc mutability =
on
    security/ssrc collision/end-point procedures in the perc context.=E2=80=
=9D

And the security considerations section of the above draft is empty.

> No decision was reached and the topic was left open but it had nothing =
to do with the security implications of either approach and the lack of =
consensus was primarily driven by implementation convenience.

While implementation convenience was part of the discussion it was =
raised a few times that the people in favor of allowing SSRC mutability =
never provided any written description of why mutating the SSRC is not a =
problem as pointed out by the design team.

Best
  Nils

> The discussion then morphed into RTX/FEC handling for which we've also =
made submissions.
>=20
> https://mailarchive.ietf.org/arch/msg/perc/eR_1o1Aj8fDBmrEzA0jgL4IL1e4 =

>=20
> Eventually, at some point the chairs decided to declare consensus =
where there wasn't any and the WG just ploughed through. That's where I =
personally disconnected and I have been waiting for last call to voice =
these concerns ever since.
>=20
> The entire WG mode of operation has been an egregious violation of the =
main principles that the IETF stands for.
>=20
> Regards,
> Emil
> =20
>=20
> 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.
>   https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01 =

>   =
https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc =

> Best regards
>   Nils & Suhas
>   PERC WG chairs
>=20
>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo =
> wrote:
>>=20
>> PERC may be a valid solution for some scenarios, maybe SIP.
>>=20
>> 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.
>>=20
>> Best regards
>>=20
>> Sergio
>>=20
>>>=20
>>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>>> Sergio -
>>>>=20
>>>> 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?
>>>>=20
>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo =
> wrote:
>>>>=20
>>>>> I think Emil and Bernard have described quite precisely where we =
are and how we managed to get here.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Best regards
>>>>> Sergio
>>>>>=20
>>>>>=20
>>>>> On 02/02/2019 18:42, Emil Ivov wrote:
>>>>>>=20
>>>>>>=20
>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba =
> wrote:
>>>>>> Emil said:
>>>>>>=20
>>>>>> "The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents."
>>>>>>=20
>>>>>> [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".=20
>>>>>>=20
>>>>>> 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.=20
>>>>>>=20
>>>>>> I don=E2=80=99t know that this goal is a direct consequence of =
the framework=E2=80=99s 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> This approach was referred to as =E2=80=9Cwedging RTX and FEC=E2=80=
=9D as it places them in between the two encryption operations.
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> Applications will apply SRTP-double first and, those that need to =
use FEC and RTX would have to apply them only after.=20
>>>>>>=20
>>>>>> It was quickly pointed out that this not only destroys the stated =
=E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, =
those of you who use FEC/RTX will simply do a third round of SRTP=E2=80=9D=
, thus arriving at a total of three encryptions for every packet..
>>>>>>=20
>>>>>> The discussions around this topic were highly contentious.
>>>>>>=20
>>>>>> Hope this makes things clear,
>>>>>> Emil
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov > wrote:
>>>>>> Yes pretty much those.
>>>>>>=20
>>>>>> The need to do a triple encryption for example is a particularly =
egregious consequence of the order problem. That=E2=80=99s a problem =
specific to the =E2=80=9Cdouble=E2=80=9D documents.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Emil
>>>>>>=20
>>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba =
> wrote:
>>>>>> "on the consensus not reached on this and other topics."
>>>>>>=20
>>>>>> [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:
>>>>>>=20
>>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>>> * Whole frame encryption versus payload encryption
>>>>>>=20
>>>>>> 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?=20
>>>>>>=20
>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD =
> wrote:
>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this =
and other topics.
>>>>>>=20
>>>>>> Sent from my iPhone
>>>>>>=20
>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero > wrote:
>>>>>>=20
>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out =
there.
>>>>>>>=20
>>>>>>> Lorenzo
>>>>>>>=20
>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov > 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.
>>>>>>>=20
>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting =
could not be allowed=E2=80=9D is a conclusion that ever had any =
consensus in PERC, regardless of what WG leadership is trying to make =
everyone believe.
>>>>>>>=20
>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba =
> wrote:
>>>>>>> Richard said:
>>>>>>>=20
>>>>>>> "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."
>>>>>>>=20
>>>>>>> [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?=20
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo =
> wrote:
>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>> So I would propose we add something like the following to this =
definition:=20
>>>>>>>>=20
>>>>>>>> "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).
>>>>>>>=20
>>>>>>> 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 ?
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>    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.
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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:
>>>>>>>=20
>>>>>>> =
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryp=
tion =

>>>>>>> Best regards
>>>>>>>=20
>>>>>>> Sergio
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Perc mailing list
>>>>>>> Perc@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>> --=20
>>>>>>> sent from my mobile
>>>>>>>=20
>>>>>>> --=20
>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la =
brevit=C3=A0.
>>>>>> --=20
>>>>>> sent from my mobile
>>>>>> --=20
>>>>>> sent from my mobile
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> Perc@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>=20
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/perc =

>=20
>=20
>=20
> --=20
> https://jitsi.org 

--Apple-Mail=_F1B83B78-B8AA-411F-8C8F-F30E4E28C8D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Emil,

On 13Feb, 2019, at 02:37, Emil =
Ivov <emcho@jitsi.org> wrote:

On =
Wed, Feb 13, 2019 at 1:34 AM Nils Ohlmeier <nohlmeier@mozilla.com> 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).
  https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
 
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
  https://www.ietf.org/proceedings/96/minutes/minutes-96-perc

At IETF 98 SSRC immutability and RTX =
considerations were discussed but no proposal made on security =
implications
  https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00<=
/span>

This is really quite =
misleading:

We did indeed have a =
discussion on this was on IETF 96 (Berlin) where I was asked
to describe how this works in a draft, which we did:

https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

We then talked about it in Chicago (IETF 98) . =
No one implied security issues any more. This never was a =
problem.

I wasn=E2=80=99t a WG chair at the time but =
quoting from the IETF 96 meeting minutes section about =E2=80=9CSSRC =
Immutability Discussion":

"- Emil =
asked to submit draft explaining the impact of ssrc mutability =
on
    security/ssrc collision/end-point =
procedures in the perc context.=E2=80=9D

And the security considerations section =
of the above draft is empty.

No decision was reached and the =
topic was left open but it had nothing to do with the security =
implications of either approach and the lack of consensus was primarily =
driven by implementation =
convenience.

While implementation convenience was part of the =
discussion it was raised a few times that the people in favor of =
allowing SSRC mutability never provided any written description of why =
mutating the SSRC is not a problem as pointed out by the design =
team.

Best
  =
Nils

The discussion then =
morphed into RTX/FEC handling for which we've also made =
submissions.

https://mailarchive.ietf.org/arch/msg/perc/eR_1o1Aj8fDBmrEzA0jg=
L4IL1e4

Eventually, at some point the chairs decided to declare =
consensus where there wasn't any and the WG just ploughed through. =
That's where I personally disconnected and I have been waiting for last =
call to voice these concerns ever since.

The entire WG mode of operation has =
been an egregious violation of the main principles that the IETF stands =
for.

Regards,
Emil
 

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.
  https://datatracker.ietf.org/meeting/99/materials/minutes-99-pe=
rc-01
  https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7=
wkf4-bc

Best regards
  Nils & =
Suhas
  PERC WG chairs

On 2Feb, 2019, at 13:37, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

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?

On Feb 2, =
2019, at 3:31 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

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:


On =
Sat 2 Feb 2019 at 16:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Emil said:

"The need to do a triple encryption for example is a =
particularly egregious consequence of the order problem. That=E2=80=99s =
a problem specific to the =E2=80=9Cdouble=E2=80=9D 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=E2=80=99t know that this goal is a direct =
consequence of the framework=E2=80=99s 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 =E2=80=9Cwedging RTX and FEC=E2=80=9D 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 =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =E2=80=9Cwell, those of you who use FEC/RTX will simply do =
a third round of SRTP=E2=80=9D, 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



On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org> wrote:
Yes pretty much those.

The need to =
do a triple encryption for example is a particularly egregious =
consequence of the order problem. That=E2=80=99s a problem specific to =
the =E2=80=9Cdouble=E2=80=9D 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 Sat 2 Feb 2019 at =
12:23, Bernard Aboba <bernard.aboba@gmail.com> wrote:
"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? 

On Sat, Feb =
2, 2019 at 5:40 AM Alexandre GOUAILLARD <alex.gouaillard@cosmosoftware.io> wrote:
+1 on ssrc rewriting, and on the consensus not =
reached on this and other topics.

Sent from my iPhone

On 2 Feb 2019, at 17:18, Lorenzo Miniero <lorenzo@meetecho.com> wrote:

+1, SSRC rewriting is pretty much fundamental to all SFUs out =
there.

Lorenzo

Il 2 febbraio 2019 10:19:06 CET, =
Emil Ivov <emcho@jitsi.org> 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 =E2=80=9CSSRC=
 rewriting could not be allowed=E2=80=9D is a conclusion that ever had =
any consensus in PERC, regardless of what WG leadership is trying to =
make everyone believe.

On Sat 2 Feb 2019 at =
06:21, Bernard Aboba <bernard.aboba@gmail.com> wrote:
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia =
Murillo <sergio.garcia.murillo@gmail.com> =
wrote:
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-a=
rch-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/e=
xplainer.md#encryption
Best =
regards
Sergio
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
-- 
sent from my =
mobile

-- 
Inviato dal =
mio dispositivo Android con K-9 Mail. Perdonate la =
brevit=C3=A0.
-- 
sent from my =
mobile
-- 
sent from my mobile

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


________=
_______________________________________
Perc mailing =
list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc



-- 
https://jitsi.org

=

--Apple-Mail=_F1B83B78-B8AA-411F-8C8F-F30E4E28C8D3--


From nobody Wed Feb 13 15:42:53 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B483130F07; Wed, 13 Feb 2019 15:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5W8JMJ6q_cI; Wed, 13 Feb 2019 15:42:41 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729D5128B01; Wed, 13 Feb 2019 15:42:41 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id i12so4533412wrw.0; Wed, 13 Feb 2019 15:42:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=eEIlf2GqXb0N7Q208aYzdnj7LnK0OTWG8c9+rwaH3NA=; b=EjseMjGIu7RL6m+0dyhWA7P519EXUfwbQbiaFi6Ydg1P+EbRY2WezKO3v/k+q4gGIe ukVv4C7Tm7uqToJrR8h6Lhe0+fMYKGYbK2DfpuyMVufgDM6A0FaaWhal8LKCmKHHjVgS oGj8LbWhS7IgbnowaZIwOhVTomDeIkKbMHel7ZCFfypSh1y+Uyg8PJ8zEHPWA5nY8IqK KfzP/WlPvlHOcFzLlrKjHXpTN2FM2fc8UnOg35sM6TzTwvC9cGEMkgBMvYi0+eFQRlTs WYzRnntAnL9gEunCN8sqYPyLhVYHQ+dDiTYqtr+BTv+qjJpsIRSB8W5DHxID9Era+gMv pTpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=eEIlf2GqXb0N7Q208aYzdnj7LnK0OTWG8c9+rwaH3NA=; b=LELpNH12tXOO5xJeSFV4dbuYgobJxi2TzYFAIldRh9M9I7zOZ4DyRD2OwO1toMJVgs WiQxwdF2O8r0VRq98I0NRynyW2VSNTD9B2VoCW0j0OVRpXVr32Wgwet+mOlDUOaf9Ee6 kuG6lwYyAJbNC+JegT55Rrq3wH49tK/PA55WLTRn4uFmloZghAoG3tROQ/XveC6cZGMG xg3cVSiXX80hi86uvT8oK5A1hHJOann8+vuv39X8Fgf29oMjiJScQQgZCWsOm2IzekKL xvkNtvgnBMwn2RfoL/JdnnAhh2k5Odp/ymaPQWGtThHdwHaCoHK6fd0dGMJP7v1BlARi QnDg==
X-Gm-Message-State: AHQUAuYr1+bzr57MsONYzmmKX/b1eYIStxk8Vam1qbKhQIOhEfbn8F9V lyKgPN8M1+ZFXx0QnmWqnZY=
X-Google-Smtp-Source: AHgI3IZs6QFPtevTiNgi3QB/humcCpcnMMMGPLEyviSoyG366H53kjNHzeJ8QV3CDy5uZ0SceL1CYg==
X-Received: by 2002:a5d:428b:: with SMTP id k11mr439465wrq.17.1550101359905; Wed, 13 Feb 2019 15:42:39 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id 2sm966311wrg.89.2019.02.13.15.42.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 15:42:39 -0800 (PST)
To: Nils Ohlmeier , Emil Ivov 
Cc: Bernard Aboba , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com>
From: Sergio Garcia Murillo 
Message-ID: <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com>
Date: Thu, 14 Feb 2019 00:47:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com>
Content-Type: multipart/alternative; boundary="------------4D1E968615682A386EA0BE22"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 23:42:46 -0000

This is a multi-part message in MIME format.
--------------4D1E968615682A386EA0BE22
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 13/02/2019 23:48, Nils Ohlmeier wrote:
> While implementation convenience was part of the discussion it was 
> raised a few times that the people in favor of allowing SSRC 
> mutability never provided any written description of why mutating the 
> SSRC is not a problem as pointed out by the design team.

All SFUs I am aware of performs SSRC rewriting, it is much more than 
implementation convenience.

I assume that the ssrc rewriting security issue comes from the splicing 
attack described in:

https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01


        7.2.4
        .
        Splicing Attack



    The splicing attack is an attack where a MDD receiving multiple media
    sources splices one media stream into the other.  If the MDD would be
    able to change the SSRC without the receiver having any method for
    verifying the orignal source ID, then the MDD could first deliver
    stream A.  And if the sequence numbers and other information allows
    it, the MDD can forward stream B under the same SSRC as stream A was
    previously forwarded.

    This attack is mitigated by requiring each rtp stream to have unique
    source IDs that are provided to the receiver.  That way the receiver
    would detect when the source ID switches for these streams.


Note that this attack happens also for perc double even without ssrc 
rewriting as there is no way of verifying that a particular ssrc is from 
a given participant as all participants share the same key and there is 
no protocol in place for mapping ssrcs to participants.

Also note that we have solved this in one of our deployments using PERC 
lite allowing ssrc rewriting and app key management, using a different 
ssrc for the OHB payload used for inner encryption and the outer/HBH rtp 
packet. The inner/OHB ssrc(=participant Id) is then assigned by the key 
management server together with the encryption key for each participant 
so it can be used for mapping ssrcs to participants and allows verifying 
the origin of a packet end to end.


Best regards

Sergio


--------------4D1E968615682A386EA0BE22
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 13/02/2019 23:48, Nils Ohlmeier
      wrote:

    

    
While
      implementation convenience was part of the discussion it was
      raised a few times that the people in favor of allowing SSRC
      mutability never provided any written description of why mutating
      the SSRC is not a problem as pointed out by the design team.

    
All SFUs I am aware of performs SSRC rewriting, it is much more
      than implementation convenience.

    
I assume that the ssrc rewriting security issue comes from the
      splicing attack described in:

    
https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01

    
7.2.4.  Splicing Attack


   The splicing attack is an attack where a MDD receiving multiple media
   sources splices one media stream into the other.  If the MDD would be
   able to change the SSRC without the receiver having any method for
   verifying the orignal source ID, then the MDD could first deliver
   stream A.  And if the sequence numbers and other information allows
   it, the MDD can forward stream B under the same SSRC as stream A was
   previously forwarded.

   This attack is mitigated by requiring each rtp stream to have unique
   source IDs that are provided to the receiver.  That way the receiver
   would detect when the source ID switches for these streams.

    


    

    
Note that this attack happens also for perc double even without
      ssrc rewriting as there is no way of verifying that a particular
      ssrc is from a given participant as all participants share the
      same key and there is no protocol in place for mapping ssrcs to
      participants.

    
Also note that we have solved this in one of our deployments
      using PERC lite allowing ssrc rewriting and app key management,
      using a different ssrc for the OHB payload used for inner
      encryption and the outer/HBH rtp packet. The inner/OHB
      ssrc(=participant Id) is then assigned by the key management
      server together with the encryption key for each participant so it
      can be used for mapping ssrcs to participants and allows verifying
      the origin of a packet end to end.

    

    


    

    
Best regards

    
Sergio

    

  


--------------4D1E968615682A386EA0BE22--


From nobody Wed Feb 13 15:58:30 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D84130E57; Wed, 13 Feb 2019 15:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1mk-GX8CVYI; Wed, 13 Feb 2019 15:58:26 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BAB130E6B; Wed, 13 Feb 2019 15:58:25 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id v26so4295759wmh.3; Wed, 13 Feb 2019 15:58:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=kTtmRgiGhHqq/L64DouXDpRHstO6pDwfUSHQnBr/ODw=; b=YHypJcMHcj8gUDqMjO1XpvlytEJEc1ZRxV0/8pbyH/J3dbpnAndf4VWVQvV5i/8DTl ilV+C7fa3+x29emMlyM36WMYsopeOioWtNDxiK3SawrSMf/K47lv00mM5Q/0Lvm/G5EK Z5HZjUjSgdpWtkm8gnq1NR4RWxKA9AcI1/JzspF1Eu9NJFKEns90BAnihWNL57qbIdrw pkeMSf4onpPgwX3mdyEldxSoY5dEFt7NLCMOznwxD+fJrFXuUUikZZYvPnfwfAFohY9k +6hy1pe6YTPtOobd4YzDyqVj9a0SFQEdgMoFbQYZXd3lYjHSs1OwEoFKxOlwIzIX+DMo Ar1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kTtmRgiGhHqq/L64DouXDpRHstO6pDwfUSHQnBr/ODw=; b=K7tlEk1E7tNvj/qvRQ7lD/yUBPYZr8Nt7gJfrWctmKHzCV68kTAejsx7lVzS0b0VKW T66UX9cR0L1UByFPIzkMmsbTY8p8BurR4tau4ZrKW6xQsBpJeGwLNM5pwHnJy2ikeNfr NwpY36+0NSwNwEBUyxEkDfZ3jIEfgmL5Jcgpio/La7hjCSp+am0NSpE6FbxmeBBVh3DW WHfi0y4VvBl+06DYWy7Cw63qXQY/lfI1gsKbjpVzWPj6Xzuv+FttTRPsOY3t03gBEsF7 tjweCwh8EUBmAaqRKCtH/vap8b200N6t7KjvBnYMLD4+INMXe9MGMLD+HCnp6f6bSNu7 Wo+A==
X-Gm-Message-State: AHQUAuav4dhFDybYZweWTZ7yvYt53lPCuqmo3fp5EQNQhqLD70ScUdPJ JWFwIx3uBQr25TVtEsCiN4M=
X-Google-Smtp-Source: AHgI3Iba3rwOq4mW2wXt/8pXXdVezkgTbpC8xDYxGwqd8N9iOdxYcTjUHxsny6V02G+k1PqPvwchCw==
X-Received: by 2002:a1c:ac42:: with SMTP id v63mr401152wme.119.1550102304278;  Wed, 13 Feb 2019 15:58:24 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id y22sm1856039wrd.45.2019.02.13.15.58.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 15:58:23 -0800 (PST)
To: Nils Ohlmeier , Emil Ivov 
Cc: Bernard Aboba , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com>
From: Sergio Garcia Murillo 
Message-ID: <8136dee9-74c9-8ac1-3cb8-f18f08b1ff3b@gmail.com>
Date: Thu, 14 Feb 2019 01:03:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Feb 2019 23:58:29 -0000

On 13/02/2019 23:48, Nils Ohlmeier wrote:
> While implementation convenience was part of the discussion it was 
> raised a few times that the people in favor of allowing SSRC 
> mutability never provided any written description of why mutating the 
> SSRC is not a problem as pointed out by the design team.
>
Moreover, in the (maybe not so) near future of ssrc-less signaling (at 
least in webrtc), where the MID extensions are HBH, how would ssrc 
rewriting even be a potential risk?

Has this group analyzed the implications and new attacks that this may 
cause?

Best regards

Sergio


From nobody Wed Feb 13 17:01:15 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F721310C9; Wed, 13 Feb 2019 17:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6AZOEJhdKPC; Wed, 13 Feb 2019 17:01:10 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F69F1310C3; Wed, 13 Feb 2019 17:01:10 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id bj4so2128910plb.7; Wed, 13 Feb 2019 17:01:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=09Bv5s2n0qqOVWdv64eG97x84L/tL4+rbHanJci2xlQ=; b=EqDGfy6Tkwepdv6sqIiLlzME3CWtZB4lXT8d0JpmOMWmQ6x5qg5GQ1Rnu0yVrTM+eu JIqlnGipqcHZhh5Y/3e6GLeANSAvTAhExpkdYfW92ki+3VD0ioKJzweG+3RNZmepTjnZ 95tsEp6P0dbgN4YmEAgYULSi/SF7O0F4me3dOGyJmgXXmyPID9/pCM4+wXNNRN0/+m+I D7fgQGarqCVUagy187gAgHKLxL9OIjyw0Kn3ZpgVc4aQStf9Rl/PBydaGmbwn96/ImBZ Dl1PbN32Ts6E1Tqw7rYKvkwD+Zwh2gJS/q2xGgoQ4p2+XTWu1YnCwhZOc8kXAKSLJpBJ frRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=09Bv5s2n0qqOVWdv64eG97x84L/tL4+rbHanJci2xlQ=; b=MD4PX1eVGvciSXU5zF7zYNmoCDDb2Fozfay6YPy5IklvB3ucCDTI3HJwLZyjH3vmWg 2Gr14+QY7jDhdEStJZBt5FCu0QJDtCZLqk1Mgh3vDLIYcqyp6paLNBaIVeU+080S2cHl UhvI5WnEqbgMOgDujp6pKoPV6b2+xM1k8wrupohod1UVf14GJqWl8CmzSE+k+2Xb1FiX p240GM4hjjjsEp+kT7TcBxgUh2Bz8Wv/WIG0FF1CZJUoekkRSFzr2Deyoi7690VV0G1h grvuAB5RtnMhF9H2mT3BBxKnoUtr+7nhXiJItAR4VW41zrlIJJU+12YFaSls8R60uZPb P+kQ==
X-Gm-Message-State: AHQUAuZ5ivkXC1J5aH9bMT4/9+JMvpxnarruu84RWEPdk0gCVYW9QAO9 0FcQoc92X1c0XvUgtx4dUAk=
X-Google-Smtp-Source: AHgI3IYu/pmqPWoPBPWPOxFt0Irbwo1LqrlWFP/KsIgFYQ9EOfsOV7Zc3oWT+QAp7bzgZBWALssCVA==
X-Received: by 2002:a17:902:28c1:: with SMTP id f59mr1181277plb.37.1550106068391;  Wed, 13 Feb 2019 17:01:08 -0800 (PST)
Received: from ?IPv6:2600:380:803a:a3ec:b49c:4ae:1adf:ceac? ([2600:380:803a:a3ec:b49c:4ae:1adf:ceac]) by smtp.gmail.com with ESMTPSA id 24sm721902pfr.75.2019.02.13.17.01.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 17:01:07 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-C0EDDB55-0EB5-402F-A05E-C04FC9A0BEB3
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com>
Date: Wed, 13 Feb 2019 17:01:05 -0800
Cc: Nils Ohlmeier , Emil Ivov , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
Content-Transfer-Encoding: 7bit
Message-Id: <753988DB-FC9A-4E8F-B495-347AD943B6C8@gmail.com>
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com>
To: Sergio Garcia Murillo 
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 01:01:14 -0000

--Apple-Mail-C0EDDB55-0EB5-402F-A05E-C04FC9A0BEB3
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo  wrote:
> All SFUs I am aware of performs SSRC rewriting, it is much more than imple=
mentation convenience.
>=20
[BA] In particular, reusing an SSRC for the =E2=80=9Cdominant speaker=E2=80=9D=
 (which can change)  is a common practice with switching of audio and video g=
oing together.=20
> Also note that we have solved this in one of our deployments using PERC li=
te allowing ssrc rewriting and app key management, using a different ssrc fo=
r the OHB payload used for inner encryption and the outer/HBH rtp packet. Th=
e inner/OHB ssrc(=3Dparticipant Id) is then assigned by the key management s=
erver together with the encryption key for each participant so it can be use=
d for mapping ssrcs to participants and allows verifying the origin of a pac=
ket end to end.
>=20
[BA] This solves the key identification issue, and can also be used to notif=
y participants that the origin has changed if that is a concern.  This poten=
tial solution was pointed out during the discussion as I recall.

Far more serious than splicing attacks is access to cleartext media which th=
anks to ML can be used to create realistic =E2=80=9Cfake news=E2=80=9D.  PER=
C does not address that threat, but schemes with stricter trust models might=
.=

--Apple-Mail-C0EDDB55-0EB5-402F-A05E-C04FC9A0BEB3
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


On =
Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

    
All SFUs I am aware of performs SSRC rewriting, it is much more
      than implementation convenience.
[BA] In particu=
lar, reusing an SSRC for the =E2=80=9Cdominant speaker=E2=80=9D (which can c=
hange)  is a common practice with switching of audio and video going to=
gether. 

    
Also note that we have solved this in one of our deployments
      using PERC lite allowing ssrc rewriting and app key management,
      using a different ssrc for the OHB payload used for inner
      encryption and the outer/HBH rtp packet. The inner/OHB
      ssrc(=3Dparticipant Id) is then assigned by the key management
      server together with the encryption key for each participant so it
      can be used for mapping ssrcs to participants and allows verifying
      the origin of a packet end to end.
[BA]=
 This solves the key identification issue, and can also be used to notify pa=
rticipants that the origin has changed if that is a concern.  This pote=
ntial solution was pointed out during the discussion as I recall.
=

Far more serious than splicing attacks is access to cleartext=
 media which thanks to ML can be used to create realistic =E2=80=9Cfake news=
=E2=80=9D.  PERC does not address that threat, but schemes with stricte=
r trust models might.
=

--Apple-Mail-C0EDDB55-0EB5-402F-A05E-C04FC9A0BEB3--


From nobody Wed Feb 13 20:02:25 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF83130F1D; Wed, 13 Feb 2019 19:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgEaXSWMnOeQ; Wed, 13 Feb 2019 19:51:29 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CEE5130F1B; Wed, 13 Feb 2019 19:51:29 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1E3pGIB090811 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Feb 2019 21:51:17 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550116282; bh=Ge2t8gS/K6L0ABkfW65Ti5hH03RnFUtSi7+XuANJUx0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=o/s8xB5ehM3O5xkK6zy8nBfyuT33N5Yg5lxTX4K7gxvvomoDmRlgIFNYjXYZt2gTq aqFfS2UAYfAqO81p0UYBpS/0NO2ED7kVUZeZQYvaabKcmho29OBNplBQnBEYMABkMX h1YClC3VZcmttQqxPKk2atqth4SefsYn1YpZ+45E=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell 
Message-Id: <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3F00A0AA-0F1A-4029-AAA9-2006CE91B798"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 13 Feb 2019 21:51:14 -0600
In-Reply-To: <417923aa-8771-863e-ee12-4107f674d918@gmail.com>
Cc: Nils Ohlmeier , IETF discussion list , Emad Omara , Emil Ivov , perc@ietf.org, Harald Tveit Alvestrand , Alexandre GOUAILLARD , Lorenzo Miniero , Bernard Aboba 
To: Sergio Garcia Murillo , Cullen Jennings 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com> <417923aa-8771-863e-ee12-4107f674d918@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
X-Mailman-Approved-At: Wed, 13 Feb 2019 20:02:24 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 03:51:33 -0000

--Apple-Mail=_3F00A0AA-0F1A-4029-AAA9-2006CE91B798
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_177F9312-3C27-4511-B17E-28BC11E427EE"


--Apple-Mail=_177F9312-3C27-4511-B17E-28BC11E427EE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

(+Cullen)
(as individual)

Hi Sergio,

I don=E2=80=99t recall, and I don=E2=80=99t see anything in the notes or =
email consensus call, that would suggest the consensus included anything =
along the lines =E2=80=9Cit=E2=80=99s okay to let the js application =
have the media keys.=E2=80=9D That is, even if the idea was to let PERC =
do it=E2=80=99s thing and let other groups spin their own key management =
systems, I don=E2=80=99t think there=E2=80=99s a consensus that everyone =
would be okay with that particular approach.

Cullen: As the other join presenter, do you have thoughts?

Thanks!

Ben.

> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo =
 wrote:
>=20
> Hi Ben,
>=20
> 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).
>=20
> 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.
>=20
> Best regards
> Sergio
>=20
>=20
>=20
> On 13/02/2019 21:21, Ben Campbell wrote:
>> (as individual)
>>=20
>> Hi Sergio,
>>=20
>> 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?
>>=20
>> Thanks!
>>=20
>> Ben.
>>=20
>>> On Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo =
> wrote:
>>>=20
>>> You are missing an important piece on the timeline:
>>>=20
>>> Statement from the IETF ART and SEC Area Directors regarding the =
"Trusted application, untrusted intermediary" use case
>>> https://datatracker.ietf.org/liaison/1614/ =

>>>=20
>>> 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.
>>>=20
>>> Best regards
>>> Sergio
>>>=20
>>> On 13/02/2019 2:34, Nils Ohlmeier wrote:
>>>> Thank you for the input on the framework and the double documents =
from everyone.
>>>>=20
>>>> 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.
>>>>=20
>>>>=20
>>>> 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).
>>>>   https://www.ietf.org/proceedings/95/minutes/minutes-95-perc =

>>>>=20
>>>> 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
>>>>   https://www.ietf.org/proceedings/96/minutes/minutes-96-perc =

>>>> At IETF 98 SSRC immutability and RTX considerations were discussed =
but no proposal made on security implications
>>>>   https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 =

>>>> 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.
>>>>   =
https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01 =

>>>>   =
https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc =

>>>> Best regards
>>>>   Nils & Suhas
>>>>   PERC WG chairs
>>>>=20
>>>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo =
> wrote:
>>>>>=20
>>>>> PERC may be a valid solution for some scenarios, maybe SIP.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Best regards
>>>>>=20
>>>>> Sergio
>>>>>=20
>>>>>>=20
>>>>>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>>>>>> Sergio -
>>>>>>>=20
>>>>>>> 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?
>>>>>>>=20
>>>>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo =
> wrote:
>>>>>>>=20
>>>>>>>> I think Emil and Bernard have described quite precisely where =
we are and how we managed to get here.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> Best regards
>>>>>>>> Sergio
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 02/02/2019 18:42, Emil Ivov wrote:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba =
> wrote:
>>>>>>>>> Emil said:
>>>>>>>>>=20
>>>>>>>>> "The need to do a triple encryption for example is a =
particularly egregious consequence of the order problem. That=E2=80=99s =
a problem specific to the =E2=80=9Cdouble=E2=80=9D documents."
>>>>>>>>>=20
>>>>>>>>> [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".
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> I don=E2=80=99t know that this goal is a direct consequence of =
the framework=E2=80=99s 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.
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> This approach was referred to as =E2=80=9Cwedging RTX and =
FEC=E2=80=9D as it places them in between the two encryption operations.
>>>>>>>>>=20
>>>>>>>>> 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:
>>>>>>>>>=20
>>>>>>>>> Applications will apply SRTP-double first and, those that need =
to use FEC and RTX would have to apply them only after.
>>>>>>>>>=20
>>>>>>>>> It was quickly pointed out that this not only destroys the =
stated =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =
=E2=80=9Cwell, those of you who use FEC/RTX will simply do a third round =
of SRTP=E2=80=9D, thus arriving at a total of three encryptions for =
every packet..
>>>>>>>>>=20
>>>>>>>>> The discussions around this topic were highly contentious.
>>>>>>>>>=20
>>>>>>>>> Hope this makes things clear,
>>>>>>>>> Emil
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov > wrote:
>>>>>>>>> Yes pretty much those.
>>>>>>>>>=20
>>>>>>>>> The need to do a triple encryption for example is a =
particularly egregious consequence of the order problem. That=E2=80=99s =
a problem specific to the =E2=80=9Cdouble=E2=80=9D documents.
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> Emil
>>>>>>>>>=20
>>>>>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba =
> wrote:
>>>>>>>>> "on the consensus not reached on this and other topics."
>>>>>>>>>=20
>>>>>>>>> [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:
>>>>>>>>>=20
>>>>>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>>>>>> * Whole frame encryption versus payload encryption
>>>>>>>>>=20
>>>>>>>>> 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?
>>>>>>>>>=20
>>>>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD =
> wrote:
>>>>>>>>> +1 on ssrc rewriting, and on the consensus not reached on this =
and other topics.
>>>>>>>>>=20
>>>>>>>>> Sent from my iPhone
>>>>>>>>>=20
>>>>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero > wrote:
>>>>>>>>>=20
>>>>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs out =
there.
>>>>>>>>>>=20
>>>>>>>>>> Lorenzo
>>>>>>>>>>=20
>>>>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov > 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.
>>>>>>>>>>=20
>>>>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting =
could not be allowed=E2=80=9D is a conclusion that ever had any =
consensus in PERC, regardless of what WG leadership is trying to make =
everyone believe.
>>>>>>>>>>=20
>>>>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba =
> wrote:
>>>>>>>>>> Richard said:
>>>>>>>>>>=20
>>>>>>>>>> "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."
>>>>>>>>>>=20
>>>>>>>>>> [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?
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo =
> wrote:
>>>>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>>>>> So I would propose we add something like the following to =
this definition:
>>>>>>>>>>>=20
>>>>>>>>>>> "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).
>>>>>>>>>>=20
>>>>>>>>>> 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 ?
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>    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.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> 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:
>>>>>>>>>>=20
>>>>>>>>>> =
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryp=
tion =

>>>>>>>>>> Best regards
>>>>>>>>>>=20
>>>>>>>>>> Sergio
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Perc mailing list
>>>>>>>>>> Perc@ietf.org 
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>>>>> --
>>>>>>>>>> sent from my mobile
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate =
la brevit=C3=A0.
>>>>>>>>> --
>>>>>>>>> sent from my mobile
>>>>>>>>> --
>>>>>>>>> sent from my mobile
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> Perc mailing list
>>>>>>>>> Perc@ietf.org 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>>>=20
>>>>> _______________________________________________
>>>>> Perc mailing list
>>>>> Perc@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>=20
>>>=20
>>> _______________________________________________
>>> Perc mailing list
>>> Perc@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/perc =

>>=20
>=20


--Apple-Mail=_177F9312-3C27-4511-B17E-28BC11E427EE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


(+Cullen)
(as individual)

Hi Sergio,

I don=E2=80=99t recall, and I don=E2=80=99=
t see anything in the notes or email consensus call, that would suggest =
the consensus included anything along the lines =E2=80=9Cit=E2=80=99s =
okay to let the js application have the media keys.=E2=80=9D That is, =
even if the idea was to let PERC do it=E2=80=99s thing and let other =
groups spin their own key management systems, I don=E2=80=99t think =
there=E2=80=99s a consensus that everyone would be okay with that =
particular approach.

Cullen: As the other join presenter, do you have =
thoughts?

Thanks!

Ben.

On Feb 13, 2019, at 2:49 PM, =
Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:


 =20
    
 =20
  

    
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.

        


          

            
On Feb 13, 2019, at 4:53 AM, Sergio Garcia
              Murillo <sergio.garcia.murillo@gmail.com>
              wrote:

            

            

              
              

                
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

                

                
https://datatracker.ietf.org/liaison/1614/
                

                


                

                
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).

                  
 =
 https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
 

                  
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

                  
 =
 https://www.ietf.org/proceedings/96/minutes/minutes-96-perc

                  

                  
At IETF 98 =
SSRC immutability and RTX considerations were discussed but no proposal =
made on security implications

                  
 =
 https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00<=
/span>

                  

                  
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.

                  
 =
 https://datatracker.ietf.org/meeting/99/materials/minutes-99-pe=
rc-01

                  
 =
 https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7=
wkf4-bc

                  

                  
Best =
regards

                  
  Nils =
& Suhas

                  
  PERC =
WG chairs

                  


                    

                      
On 2Feb, 2019, at 13:37, Sergio
                        Garcia Murillo <sergio.garcia.murillo@gmail.com>
                        wrote:

                      

                      

                        
                        
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?

                              


                                On Feb 2, 2019, at 3:31 PM, Sergio
                                Garcia Murillo <sergio.garcia.murillo@gmail.com>
                                wrote:

                                

                              

                              

                                

                                  
                                  
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:

                                  

                                  

                                    
                                    

                                      


                                      

                                      


                                      

                                    

                                    

                                      
On Sat =
2
                                        Feb 2019 at 16:50, Bernard Aboba
                                        <bernard.aboba@gmail.com>
                                        wrote:

                                      

                                      

                                        
Emil
                                          said:
                                          


                                          

                                          
"The need to =
do
                                            a triple encryption for
                                            example is a particularly
                                            egregious consequence of the
                                            order problem. That=E2=80=99s =
a
                                            problem specific to the
                                            =E2=80=9Cdouble=E2=80=9D =
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=E2=80=99t
                                          know that this goal is a
                                          direct consequence of the
                                          framework=E2=80=99s 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
                                          =E2=80=9Cwedging RTX and =
FEC=E2=80=9D 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
                                          =E2=80=9Cdon=E2=80=99t-change-th=
e-app=E2=80=9D 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:
                                          =E2=80=9Cwell, those of you =
who use
                                          FEC/RTX will simply do a third
                                          round of SRTP=E2=80=9D, 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

                                        


                                        

                                        


                                        

                                      

                                    

                                    

                                      

                                        

                                          


                                            

                                              
On
                                                Sat, Feb 2, 2019 at
                                                11:46 AM Emil Ivov =
<emcho@jitsi.org>
                                                wrote:

                                              

                                              

                                                

                                                  
Yes pretty
                                                    much those.

                                                

                                                


                                                

                                                
The
                                                  need to do a triple
                                                  encryption for example
                                                  is a particularly
                                                  egregious consequence
                                                  of the order problem.
                                                  That=E2=80=99s a =
problem
                                                  specific to the
                                                  =E2=80=9Cdouble=E2=80=9D=
 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 Sat 2
                                                      Feb 2019 at 12:23,
                                                      Bernard Aboba =
<bernard.aboba@gmail.com>
                                                      wrote:

                                                    

                                                    

                                                      
"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? 

                                                      

                                                      

                                                      

                                                        
On
                                                          Sat, Feb 2,
                                                          2019 at 5:40
                                                          AM Alexandre
                                                          GOUAILLARD
                                                          <alex.gouaillard@cosmosoftware.io>
                                                          wrote:

                                                        

                                                        

                                                          
+1 on
                                                          ssrc
                                                          rewriting, and
                                                          on the
                                                          consensus not
                                                          reached on
                                                          this and other
                                                          topics.

                                                          

                                                          
Sent
                                                          from my =
iPhone

                                                          


                                                          On 2 Feb 2019,
                                                          at 17:18,
                                                          Lorenzo
                                                          Miniero <lorenzo@meetecho.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
+1,
                                                          SSRC rewriting
                                                          is pretty much
                                                          fundamental to
                                                          all SFUs out
                                                          there.

                                                          

                                                          Lorenzo

                                                          

                                                          
Il
                                                          2 febbraio
                                                          2019 10:19:06
                                                          CET, Emil Ivov
                                                          <emcho@jitsi.org>
                                                          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 =E2=80=9CSS=
RC
                                                          rewriting
                                                          could not be
                                                          allowed=E2=80=9D=
 is a
                                                          conclusion
                                                          that ever had
                                                          any consensus
                                                          in PERC,
                                                          regardless of
                                                          what WG
                                                          leadership is
                                                          trying to make
                                                          everyone
                                                          believe.

                                                          


                                                          

                                                          
On
                                                          Sat 2 Feb 2019
                                                          at 06:21,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia =
Murillo
                                                          <sergio.garcia.murillo@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
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-sec=
urity-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/m=
aster/explainer.md#encryption

                                                          
Best
                                                          regards
Sergio

                                                          

                                                          

_______________________________________________

                                                          Perc mailing
                                                          list

                                                          Perc@ietf.org

                                                          https://www.ietf.org/mailman/listinfo/perc

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          -- 

                                                          
s=
ent
                                                          from my =
mobile

                                                          

                                                          

                                                          

                                                          -- 

                                                          Inviato dal
                                                          mio
                                                          dispositivo
                                                          Android con
                                                          K-9 Mail.
                                                          Perdonate la
                                                          =
brevit=C3=A0.

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                                -- 

                                                
sent
                                                  from my mobile

                                              

                                            

                                          

                                        

                                      

                                    

                                    -- 

                                    
sent
                                      from my mobile

                                    

                                    

                                    
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


                                  


                                  

                                

                              

                            

                          

                        

                        =
_______________________________________________

                        Perc mailing list

                        Perc@ietf.org

                        https://www.ietf.org/mailman/listinfo/perc
                      

                    

                  

                  

                


                

              

              _______________________________________________

              Perc mailing list

              Perc@ietf.org

              https://www.ietf.org/m=
ailman/listinfo/perc

            

          

        

        

      

    


    

  




=

--Apple-Mail=_177F9312-3C27-4511-B17E-28BC11E427EE--

--Apple-Mail=_3F00A0AA-0F1A-4029-AAA9-2006CE91B798
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxk5bIACgkQgFZKbJXz
1A3DIBAAkOATXYpCJEH0TzG/SHvScb9BZ1fgaXsJMa5s656spzlhrfc/jGpES7dX
+fUvGuIcSTlnt5l0apjYuNLHEf4Qlg14chsPE3f1VenwKMmoi46A5420wWjAEO4j
hieHUJSWjtOKQf7fR1ZQ6go5pCYC8vAeMaNfapl2NST4TdzNCQ20hejy4utpELu+
fA3Mq7WE7Ybc27chq0658svP9S6J5eZpDd8e9sRhLaAkLH+ntlq352mkBjJJh+8X
3cbTCHrlHjN1jIa4Iss06e3Yr0DF12DQT6tU50/3Gm0TYTTEOnhX7oXbMpvI2Ysb
KU6CGkAyL7UvVQ0e/hXui5/rEGBi+15ve77zTochsTqWFAV0My40eJhO/VonE7K5
6RrrrVdoEQLR4bENVH2YGgqPTyvhy0/cr4IuUpSRdIqIKKjMn0zc7i2DRvs52Wyp
XNVM3pmEZNHhjxN2Lmd3UJ2mY6NTv8kpH0cNlJqvlhgNA/d4+OjSjCKDZ8fhZl/4
kGCMsTsRo+Jn1ax/9LngXIrpv8TbKE96MQegdvIWRxfSCd50g6nF6g/w2eCOsPw5
ZBeprC6usAQ5k45GZjlzbcplVs4W1ng5UwdTZGxd+IbJemGSW1rLkQFBqlaxJu9e
H6B+Ao2v2ehO4dSyCogtb68bDoHLyOwWMZILAHL9EiKzv2zSnHw=
=45qC
-----END PGP SIGNATURE-----

--Apple-Mail=_3F00A0AA-0F1A-4029-AAA9-2006CE91B798--


From nobody Wed Feb 13 23:16:54 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC03131027; Wed, 13 Feb 2019 23:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_JVOgFx4wbQ; Wed, 13 Feb 2019 23:16:51 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9692E12D7F8; Wed, 13 Feb 2019 23:16:50 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id q21so4934703wmc.5; Wed, 13 Feb 2019 23:16:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u8vrR7odtSK8C+wBLZt0iP1BVXZ+P9Ac9fnkQ7kVCMk=; b=d2rDz8gYEWkhWUMvwitA5rrD/FBnMqhIQWnVQT7F9/WEHNmpO9b93xWvbskp0cO5gQ FXBWdExxsKdElIMg5R5drXH1RCXGBPrDIUc03Uk7LaVCSgTObWLZQjNZp8p8tBN/TI45 gyHJPexPv+gykOWyNYKv2oY86WlI5fp+zr22+DsM54xKXOTq7TS3obxFtLIGRdjqtxo4 BGHRCZ/ZdldQs+tYrvg1fklDaWiwam3VFDkDdLZSWTO4cwfZGOWgRYpnSrWpNXgtB1jF WZEZwOJ8VFNsVeyhzRVJy1fQA6IuqJZw0CgSNciVLr4ayCwN1FDkz2sz3j3QFfwhXVLC 0Qfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u8vrR7odtSK8C+wBLZt0iP1BVXZ+P9Ac9fnkQ7kVCMk=; b=j0P+srWUx+EiJQ3TPLeVFfyVgPU6oLWBSzwhndYfka/8r6pFHidw3WaWOfYpdytgTV mT9AYYwC+cBXRyumh+PvBaCoAXgoNAap63mio1n/lKO4eNXJe686OgYzf2PybWfy31pA l4RC71kmKpvSjLaOXA2bWtB92H3BgElQgeNesOj6WxMkGk4yCo8hswgKy/ITFMFaTLb6 hAPSWVz8CN0fl4sxMyETTvI/UyX1NmdBahdaphcs+SKuIQnb8HmHhhrmqLQMM6+zVxd8 rE5ejZgfMLFFejrByLGB5cHpQeEJl1CsETvhtO1AqBjwoRae2yTcpXDRTFzTuMj02ogL YX8A==
X-Gm-Message-State: AHQUAuaL7S2XKV4oySfx9qkmV2385JBvwBwJjzMNzZoUzUOtJxHlewVs UGN8Yo54Va8c3MtkofgTlcBOX1gKXzGGbSKKDf0=
X-Google-Smtp-Source: AHgI3IacqiZGWKPbGtSMbRgcwkZnuC2WiUO2I1RnEo2qm6lDYrcBLcuUAc0K4Q54ZM+and8VSLH/2S5c87/Xay15E9Q=
X-Received: by 2002:a1c:c181:: with SMTP id r123mr1427484wmf.8.1550128609049;  Wed, 13 Feb 2019 23:16:49 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com> <753988DB-FC9A-4E8F-B495-347AD943B6C8@gmail.com>
In-Reply-To: <753988DB-FC9A-4E8F-B495-347AD943B6C8@gmail.com>
From: Sergio Garcia Murillo 
Date: Thu, 14 Feb 2019 08:16:35 +0100
Message-ID: 
To: Bernard Aboba 
Cc: Nils Ohlmeier , Emil Ivov ,  IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD ,  Lorenzo Miniero 
Content-Type: multipart/alternative; boundary="0000000000001943c40581d57187"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 07:16:53 -0000

--0000000000001943c40581d57187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El jue., 14 feb. 2019 2:01, Bernard Aboba 
escribi=C3=B3:

> On Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> All SFUs I am aware of performs SSRC rewriting, it is much more than
> implementation convenience.
>
> [BA] In particular, reusing an SSRC for the =E2=80=9Cdominant speaker=E2=
=80=9D (which can
> change)  is a common practice with switching of audio and video going
> together.
>

would love to see how simulcast is expected to work without ssrc rewriting
(and without mid)

Best regards
Sergio

>

--0000000000001943c40581d57187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




El jue., 14 feb. 2019 2:01, Bernard Aboba <=
;bernard.aboba@gmail.com>=
 escribi=C3=B3:
<=
div dir=3D"ltr">
On Feb 13, 2019, at 3:47 PM, Sergio =
Garcia Murillo <sergio.garcia.murillo@gmail.com> wro=
te:

    
All SFUs I am aware of performs SSRC rewriting, it is much more
      than implementation convenience.
[BA] In partic=
ular, reusing an SSRC for the =E2=80=9Cdominant speaker=E2=80=9D (which can=
 change) =C2=A0is a common practice with switching of audio and video going=
 together.

would love to see how simulcast is expected to work without ssrc =
rewriting (and without mid)

Best regards=C2=A0
Sergio


--0000000000001943c40581d57187--


From nobody Thu Feb 14 01:51:55 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1083131056 for ; Thu, 14 Feb 2019 01:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZsUkDyWT86g for ; Thu, 14 Feb 2019 01:51:48 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A932413104E for ; Thu, 14 Feb 2019 01:51:47 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id v26so5394200wmh.3 for ; Thu, 14 Feb 2019 01:51:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=4DAScoKeiZiuk6QTI7VU040pZEXDZoe8/0fDRVZ2374=; b=egOxSijZiqsZSUlHwNdM3WpPKXPZyS9Juwx4ZYBsItlwye2F8uXB8L4H7u7p7LMLdW erhQ3neS5ey7+2uPmN6AB9C17cscHDmdrCoCCo/JIR/CtyTSWmSmfo7vbC4F0cNeM+mh ONl/vWonPd0dsi4OdKjwOX82RAo7GQKmi2IXvv8viHaPR3O8jS4K3uh+aPzrJ3xsi6wB eDgV7aSPm4klGlA3Rz6EwT0dKtDYufVENlU1hofS+BfqU5Z3nL9xMzp83UwJ/VCJBuXB XTzUAWX5hqNoJavjuEwzg9Phcoe/OkuJoq6nlhRIH85XAymVMYmo5pDux/IlVZRm8RqA Ye+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4DAScoKeiZiuk6QTI7VU040pZEXDZoe8/0fDRVZ2374=; b=A9y7TG76KXVu5NTBngUyb0vbrWiIitxfxZr2YhvFVWAGy+i4IOCoYDuzdcmYh+lxCt 8z4p+xbQLinJPCB9s7MiSUNZ3ULxjamcLsBfau2Yja57bckAB/b/O3Le7tchyF99aFLk ychjKGNs5gj3FEAFf6gq4n+PPa1GCR9p0bzcC/BLp3WxVLVYBzRGC22A+11jtTvbUw/4 57En0Xr+04rm5uspm6ml2tpr4i+kDQ7qU6ArbOmr6CloYHV4Qqov4M36OJzyem1OuaJO tMvYOla1AeqgKKTZ2Bjyzf4GZf33kvHOFqKPOfriOjg0tPN51bDruvvLDKZxnS3fVYnj pRVA==
X-Gm-Message-State: AHQUAuYRF2llUpNq00p7SgH1Lh7tMLCELSMBK23FQhZ4OnXVdpPY4/J0 gWGi97BFF8Hb5XI9Eeuf55ORzDIV
X-Google-Smtp-Source: AHgI3IZFW+639O8QaCwmbg2waRdSC72Iq535TaBzz98XJK69hToyiisLW67yM830aS5J3Q9LKEyXxQ==
X-Received: by 2002:a1c:2097:: with SMTP id g145mr1870014wmg.81.1550137905526;  Thu, 14 Feb 2019 01:51:45 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id c9sm1216707wrs.84.2019.02.14.01.51.44 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 01:51:44 -0800 (PST)
To: "perc@ietf.org" 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>  <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com> <417923aa-8771-863e-ee12-4107f674d918@gmail.com> <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com>
From: Sergio Garcia Murillo 
Message-ID: 
Date: Thu, 14 Feb 2019 10:56:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com>
Content-Type: multipart/alternative; boundary="------------8F5C067705F5CE55818ADDEE"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 09:51:54 -0000

This is a multi-part message in MIME format.
--------------8F5C067705F5CE55818ADDEE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 14/02/2019 4:51, Ben Campbell wrote:
> (+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.”

I have never said that there was a consensus around that.

> 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.

We don't know because the discussion has been prevented from even starting.


>
> Cullen: As the other join presenter, do you have thoughts?
>
> Thanks!
>
> Ben.
>
>> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo 
>> > > wrote:
>>
>> 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.
>>>
>>>> On Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo 
>>>> >>> > wrote:
>>>>
>>>> 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
>>>> https://datatracker.ietf.org/liaison/1614/
>>>>
>>>> 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).
>>>>> https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
>>>>>
>>>>> 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
>>>>> https://www.ietf.org/proceedings/96/minutes/minutes-96-perc
>>>>>
>>>>> At IETF 98 SSRC immutability and RTX considerations were discussed 
>>>>> but no proposal made on security implications
>>>>> https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00
>>>>>
>>>>> 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.
>>>>> https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01
>>>>> https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc
>>>>>
>>>>> Best regards
>>>>>  Nils & Suhas
>>>>>  PERC WG chairs
>>>>>
>>>>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo 
>>>>>> >>>>> > wrote:
>>>>>>
>>>>>> 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?
>>>>>>>>
>>>>>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo 
>>>>>>>> >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba 
>>>>>>>>>> > 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov
>>>>>>>>>>     > wrote:
>>>>>>>>>>
>>>>>>>>>>         Yes pretty much those.
>>>>>>>>>>
>>>>>>>>>>         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 Sat 2 Feb 2019 at 12:23, Bernard Aboba
>>>>>>>>>>         >>>>>>>>>         > wrote:
>>>>>>>>>>
>>>>>>>>>>             "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?
>>>>>>>>>>
>>>>>>>>>>             On Sat, Feb 2, 2019 at 5:40 AM Alexandre
>>>>>>>>>>             GOUAILLARD >>>>>>>>>             > wrote:
>>>>>>>>>>
>>>>>>>>>>                 +1 on ssrc rewriting, and on the consensus
>>>>>>>>>>                 not reached on this and other topics.
>>>>>>>>>>
>>>>>>>>>>                 Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>>                 On 2 Feb 2019, at 17:18, Lorenzo Miniero
>>>>>>>>>>                 >>>>>>>>>                 > wrote:
>>>>>>>>>>
>>>>>>>>>>>                 +1, SSRC rewriting is pretty much
>>>>>>>>>>>                 fundamental to all SFUs out there.
>>>>>>>>>>>
>>>>>>>>>>>                 Lorenzo
>>>>>>>>>>>
>>>>>>>>>>>                 Il 2 febbraio 2019 10:19:06 CET, Emil Ivov
>>>>>>>>>>>                 >
>>>>>>>>>>>                 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.
>>>>>>>>>>>
>>>>>>>>>>>                     On Sat 2 Feb 2019 at 06:21, Bernard
>>>>>>>>>>>                     Aboba >>>>>>>>>>                     > wrote:
>>>>>>>>>>>
>>>>>>>>>>>                         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 Fri, Feb 1, 2019 at 12:23 PM
>>>>>>>>>>>                         Sergio Garcia Murillo
>>>>>>>>>>>                         >>>>>>>>>>                         >
>>>>>>>>>>>                         wrote:
>>>>>>>>>>>
>>>>>>>>>>>                             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@ietf.org 
>>>>>>>>>>>                             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@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>>>>>
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> Perc@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/perc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>>
>


--------------8F5C067705F5CE55818ADDEE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 14/02/2019 4:51, Ben Campbell wrote:

    

    

      
      
(+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.” 

    

    
I have never said that there was a consensus around that.

    

      
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.

    

    
We don't know because the discussion has been prevented from even
      starting. 

    

    


    

    

      


      

      
Cullen: As the other join presenter, do you have
        thoughts?

      


      

      
Thanks!

      


      

      
Ben.

        


          

            
On Feb 13, 2019, at 2:49 PM, Sergio Garcia
              Murillo <sergio.garcia.murillo@gmail.com>
              wrote:

            

            

              
              

                
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.

                    


                      

                        
On Feb 13, 2019, at 4:53 AM,
                          Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
                          wrote:

                        

                        

                          
                          

                            
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

                            

                            
https://datatracker.ietf.org/liaison/1614/

                            

                            


                            

                            
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

                              


                                

                                  
On 2Feb, 2019, at 13:37,
                                    Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
                                    wrote:

                                  

                                  

                                    
                                    

                                      
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?

                                          


                                            On Feb 2, 2019, at 3:31 PM,
                                            Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
                                            wrote:

                                            

                                          

                                          

                                            

                                              
                                              
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:

                                              

                                              

                                                
                                                

                                                  


                                                  

                                                  


                                                  

                                                

                                                

                                                  
On Sat 2
                                                    Feb 2019 at 16:50,
                                                    Bernard Aboba <bernard.aboba@gmail.com>
                                                    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

                                                    


                                                    

                                                    


                                                    

                                                  

                                                

                                                

                                                  

                                                    

                                                      


                                                        

                                                          
On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov <emcho@jitsi.org>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Yes
                                                          pretty much
                                                          those.

                                                          

                                                          


                                                          

                                                          
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
                                                          Sat 2 Feb 2019
                                                          at 12:23,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
"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? 

                                                          

                                                          

                                                          

                                                          
On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD
                                                          <alex.gouaillard@cosmosoftware.io>
                                                          wrote:

                                                          

                                                          

                                                          
+1 on
                                                          ssrc
                                                          rewriting, and
                                                          on the
                                                          consensus not
                                                          reached on
                                                          this and other
                                                          topics.

                                                          

                                                          
Sent
                                                          from my iPhone

                                                          


                                                          On 2 Feb 2019,
                                                          at 17:18,
                                                          Lorenzo
                                                          Miniero <lorenzo@meetecho.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
+1,
                                                          SSRC rewriting
                                                          is pretty much
                                                          fundamental to
                                                          all SFUs out
                                                          there.

                                                          

                                                          Lorenzo

                                                          

                                                          
Il
                                                          2 febbraio
                                                          2019 10:19:06
                                                          CET, Emil Ivov
                                                          <emcho@jitsi.org>
                                                          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.

                                                          


                                                          

                                                          
On
                                                          Sat 2 Feb 2019
                                                          at 06:21,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo
                                                          <sergio.garcia.murillo@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
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@ietf.org

                                                          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@ietf.org
https://www.ietf.org/mailman/listinfo/perc


                                              

                                              


                                              

                                            

                                          

                                        

                                      

                                    

_______________________________________________

                                    Perc mailing list

                                    Perc@ietf.org

                                    https://www.ietf.org/mailman/listinfo/perc

                                  

                                

                              

                              

                            

                            


                            

                          

_______________________________________________

                          Perc mailing list

                          Perc@ietf.org

                          https://www.ietf.org/mailman/listinfo/perc

                        

                      

                    

                    

                  

                

                


                

              

            

          

        

        

      

    

    


    

  


--------------8F5C067705F5CE55818ADDEE--


From nobody Thu Feb 14 15:20:05 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC9D131249; Thu, 14 Feb 2019 15:19:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKkl0qauWD9I; Thu, 14 Feb 2019 15:19:52 -0800 (PST)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0353812F1A5; Thu, 14 Feb 2019 15:19:52 -0800 (PST)
Received: by mail-vk1-xa2b.google.com with SMTP id e131so1811759vkf.10; Thu, 14 Feb 2019 15:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uCEXu+KCEP4UMf50Jzp6WoPqrDEap8uMHWklEobRNjI=; b=AijcLakIWaw6N3YYdKl+DuH8oDHO8oR4ETq6uo+/EvJ8W0b2NPUfoWhAlhXLeh2G2q z158kk0yI4/ch45NfEcI3ZH1AtZfQQa5M/lq/HI2Iguyr0OJakDR21ORz89jj0hLS5V8 Aj16BVz1rCeQpJ8CfXLIYz202vbQvLzRZ66zS9nVOCk17Q6CCWdSWo7tmeqBSnMb+fT5 FE0RhInsbUqda6ac5AsZWZI3MLK9ag2+E9p2mMEhGAUB7bmtXWArDHJz/ejDQ8OVnrpe aB7nm57SSIQUewWo/smBlsjqCwGYhqOHDUbqR8nJvLw9zHteV7t2VbUXbdarJ6eVwH0H nzlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uCEXu+KCEP4UMf50Jzp6WoPqrDEap8uMHWklEobRNjI=; b=Z1lFO6v/W7GzOJpaEGnFFCgQoX2+x948F38+FtSg/XT1nnJNmr2P69xv0md/vVItk/ hfC7nYB9GFEMA7If3/s22nomK7EEWB0V4+zqCKbpfSwh3cQXJTsYYr9NZqqljdUTG/TC 3UTumVMEO2FuN1GV/DisiDrlPbVjjyvi7lKSU7NlGrQaXmNDhOrmEFrV82IKBc4tz04s Bn4m6jv9TPjOuqcBkHF/OLU7WwdfeZHbd680i8+FHwA8iusb8qOjPRycosGMMUxoxtXp ija2NWxj79d65NqOpINRZUqJfeh92iNEC3QcKRna9EPDAjFEwWnvpsTiCkftFNq+E8pN IyUw==
X-Gm-Message-State: AHQUAuZ4ukzp0V1O57B9sexGO9RPy6IrVu9eaUwcvz9keMohcmtNVNX3 a+8jprcyjOaR3BoOgxhlw1K14LBy/YSYPUdeNeM=
X-Google-Smtp-Source: AHgI3IY7q4F3baHeNZzmNK/neRhkNRce9mNxEUPR3GlZlJqyuXfM0LqfcNnTmC+C2QfI6waSBRFFec0m69lGDWxQnVc=
X-Received: by 2002:a1f:82ce:: with SMTP id e197mr3530800vkd.58.1550186390468;  Thu, 14 Feb 2019 15:19:50 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com> <753988DB-FC9A-4E8F-B495-347AD943B6C8@gmail.com> 
In-Reply-To: 
From: Bernard Aboba 
Date: Thu, 14 Feb 2019 15:19:40 -0800
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Nils Ohlmeier , Emil Ivov ,  IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD ,  Lorenzo Miniero 
Content-Type: multipart/alternative; boundary="00000000000023c22e0581e2e5eb"
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 23:19:59 -0000

--00000000000023c22e0581e2e5eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

"I don=E2=80=99t recall, and I don=E2=80=99t see anything in the notes or e=
mail consensus
call, that would suggest the consensus included anything along the lines
=E2=80=9Cit=E2=80=99s okay to let the js application have the media keys.=
=E2=80=9D

[BA] The PERC framework document only mentions that the endpoint is
trusted, but does not go into further detail.  That detail becomes
important when attempting to understand the provable security properties of
PERC (e.g. what attacks are prevented, what attacks are still allowed). As
an example, if the goal is not only to protect against access to cleartext
media within the MDD, but also the ability of endpoints to mis-use the
cleartext media (e.g. to create "deep fakes"), then it is necessary to
restrict access to cleartext media within the PERC application itself (e.g.
no ability to record or even modify cleartext media).  That goes beyond the
"no access to media keys in JS" dictum to "no access to cleartext media for
any PERC application, native or Web".  Once you've gone there, the
distinction between the problem solved by PERC and content protection
technologies begins to disappear.  Keep in mind though that technologies
such as EME are transport-independent - EME can be used when transporting
media over the SCTP data channel, for example.

On Wed, Feb 13, 2019 at 11:16 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>
>
> El jue., 14 feb. 2019 2:01, Bernard Aboba 
> escribi=C3=B3:
>
>> On Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <
>> sergio.garcia.murillo@gmail.com> wrote:
>>
>> All SFUs I am aware of performs SSRC rewriting, it is much more than
>> implementation convenience.
>>
>> [BA] In particular, reusing an SSRC for the =E2=80=9Cdominant speaker=E2=
=80=9D (which can
>> change)  is a common practice with switching of audio and video going
>> together.
>>
>
> would love to see how simulcast is expected to work without ssrc rewritin=
g
> (and without mid)
>
> Best regards
> Sergio
>
>>

--00000000000023c22e0581e2e5eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


"I don=E2=80=99t recall, and I don=E2=80=99t see anyt=
hing in the notes or email consensus call, that would suggest the consensus=
 included anything along the lines =E2=80=9Cit=E2=80=99s okay to let the js=
 application have the media keys.=E2=80=9D

[BA] The PERC=
 framework document only mentions that the endpoint is trusted, but does no=
t go into further detail.=C2=A0 That detail becomes important when attempti=
ng to understand the provable security properties of PERC (e.g. what attack=
s are prevented, what attacks are still allowed). As an example, if the goa=
l is not only to protect against access to cleartext media within the MDD, =
but also the ability of endpoints to mis-use the cleartext media (e.g. to c=
reate "deep fakes"), then it is necessary to restrict access to c=
leartext media within the PERC application itself (e.g. no ability to recor=
d or even modify cleartext media).=C2=A0 That goes beyond the "no acce=
ss to media keys in JS" dictum to "no access to cleartext media f=
or any PERC application, native or Web".=C2=A0 Once you've gone th=
ere, the distinction between the problem solved by PERC and content protect=
ion technologies begins to disappear.=C2=A0 Keep in mind though that techno=
logies such as EME are transport-independent - EME can be used when transpo=
rting media over the SCTP data channel, for example.=C2=A0

<=
div class=3D"gmail_quote">
On Wed, Feb=
 13, 2019 at 11:16 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:


El jue., 14 feb. 2019 2:01, Bernard Aboba <bernard.aboba@gm=
ail.com> escribi=C3=B3:
On=
 Feb 13, 2019, at 3:47 PM, Sergio Garcia Murillo <sergio.ga=
rcia.murillo@gmail.com> wrote:

    
All SFUs I am aware of performs SSRC rewriting, it is much more
      than implementation convenience.
[BA] In partic=
ular, reusing an SSRC for the =E2=80=9Cdominant speaker=E2=80=9D (which can=
 change) =C2=A0is a common practice with switching of audio and video going=
 together.

would love to see how simulcast is expected to work without ssrc =
rewriting (and without mid)

Best regards=C2=A0
Sergio



--00000000000023c22e0581e2e5eb--


From nobody Thu Feb 14 15:48:31 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ABD12F1A6; Thu, 14 Feb 2019 15:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dioNYYfc14p; Thu, 14 Feb 2019 15:48:20 -0800 (PST)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E841128B36; Thu, 14 Feb 2019 15:48:20 -0800 (PST)
Received: by mail-wm1-x342.google.com with SMTP id a62so8180868wmh.4; Thu, 14 Feb 2019 15:48:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KoY4DCLboLakUxPFN70nL/AcW8bYbwpkDT1ijv3KYZM=; b=CISKcp55mZ3wWRFJR3VKEJV2Dx1MSP+Wi6ABjnBzVVY7vNWyZEB8b9SKYAk6CQKAci PF/GidWWNI/WMzKSGD/DXcb8cEPvB/h84/3A/Hb7YQo9wtrbZgRyKVgRJrykHuiHd2HV iFVjM6OEUEiPF8Wo4gNhI2XC0AlUF6/ReOXBnuwHd2kTDdFtoIr4LxTpPd6NIfpGhp2M XWgCitQ8bS2VrwokUuAQRlrRVpLy9+L83nfHOH5Z1eoGWJ4A0D/7XvD+MFxl0Ruoi8Hm lsNZq0JypKus5k0eqhzFegE9cOHLkOtB+eH/0IwCQHLw1wt07xMUDt9OxC/nPRkLzzu6 rnOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KoY4DCLboLakUxPFN70nL/AcW8bYbwpkDT1ijv3KYZM=; b=VYWDer23X0jRj5L+86s7B0mcoqQqRR0Lh6z1taPDJld/X+FYLB1qq9vjUtUShTfuwV DuWvMVfVsA+3fYdNL+RDgb2ka24YA7PgVgJWCitCVBc9Llv1CmORLqVTisbA/G+DgcFs 4EbtTDQQhJP3yOZfJ3ZbR55ChXJSbSlIUe6BmiG9OVU0LJa5txZ6PoUncDurmFQDj711 yOwQL77cGRgv8CzaSYBqyQeNR88cXW8zhyp5slmz5Qx4HcyL1u8wxEJdInF/E/4RKGn+ IGLhgrCo61r7PYVKVd2Ssu/9DQqL6j0C9G7ozP7qpGNhRMT/fRj/J13o0PvpkacfoT6D w7Hw==
X-Gm-Message-State: AHQUAuYkpKVcXS3J0GFSe17Jxx6WVthIanWGfNxMBxMucwS7pMeYLRFa BFUGIkTClSwY7nruezqpWl8=
X-Google-Smtp-Source: AHgI3IYhm8X/8RIeffXLsY2Vf/Qnr4M4gYmOg9khD8YsCshe+i2zA3DTQnJSAHq9Ds6GnD5P1NIB3Q==
X-Received: by 2002:a1c:b1d5:: with SMTP id a204mr4615010wmf.32.1550188098838;  Thu, 14 Feb 2019 15:48:18 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id 2sm7421207wrj.27.2019.02.14.15.48.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 15:48:18 -0800 (PST)
To: Bernard Aboba 
Cc: Nils Ohlmeier , Emil Ivov , IETF discussion list , Emad Omara , perc@ietf.org, "hta@google.com" , Alexandre GOUAILLARD , Lorenzo Miniero 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>      <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <2807c153-60ba-a741-f0ad-72c98d8d77bb@gmail.com> <753988DB-FC9A-4E8F-B495-347AD943B6C8@gmail.com>  
From: Sergio Garcia Murillo 
Message-ID: 
Date: Fri, 15 Feb 2019 00:53:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 23:48:23 -0000

On 15/02/2019 0:19, Bernard Aboba wrote:
> "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.”
>
> [BA] The PERC framework document only mentions that the endpoint is 
> trusted, but does not go into further detail.  That detail becomes 
> important when attempting to understand the provable security 
> properties of PERC (e.g. what attacks are prevented, what attacks are 
> still allowed). As an example, if the goal is not only to protect 
> against access to cleartext media within the MDD, but also the ability 
> of endpoints to mis-use the cleartext media (e.g. to create "deep 
> fakes"), then it is necessary to restrict access to cleartext media 
> within the PERC application itself (e.g. no ability to record or even 
> modify cleartext media).  That goes beyond the "no access to media 
> keys in JS" dictum to "no access to cleartext media for any PERC 
> application, native or Web".  Once you've gone there, the distinction 
> between the problem solved by PERC and content protection technologies 
> begins to disappear.  Keep in mind though that technologies such as 
> EME are transport-independent - EME can be used when transporting 
> media over the SCTP data channel, for example.

Indeed. Any true end to end encryption for webrtc that must be 
integrated with IdP and isolated media streams IMHO.

Best regards

Sergio



From nobody Thu Feb 14 20:27:44 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2E13122A for ; Thu, 14 Feb 2019 15:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5OA1PWSVOAG for ; Thu, 14 Feb 2019 15:05:57 -0800 (PST)
Received: from smtp117.iad3a.emailsrvr.com (smtp117.iad3a.emailsrvr.com [173.203.187.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C1313122B for ; Thu, 14 Feb 2019 15:05:55 -0800 (PST)
Received: from smtp7.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6818F274E; Thu, 14 Feb 2019 18:05:54 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B99C251C9;  Thu, 14 Feb 2019 18:05:52 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 14 Feb 2019 18:05:54 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_989C5335-5C34-4CC6-85BA-E1FC7268081B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Cullen Jennings 
In-Reply-To: <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com>
Date: Thu, 14 Feb 2019 16:05:51 -0700
Cc: Sergio Garcia Murillo , Nils Ohlmeier , IETF Crazy , Emad Omara , Emil Ivov , perc@ietf.org, Harald Alvestrand , Alexandre GOUAILLARD , Lorenzo Miniero , Bernard Aboba 
Message-Id: <88F12D70-CE7F-48FB-9F32-7827091E3768@iii.ca>
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com> <417923aa-8771-863e-ee12-4107f674d918@gmail.com> <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Feb 2019 20:27:42 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 23:06:03 -0000

--Apple-Mail=_989C5335-5C34-4CC6-85BA-E1FC7268081B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


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 =E2=80=A6 but let me =
comment on the =E2=80=9CJS access to media keys=E2=80=9D issue.=20

"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 =
 )=20

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.=20

Bit more inline =E2=80=A6=20




> On Feb 13, 2019, at 8:51 PM, Ben Campbell  wrote:
>=20
> (+Cullen)
> (as individual)
>=20
> Hi Sergio,
>=20
> I don=E2=80=99t recall, and I don=E2=80=99t see anything in the notes =
or email consensus call, that would suggest the consensus included =
anything along the lines =E2=80=9Cit=E2=80=99s okay to let the js =
application have the media keys.=E2=80=9D That is, even if the idea was =
to let PERC do it=E2=80=99s thing and let other groups spin their own =
key management systems, I don=E2=80=99t think there=E2=80=99s a =
consensus that everyone would be okay with that particular approach.
>=20
> 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).=20

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.


>=20
> Thanks!
>=20
> Ben.
>=20
>> On Feb 13, 2019, at 2:49 PM, Sergio Garcia Murillo =
> wrote:
>>=20
>> Hi Ben,
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> Best regards
>> Sergio
>>=20
>>=20
>>=20
>> On 13/02/2019 21:21, Ben Campbell wrote:
>>> (as individual)
>>>=20
>>> Hi Sergio,
>>>=20
>>> 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?
>>>=20
>>> Thanks!
>>>=20
>>> Ben.
>>>=20
>>>> On Feb 13, 2019, at 4:53 AM, Sergio Garcia Murillo =
> wrote:
>>>>=20
>>>> You are missing an important piece on the timeline:
>>>>=20
>>>> Statement from the IETF ART and SEC Area Directors regarding the =
"Trusted application, untrusted intermediary" use case
>>>> https://datatracker.ietf.org/liaison/1614/ =

>>>>=20
>>>> 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.
>>>>=20
>>>> Best regards
>>>> Sergio
>>>>=20
>>>> On 13/02/2019 2:34, Nils Ohlmeier wrote:
>>>>> Thank you for the input on the framework and the double documents =
from everyone.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>> 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).
>>>>>   https://www.ietf.org/proceedings/95/minutes/minutes-95-perc =

>>>>> =20
>>>>> 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
>>>>>   https://www.ietf.org/proceedings/96/minutes/minutes-96-perc =

>>>>> At IETF 98 SSRC immutability and RTX considerations were discussed =
but no proposal made on security implications
>>>>>   https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 =

>>>>> 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.
>>>>>   =
https://datatracker.ietf.org/meeting/99/materials/minutes-99-perc-01 =

>>>>>   =
https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7wkf4-bc =

>>>>> Best regards
>>>>>   Nils & Suhas
>>>>>   PERC WG chairs
>>>>>=20
>>>>>> On 2Feb, 2019, at 13:37, Sergio Garcia Murillo =
> wrote:
>>>>>>=20
>>>>>> PERC may be a valid solution for some scenarios, maybe SIP.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Best regards
>>>>>>=20
>>>>>> Sergio
>>>>>>>=20
>>>>>>> On 02/02/2019 21:42, Bernard Aboba wrote:
>>>>>>>> Sergio -
>>>>>>>>=20
>>>>>>>> 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?
>>>>>>>>=20
>>>>>>>> On Feb 2, 2019, at 3:31 PM, Sergio Garcia Murillo =
> wrote:
>>>>>>>>=20
>>>>>>>>> I think Emil and Bernard have described quite precisely where =
we are and how we managed to get here.
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> Best regards
>>>>>>>>> Sergio
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 02/02/2019 18:42, Emil Ivov wrote:
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Sat 2 Feb 2019 at 16:50, Bernard Aboba =
> wrote:
>>>>>>>>>> Emil said:
>>>>>>>>>>=20
>>>>>>>>>> "The need to do a triple encryption for example is a =
particularly egregious consequence of the order problem. That=E2=80=99s =
a problem specific to the =E2=80=9Cdouble=E2=80=9D documents."
>>>>>>>>>>=20
>>>>>>>>>> [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".=20
>>>>>>>>>>=20
>>>>>>>>>> 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.=20
>>>>>>>>>>=20
>>>>>>>>>> I don=E2=80=99t know that this goal is a direct consequence =
of the framework=E2=80=99s 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.
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> This approach was referred to as =E2=80=9Cwedging RTX and =
FEC=E2=80=9D as it places them in between the two encryption operations.
>>>>>>>>>>=20
>>>>>>>>>> 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:
>>>>>>>>>>=20
>>>>>>>>>> Applications will apply SRTP-double first and, those that =
need to use FEC and RTX would have to apply them only after.=20
>>>>>>>>>>=20
>>>>>>>>>> It was quickly pointed out that this not only destroys the =
stated =E2=80=9Cdon=E2=80=99t-change-the-app=E2=80=9D 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: =
=E2=80=9Cwell, those of you who use FEC/RTX will simply do a third round =
of SRTP=E2=80=9D, thus arriving at a total of three encryptions for =
every packet..
>>>>>>>>>>=20
>>>>>>>>>> The discussions around this topic were highly contentious.
>>>>>>>>>>=20
>>>>>>>>>> Hope this makes things clear,
>>>>>>>>>> Emil
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Sat, Feb 2, 2019 at 11:46 AM Emil Ivov > wrote:
>>>>>>>>>> Yes pretty much those.
>>>>>>>>>>=20
>>>>>>>>>> The need to do a triple encryption for example is a =
particularly egregious consequence of the order problem. That=E2=80=99s =
a problem specific to the =E2=80=9Cdouble=E2=80=9D documents.
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> Emil
>>>>>>>>>>=20
>>>>>>>>>> On Sat 2 Feb 2019 at 12:23, Bernard Aboba =
> wrote:
>>>>>>>>>> "on the consensus not reached on this and other topics."
>>>>>>>>>>=20
>>>>>>>>>> [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:
>>>>>>>>>>=20
>>>>>>>>>> * Order of application of encryption versus FEC/RTX/RED
>>>>>>>>>> * Whole frame encryption versus payload encryption
>>>>>>>>>>=20
>>>>>>>>>> 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?=20
>>>>>>>>>>=20
>>>>>>>>>> On Sat, Feb 2, 2019 at 5:40 AM Alexandre GOUAILLARD =
> wrote:
>>>>>>>>>> +1 on ssrc rewriting, and on the consensus not reached on =
this and other topics.
>>>>>>>>>>=20
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>=20
>>>>>>>>>> On 2 Feb 2019, at 17:18, Lorenzo Miniero =
> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> +1, SSRC rewriting is pretty much fundamental to all SFUs =
out there.
>>>>>>>>>>>=20
>>>>>>>>>>> Lorenzo
>>>>>>>>>>>=20
>>>>>>>>>>> Il 2 febbraio 2019 10:19:06 CET, Emil Ivov > 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.
>>>>>>>>>>>=20
>>>>>>>>>>> I am also not sure that I agree with =E2=80=9CSSRC rewriting =
could not be allowed=E2=80=9D is a conclusion that ever had any =
consensus in PERC, regardless of what WG leadership is trying to make =
everyone believe.
>>>>>>>>>>>=20
>>>>>>>>>>> On Sat 2 Feb 2019 at 06:21, Bernard Aboba =
> wrote:
>>>>>>>>>>> Richard said:
>>>>>>>>>>>=20
>>>>>>>>>>> "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."
>>>>>>>>>>>=20
>>>>>>>>>>> [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?=20
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia Murillo =
> wrote:
>>>>>>>>>>> On 01/02/2019 17:18, Richard Barnes wrote:
>>>>>>>>>>>> So I would propose we add something like the following to =
this definition:=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> "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).
>>>>>>>>>>>=20
>>>>>>>>>>> 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 ?
>>>>>>>>>>>=20
>>>>>>>>>>>    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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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:
>>>>>>>>>>>=20
>>>>>>>>>>> =
https://github.com/WICG/media-capabilities/blob/master/explainer.md#encryp=
tion =

>>>>>>>>>>> Best regards
>>>>>>>>>>>=20
>>>>>>>>>>> Sergio
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Perc mailing list
>>>>>>>>>>> Perc@ietf.org 
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>>>>>> --=20
>>>>>>>>>>> sent from my mobile
>>>>>>>>>>>=20
>>>>>>>>>>> --=20
>>>>>>>>>>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate =
la brevit=C3=A0.
>>>>>>>>>> --=20
>>>>>>>>>> sent from my mobile
>>>>>>>>>> --=20
>>>>>>>>>> sent from my mobile
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Perc mailing list
>>>>>>>>>> Perc@ietf.org 
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Perc mailing list
>>>>>> Perc@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/perc =

>>>=20
>>=20
>=20


--Apple-Mail=_989C5335-5C34-4CC6-85BA-E1FC7268081B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



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 =E2=80=A6 but let me comment on the =E2=80=9CJS access to media =
keys=E2=80=9D 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 =
=E2=80=A6 




On Feb 13, 2019, at 8:51 PM, Ben Campbell <ben@nostrum.com> =
wrote:

(+Cullen)
(as individual)

Hi Sergio,

I don=E2=80=99t recall, and I don=E2=80=99=
t see anything in the notes or email consensus call, that would suggest =
the consensus included anything along the lines =E2=80=9Cit=E2=80=99s =
okay to let the js application have the media keys.=E2=80=9D That is, =
even if the idea was to let PERC do it=E2=80=99s thing and let other =
groups spin their own key management systems, I don=E2=80=99t think =
there=E2=80=99s 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.

On Feb 13, 2019, at 2:49 PM, =
Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:


 =20
    
 =20
  

    
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.

        


          

            
On Feb 13, 2019, at 4:53 AM, Sergio Garcia
              Murillo <sergio.garcia.murillo@gmail.com>
              wrote:

            

            

              
              

                
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

                

                
https://datatracker.ietf.org/liaison/1614/
                

                


                

                
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).

                  
 =
 https://www.ietf.org/proceedings/95/minutes/minutes-95-perc
 

                  
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

                  
 =
 https://www.ietf.org/proceedings/96/minutes/minutes-96-perc

                  

                  
At IETF 98 =
SSRC immutability and RTX considerations were discussed but no proposal =
made on security implications

                  
 =
 https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00<=
/span>

                  

                  
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.

                  
 =
 https://datatracker.ietf.org/meeting/99/materials/minutes-99-pe=
rc-01

                  
 =
 https://mailarchive.ietf.org/arch/msg/perc/3fPqYTE2qhT351nvp1b7=
wkf4-bc

                  

                  
Best =
regards

                  
  Nils =
& Suhas

                  
  PERC =
WG chairs

                  


                    

                      
On 2Feb, 2019, at 13:37, Sergio
                        Garcia Murillo <sergio.garcia.murillo@gmail.com>
                        wrote:

                      

                      

                        
                        
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?

                              


                                On Feb 2, 2019, at 3:31 PM, Sergio
                                Garcia Murillo <sergio.garcia.murillo@gmail.com>
                                wrote:

                                

                              

                              

                                

                                  
                                  
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:

                                  

                                  

                                    
                                    

                                      


                                      

                                      


                                      

                                    

                                    

                                      
On Sat =
2
                                        Feb 2019 at 16:50, Bernard Aboba
                                        <bernard.aboba@gmail.com>
                                        wrote:

                                      

                                      

                                        
Emil
                                          said:
                                          


                                          

                                          
"The need to =
do
                                            a triple encryption for
                                            example is a particularly
                                            egregious consequence of the
                                            order problem. That=E2=80=99s =
a
                                            problem specific to the
                                            =E2=80=9Cdouble=E2=80=9D =
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=E2=80=99t
                                          know that this goal is a
                                          direct consequence of the
                                          framework=E2=80=99s 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
                                          =E2=80=9Cwedging RTX and =
FEC=E2=80=9D 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
                                          =E2=80=9Cdon=E2=80=99t-change-th=
e-app=E2=80=9D 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:
                                          =E2=80=9Cwell, those of you =
who use
                                          FEC/RTX will simply do a third
                                          round of SRTP=E2=80=9D, 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

                                        


                                        

                                        


                                        

                                      

                                    

                                    

                                      

                                        

                                          


                                            

                                              
On
                                                Sat, Feb 2, 2019 at
                                                11:46 AM Emil Ivov =
<emcho@jitsi.org>
                                                wrote:

                                              

                                              

                                                

                                                  
Yes pretty
                                                    much those.

                                                

                                                


                                                

                                                
The
                                                  need to do a triple
                                                  encryption for example
                                                  is a particularly
                                                  egregious consequence
                                                  of the order problem.
                                                  That=E2=80=99s a =
problem
                                                  specific to the
                                                  =E2=80=9Cdouble=E2=80=9D=
 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 Sat 2
                                                      Feb 2019 at 12:23,
                                                      Bernard Aboba =
<bernard.aboba@gmail.com>
                                                      wrote:

                                                    

                                                    

                                                      
"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? 

                                                      

                                                      

                                                      

                                                        
On
                                                          Sat, Feb 2,
                                                          2019 at 5:40
                                                          AM Alexandre
                                                          GOUAILLARD
                                                          <alex.gouaillard@cosmosoftware.io>
                                                          wrote:

                                                        

                                                        

                                                          
+1 on
                                                          ssrc
                                                          rewriting, and
                                                          on the
                                                          consensus not
                                                          reached on
                                                          this and other
                                                          topics.

                                                          

                                                          
Sent
                                                          from my =
iPhone

                                                          


                                                          On 2 Feb 2019,
                                                          at 17:18,
                                                          Lorenzo
                                                          Miniero <lorenzo@meetecho.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
+1,
                                                          SSRC rewriting
                                                          is pretty much
                                                          fundamental to
                                                          all SFUs out
                                                          there.

                                                          

                                                          Lorenzo

                                                          

                                                          
Il
                                                          2 febbraio
                                                          2019 10:19:06
                                                          CET, Emil Ivov
                                                          <emcho@jitsi.org>
                                                          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 =E2=80=9CSS=
RC
                                                          rewriting
                                                          could not be
                                                          allowed=E2=80=9D=
 is a
                                                          conclusion
                                                          that ever had
                                                          any consensus
                                                          in PERC,
                                                          regardless of
                                                          what WG
                                                          leadership is
                                                          trying to make
                                                          everyone
                                                          believe.

                                                          


                                                          

                                                          
On
                                                          Sat 2 Feb 2019
                                                          at 06:21,
                                                          Bernard Aboba
                                                          <bernard.aboba@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
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 Fri, Feb 1, 2019 at 12:23 PM Sergio Garcia =
Murillo
                                                          <sergio.garcia.murillo@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
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-sec=
urity-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/m=
aster/explainer.md#encryption

                                                          
Best
                                                          regards
Sergio

                                                          

                                                          

_______________________________________________

                                                          Perc mailing
                                                          list

                                                          Perc@ietf.org

                                                          https://www.ietf.org/mailman/listinfo/perc

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          -- 

                                                          
s=
ent
                                                          from my =
mobile

                                                          

                                                          

                                                          

                                                          -- 

                                                          Inviato dal
                                                          mio
                                                          dispositivo
                                                          Android con
                                                          K-9 Mail.
                                                          Perdonate la
                                                          =
brevit=C3=A0.

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                                -- 

                                                
sent
                                                  from my mobile

                                              

                                            

                                          

                                        

                                      

                                    

                                    -- 

                                    
sent
                                      from my mobile

                                    

                                    

                                    
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


                                  


                                  

                                

                              

                            

                          

                        

                        =
_______________________________________________

                        Perc mailing list

                        Perc@ietf.org

                        https://www.ietf.org/mailman/listinfo/perc
                      

                    

                  

                  

                


                

              

              _______________________________________________

              Perc mailing list

              Perc@ietf.org

              https://www.ietf.org/m=
ailman/listinfo/perc

            

          

        

        

      

    


    

  





=

--Apple-Mail=_989C5335-5C34-4CC6-85BA-E1FC7268081B--


From nobody Thu Feb 14 20:27:51 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7093A131053 for ; Thu, 14 Feb 2019 15:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6VlvU_3rXnH for ; Thu, 14 Feb 2019 15:10:55 -0800 (PST)
Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2404312F1A5 for ; Thu, 14 Feb 2019 15:10:54 -0800 (PST)
Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0C1A824C39; Thu, 14 Feb 2019 18:10:54 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1479024BB7;  Thu, 14 Feb 2019 18:10:52 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 14 Feb 2019 18:10:53 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Cullen Jennings 
In-Reply-To: <8136dee9-74c9-8ac1-3cb8-f18f08b1ff3b@gmail.com>
Date: Thu, 14 Feb 2019 16:10:51 -0700
Cc: Nils Ohlmeier , Emil Ivov , IETF Crazy , Emad Omara , perc@ietf.org, Harald Alvestrand , Alexandre GOUAILLARD , Lorenzo Miniero , Bernard Aboba 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com>  <1F1100AC-B9D2-4650-8663-A6D380721688@mozilla.com> <8136dee9-74c9-8ac1-3cb8-f18f08b1ff3b@gmail.com>
To: Sergio Garcia Murillo 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Feb 2019 20:27:42 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 23:10:56 -0000

> On Feb 13, 2019, at 5:03 PM, Sergio Garcia Murillo =
 wrote:
>=20
> On 13/02/2019 23:48, Nils Ohlmeier wrote:
>> While implementation convenience was part of the discussion it was =
raised a few times that the people in favor of allowing SSRC mutability =
never provided any written description of why mutating the SSRC is not a =
problem as pointed out by the design team.
>>=20
> Moreover, in the (maybe not so) near future of ssrc-less signaling (at =
least in webrtc), where the MID extensions are HBH, how would ssrc =
rewriting even be a potential risk?
>=20
> Has this group analyzed the implications and new attacks that this may =
cause?
>=20
> Best regards
>=20
> Sergio


I know you understand this stuff too well to really believe what you =
just wrote so it comes across as feeling like FUD. You know that most =
WebRTC does not use any SSRC in the signaling at all and the WebRTC =
security dose not change if the ssrc are signaled or not.=20

Has it been analyzed? YES OF COURSE IT HAS - the whole of webrtc =
security drafts and security section of of the related WebRTC drafts are =
written based on the security being ssrc-less signaling.=20=


From nobody Thu Feb 14 20:27:56 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A4B12F295 for ; Thu, 14 Feb 2019 15:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5riqfAgvCbU for ; Thu, 14 Feb 2019 15:54:58 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5891512F1A6 for ; Thu, 14 Feb 2019 15:54:58 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id v10so9015047qtp.8 for ; Thu, 14 Feb 2019 15:54:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iYjj/nMwy+6XdXHZShSV+tLK7oJ3GufN6V7M/Lh11E0=; b=vvu34wjxA0s5P050k+3NPq/tqQyabyJoQnQgKoyYFDZda63OYqFiIMn3FY9UojG+Rs dOloHdx05VY4UuFXqi/t5qKXKI5//o4Ja+efz8txV08ES098UoUrnF3E/OLkS+sle6mt ar3pD5xXXjLWIr52VsGbSNSr0oRhV7MXHNa19C6FqLXIeKRjuzILEzwgeXiCP4O1WzNY YgUItmTdVu4Nb956WIq1MLqkDN1GOVUmOxlbTUy9OS4LfOPApryVsvru52YCKcS4O/4o MI9tacHQcgYL7+wY6uve1ZaoaWQy6+FhopjWyZO7zi3EEhtTcF6k2XeL5CS7Uhv/JPNA spPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iYjj/nMwy+6XdXHZShSV+tLK7oJ3GufN6V7M/Lh11E0=; b=jc0QYHYMvYfd1CuftlRytmZ/fP7IU87A4qTQuffR590fAV+ZPjyrsQagi9bGMv2F4z ohu7h0+RWv7nmlDrGD+wSEfEdXPZ0KXmbResO+H+mgzkOlfu3ZKrv/AefEeRp3XE1JYD I89JC57XoW+OgUpJsLLiNFi6k2rJV3mcF7WjzMyFhINh6qtCB8vhkmk5h7qOgu/v1Qo2 yOmb8nceZtrUDRRVBv0vBKVkfoKwt91zjVnEYYdmpDn7e5gNrV88tTqsHt58r+tR/7RB aNkcM2leOd+cX7CqgsBd1Cc4lmZdIm6YpvLgkhP484Cn3twq8s2BJmlLCN1ub78DUlhm obhw==
X-Gm-Message-State: AHQUAuaRTU4I9lXC60FJ3EY2QnM1q1901bbbnHvOgp/nRtpMNBUjqWgY Q0csAFu7ThCHlx134oZ6K5do7SfEBGP9W2bMrMCdqg==
X-Google-Smtp-Source: AHgI3IbXYi2Vmu5jLJJVIBmzhvBjJvx/blb6kqUffkMxhRLq/H3ZYTe/68Gi+j37/I1mTnHYAglsBsP8+SD0gNM6Cf4=
X-Received: by 2002:a0c:98c9:: with SMTP id g9mr5098712qvd.150.1550188497026;  Thu, 14 Feb 2019 15:54:57 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com> <417923aa-8771-863e-ee12-4107f674d918@gmail.com> <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com> <88F12D70-CE7F-48FB-9F32-7827091E3768@iii.ca>
In-Reply-To: <88F12D70-CE7F-48FB-9F32-7827091E3768@iii.ca>
From: Emil Ivov 
Date: Thu, 14 Feb 2019 23:54:43 +0000
Message-ID: 
To: Cullen Jennings 
Cc: Ben Campbell ,  Sergio Garcia Murillo , Nils Ohlmeier ,  IETF Crazy , Emad Omara , perc@ietf.org,  Harald Alvestrand , Alexandre GOUAILLARD ,  Lorenzo Miniero , Bernard Aboba 
Content-Type: multipart/alternative; boundary="000000000000b3610d0581e362b7"
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Feb 2019 20:27:41 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2019 23:55:01 -0000

--000000000000b3610d0581e362b7
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 14, 2019 at 5:05 PM Cullen Jennings  wrote:

>
> Mostly I view this thread as the same set of people that failed to get
> consensus in the WG trying to reopen
>

Aha! I am glad we agree on the lack of consensus in the  WG! I feel that we
are making progress here! All hope is not lost! ;)

issues that was clearly not consensus for
>

Agreed again!

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.
>

Now this bit here is somewhat vexing. Of course I am sure it is entirely
unintentional so let me just correct this:  "Before the meeting, Emil
decided he did not support it" is quite an, obviously accidental but still,
misrepresentation of reality!

You had discussions with people. I was not an active part of them. You put
my name on a slide of "supporters" and you were about to present to that to
the WG. I saw that and asked you to remove my name. Please do not imply
sudden whimsical changes of positions.

Next time my support is important to you, please simply reach out and I'd
be happy to hear you out.

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).
>

Ah! That "splicing attack"! You often refer to it and have yet to explain
it ... I am confident that you only mean well of course, and promise that,
as soon as you provide details, we will come back with explanations and
security considerations on how to protect against the specific vectors that
concern you.

My very best regards!
Emil

--000000000000b3610d0581e362b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Feb 14, 2019 at 5:05 PM Culle=
n Jennings <fluffy@iii.ca> wrote=
:

Mostly I view this thread as the=
 same set of people that failed to get consensus in the WG trying to reopen=
 

Aha! I am glad we agree on the lack=
 of consensus in the=C2=A0 WG! I feel that we are making progress here! All=
 hope is not lost! ;)

issues that was =
clearly not consensus for 

Agreed aga=
in!

<=
div style=3D"overflow-wrap: break-word;">
Mostly the agreemen=
t was we would the way EKT and double was done breaking all the existing im=
plementation if Sergio and Emil agreed they would support that approach.=C2=
=A0 Before the meeting, Emil decided he did not support it which made the m=
any of us regret making the breaking changes. 

Now this bit here is somewhat vexing. Of course=
 I am sure it is entirely unintentional so let me just correct this:=C2=A0 =
"Before the meeting, Emil decided he did not support it" is quite=
 an, obviously accidental but still, misrepresentation of reality!=C2=A0

You had discussions with people. I was not an active=
 part of them. You put my name on a slide of "supporters" and you=
 were about to present to that to the WG. I saw that and asked you to remov=
e my name. Please do not imply sudden whimsical changes of positions.
=


Next time my support is important to you, please simply=
 reach out and I'd be happy to hear you out.

We were hoping to find a way to move forward with=
out 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 se=
curity requirements and issues that had been raised (such as the splicing a=
ttack).=C2=A0

Ah!=
=C2=A0That "splicing attack"! You often refer to it and have yet =
to explain it ... I am confident that you only mean well of course, and pro=
mise that, as soon as you provide details, we will come back with explanati=
ons and security considerations on how to protect against the specific vect=
ors that concern you.

My very best regards!
<=
div>Emil


--000000000000b3610d0581e362b7--


From nobody Thu Feb 14 20:28:02 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260AC130DC0 for ; Thu, 14 Feb 2019 16:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cosmosoftware-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyKlwg84QMWs for ; Thu, 14 Feb 2019 16:00:59 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8A7128B36 for ; Thu, 14 Feb 2019 16:00:59 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id 32so13630810ota.12 for ; Thu, 14 Feb 2019 16:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R3vo/PG9d1FbVOJEsLKDE+tH5h3zbTY8bJc8mzZGDpk=; b=EPCkICCOIqNnWkk/o45ruQvTjJqROJmxXlQrus9F5/roQCjnzDnEaKDLP+kQnwKOvl AY40r7izX7PR1sSKrudOxttBMd8MY3gIePeyRHu2Yx/a2BL7sO+5G3gUtZz4M4q8//+d zs/r4LYc4LH6pF2vqWzSAEntcy43/SBoIiQbvFKq3iGOeJkH4Fpvh5iJLDbLO8v57FbL fEFG/zAPjkZv0YvwaRMc/UHxy92hOaVEM+XfjXZpCjLpniAO0fVqAXAZFZ4JDkBkp7+S ZpRsCktl5Z4qSSE33BFrMGRG3izvouXQ+a1d2rcAgXBpe5NoL6zcLXm7IFfn2h1IMsy/ YEwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R3vo/PG9d1FbVOJEsLKDE+tH5h3zbTY8bJc8mzZGDpk=; b=GYRBUuO7BsOpE/ifEx2HdJYqnLzMN6tkX7rmBU50rt8G3Dcra7xt3WG3yhb/zgN9FS DZvXyBfDtSixR9vADoibOr/FLr/kwgbtpfBYi6V/mW24ZeMaEMuDhOnsZrf3VUkacpSq pUXYAQq4hAr6gELVaNto8fpSgXD+n8aOiY5WVGyOuAbZeYzNRehvE05FJaqMR0IfxhOy 5njWVlun9DOGzQhKf53BOfgrm5ABfd36rEGN/K9bF2+hPPnkJ3Bk/9cF64E2u/hB9+ju wpgKgpZwjsS9DLMDrGCuacmJ/SPWHG9yPlIrOa/XG7dP1x2IsOUDTZAIJ6dRyvlzgjzS VTqQ==
X-Gm-Message-State: AHQUAuZJ7sRT7bL3pMsmq+DYzOvdiR0yEpS2TuTIVKS8olyRIKETjxre 6Do77YJTftD0J43KKZ4ynf1Kj91Auul2HKyz+b/JPw==
X-Google-Smtp-Source: AHgI3Ia118N/GVfKR/5qJx2ctSj02dJcCODWj/Y8HoXJSa/RerlYj5TtHGEcL/OfWq3+FH5LNpJsDC5DPgtfmAMNaM0=
X-Received: by 2002:a9d:3665:: with SMTP id w92mr4229830otb.262.1550188858194;  Thu, 14 Feb 2019 16:00:58 -0800 (PST)
MIME-Version: 1.0
References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com>   <5486C91C-48EA-4AA1-85EE-05A0B01C1E70@meetecho.com>       <543375ED-9A4F-452C-AE51-9499DAD5CEE0@gmail.com> <80a1f634-0888-c5e2-f6be-729d4cca3b28@cosmosoftware.io> <06d91175-b071-49fe-01cc-4a1323ad85f7@gmail.com> <91A16283-A392-4217-97E1-B04A5C8AD245@mozilla.com> <9c4149c0-184b-5ee9-e0a4-2b41420d3279@gmail.com> <37143A53-81C3-4391-998E-D7F2AD1F409C@nostrum.com> <417923aa-8771-863e-ee12-4107f674d918@gmail.com> <4CBF52C0-1D9F-4576-85B6-4F24F59CB3E6@nostrum.com> <88F12D70-CE7F-48FB-9F32-7827091E3768@iii.ca> 
In-Reply-To: 
From: Alexandre GOUAILLARD 
Date: Fri, 15 Feb 2019 08:00:46 +0800
Message-ID: 
To: Emil Ivov 
Cc: Cullen Jennings , Ben Campbell ,  Sergio Garcia Murillo , Nils Ohlmeier ,  IETF Crazy , Emad Omara , perc@ietf.org,  Harald Alvestrand , Lorenzo Miniero ,  Bernard Aboba 
Content-Type: multipart/alternative; boundary="0000000000003a53f60581e3782d"
Archived-At: 
X-Mailman-Approved-At: Thu, 14 Feb 2019 20:27:41 -0800
Subject: Re: [Perc] Last Call:  (A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing) to Proposed Standard
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2019 00:01:01 -0000

--0000000000003a53f60581e3782d
Content-Type: text/plain; charset="UTF-8"

I do not agree with everything culled say, but still,
I wanted to say something for his defence on his point where i think he is
being given credits for my mistake.

You had discussions with people. I was not an active part of them. You put
> my name on a slide of "supporters" and you were about to present to that to
> the WG. I saw that and asked you to remove my name. Please do not imply
> sudden whimsical changes of positions.
>

I am the culprit for bringing your name in at IETF 99. Sergio and I spoke
with cullen to try to find a consensus, and we brought to the table what we
though was important for you. As you clearly stated later, you had not
asked us to do that, so it s my bad. When I thought we found a consensus, i
kindly asked cullen tot put your name before presenting it, to show we had
also included your concerns in our discussion and teh corresponding
solution.

this one is on me, and I apologise, again, for it.

--0000000000003a53f60581e3782d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I do not agree with everything culled say, but still,=
=C2=A0
I wanted to say something for his defence on his point whe=
re i think he is being given credits for my mistake.

You had discussions with people. I was not an ac=
tive part of them. You put my name on a slide of "supporters" and=
 you were about to present to that to the WG. I saw that and asked you to r=
emove my name. Please do not imply sudden whimsical changes of positions.

I am the culprit for bring=
ing your name in at IETF 99. Sergio and I spoke with cullen to try to find =
a consensus, and we brought to the table what we though was important for y=
ou. As you clearly stated later, you had not asked us to do that, so it s m=
y bad. When I thought we found a consensus, i kindly asked cullen tot put y=
our name before presenting it, to show we had also included your concerns i=
n our discussion and teh corresponding solution.

t=
his one is on me, and I apologise, again, for it.



--0000000000003a53f60581e3782d--


From nobody Fri Feb 15 20:08:34 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23642131057; Fri, 15 Feb 2019 20:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr6yfvw1BRQv; Fri, 15 Feb 2019 20:08:31 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7BD130E92; Fri, 15 Feb 2019 20:08:29 -0800 (PST)
Received: from authuser (localhost [127.0.0.1]) 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550290102; bh=78kkfcbmqNfrOHaIo+R9in2EU0mU5fQ7PTq2X2zjJ8Q=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=uW55yl8ix6OapZr0Lbkudn5VL+0xlwJYoKyMzZOhs4qCFru8GZprSj3ZjMNlcS37g GfJhVlRgtrFYlVfwkVEex+Xo2jM7OJidGn4zWjOWD40gQlmEayydRgmTs8MbCJkayY wr+PtSH36PCCkbg0Y0PpvhKZRvPGFUKFhiNG824M=
From: "Paul E. Jones" 
To: "Gorry Fairhurst" , tsv-art@ietf.org
Cc: ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
Date: Sat, 16 Feb 2019 04:08:17 +0000
Message-Id: 
In-Reply-To: <154930159870.28630.16457371613620717540@ietfa.amsl.com>
References: <154930159870.28630.16457371613620717540@ietfa.amsl.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.34208.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Perc] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2019 04:08:33 -0000

Gorry,

Thanks for your review.  Please see comment/questions in-line.

>General comments
>
>Some keywords appear not defined before first used - whilst these are like=
ly
>to be well-known by the coimmunity of interest, it would none-the-less
>be helpful to define these:
>
>SRTP; RTCP; SIP; SDP.

Most of these have a reference that follows them (RTCP was the one=20
exception, I think). Are you saying we should fully state what SRTP=20
stands for, for example, or are you saying references were missing?


>In section 8.1, there is a sentence starting "Off-path atttackers may" ... =
while this
>is lower case, the authors may wish toi consider using "could" to remove a=
ny
>possibility of this being regarded as permissive.

Agreed. Changed as suggested.

>In 8.1, the text "could incorrectly assuming their packets..." probably ou=
ght to
>read could incorrectly assume their packets..."

Thanks. Fixed that and another small grammatical error there.

>In section 8.2.1. there is a dscription of a resource consumption attack,=
 but
>no miitigation is described. It could be possible to consider using  rate-=
limiting
>of requests to reduce the impact - a mthod commonly suggested in other
>attacks on the transport endpoints
Good point. We cannot stop this entirely, but there are certainly=20
implementation-specific approaches that could be employed.

I appended that paragraph with the following:

"While resource consumption attacks cannot be mitigated entirely,=20
rate-limiting packets might help reduce the effectiveness of such=20
attacks."

I'm open to alternative wording, but I think that should suffice.

Thanks,
Paul


From nobody Fri Feb 15 20:53:14 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5EB13108C; Fri, 15 Feb 2019 20:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPW6WrNUCCYo; Fri, 15 Feb 2019 20:53:03 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B963812958B; Fri, 15 Feb 2019 20:53:02 -0800 (PST)
Received: from authuser (localhost [127.0.0.1]) 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550292773; bh=0U9Dt/tluuhbDMAqAhpxGS6vqyrwqMda9LMNRhOT35I=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=DSvKlr3uDPuRqC1eCdaf+98iBM1fyCQv3GeRWVhrjjNoE4ug7gQXD1LzUO8qyNCrD srXtP2vnRy3WuebdyHsF+/N40dkNR9v0/Gta7ZepOigZA0GOCgeTJxjn+pgpOqLjm8 JyoE8nG7yy1wot/wxMAHTpvRRPOw2FuOgmHewPSs=
From: "Paul E. Jones" 
To: "Linda Dunbar" , gen-art@ietf.org
Cc: ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
Date: Sat, 16 Feb 2019 04:52:50 +0000
Message-Id: 
In-Reply-To: <154967186390.31080.3030875691159376140@ietfa.amsl.com>
References: <154967186390.31080.3030875691159376140@ietfa.amsl.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.34208.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB00792A76-DBB6-40DD-9FE5-5A70ACACB35E"
Archived-At: 
Subject: Re: [Perc] Genart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2019 04:53:06 -0000

--------=_MB00792A76-DBB6-40DD-9FE5-5A70ACACB35E
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Linda,

Thanks for your feedback.  Please see comments inline.

>Major issues:
>  The SRTP Master Key described in Section 6.4 is not listed in the Figure =
4 Key
>  Inventory. What is the relationship between the KEK listed in the Figure =
4 Key
>  Inventory and the SRTP Master Key?

The SRTP master key is the E2E key in this case. I can see why this is=20
confusing. I'll revise the table to add "SRTP master key" in place of=20
"Key" on each of the last two entries in Figure 4 and add "E2E" before=20
"master key" in section 6.4. I think that should make things clearer.

>
>Section 6.3 talks about Key distributor sending KEK to endpoints.  Is it v=
ia
>untrusted network?  how to prevent the KEK from leaking to other points?
>  Is KEK same as EKT Key? if yes, why use two names? it is confusing.

The network is untrusted, but the key delivery uses DTLS-SRTP, which=20
ensures that the entity delivering the key is trusted (since=20
certificates are verified). KEK and EKT Key are the same, yes. That was=20
explained in section 4.2. (Personally, I don't like using both terms,=20
but I lost that battle long ago. KEK is a more generic term for the=20
function/role of the key commonly used in security [e.g., see=20
https://csrc.nist.gov/glossary/term/Key_Encryption_Key], whereas EKT Key=20
is more specific in defining what the KEK is. This is like saying "I=20
drive a car [KEK], specifically a Ford Focus [EKT Key]." That's not the=20
best analogy, but I think it explains the difference more clearly than=20
just repeating the same words. In PERC, we have only one type of KEK,=20
which is the EKT Key. And that was why I was arguing to avoid KEK=20
entirely. That said, the counter-argument is that KEK immediately tells=20
a security person about the nature of the key.)


>Section 5: the first paragraph says that the "Key requirements are that
>endpoint can verify it is connected to the correct Key Distributor..", But =
How?
>can you include a reference to the method?

PERC is focused on securing the media end-to-end, but the problem of=20
properly identifying endpoints or the Key Distributor is a separate=20
issue. However, it's absolutely a key requirement to building a secure=20
system. Section 5.1 and 5.2 provide two possible approaches to trying to=20
tackle that problem, but those are merely options for consideration.


>Minor issues:
>
>Nits/editorial comments:
>Section 3.2.2: is it a typo? extra "to" in the following sentence?
>"...is necessary to for proper conference-to-endpoint mappings."

Yep, definitely another typo.

Thanks!
Paul

--------=_MB00792A76-DBB6-40DD-9FE5-5A70ACACB35E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable




L=
inda,

Thanks for your feedback. =C2=
=A0Please see comments inline.





Major issues:


 The SRTP Master Key =
described in Section 6.4 is not listed in the Figure 4 Key


 Inventory. What is=
 the relationship between the KEK listed in the Figure 4 Key


 Inventory and the S=
RTP Master Key?

The SRTP master key is the E2E key =
in this case.  I can see why this is confusing. I'll revise the table to a=
dd "SRTP master key" in place of "Key" on each of the last two entries in F=
igure 4 and add "E2E" before "master key" in section 6.4.  I think that sho=
uld make things clearer.




Section 6.3 talks ab=
out Key distributor sending KEK to endpoints.  Is it via


untrusted network? =
 how to prevent the KEK from leaking to other points?


 Is KEK same as EKT=
 Key? if yes, why use two names? it is confusing.

=
The network is untrusted, but the key delivery uses DTLS-SRTP, which ensure=
s that the entity delivering the key is trusted (since certificates are ver=
ified).  KEK and EKT Key are the same, yes.  That was explained in section=
 4.2.  (Personally, I don't like using both terms, but I lost that battle lo=
ng ago.  KEK is a more generic term for the function/role of the key common=
ly used in security [e.g., see https://csrc.nist.gov/glossary/term/Key_Encr=
yption_Key], whereas EKT Key is more specific in defining what the KEK is.  =
This is like saying "I drive a car [KEK], specifically a Ford Focus [EKT K=
ey]."  That's not the best analogy, but I think it explains the difference=
 more clearly than just repeating the same words.  In PERC, we have only one =
type of KEK, which is the EKT Key.  And that was why I was arguing to avoi=
d KEK entirely.  That said, the counter-argument is that KEK immediately te=
lls a security person about the nature of the key.)

=


Section 5: the first paragraph says that the "Key requirem=
ents are that


endpoint can verify=
 it is connected to the correct Key Distributor..", But How?


can you include a re=
ference to the method?

PERC is focused on securing =
the media end-to-end, but the problem of properly identifying endpoints or =
the Key Distributor is a separate issue.  However, it's absolutely a key r=
equirement to building a secure system.  Section 5.1 and 5.2 provide two po=
ssible approaches to trying to tackle that problem, but those are merely op=
tions for consideration.


Minor issu=
es:


=C2=A0


Nits/editorial comme=
nts:


Section 3.2.2: is it =
a typo? extra "to" in the following sentence?


"...is necessary to=
 for proper conference-to-endpoint mappings."

Yep, definitely a=
nother typo.

Than=
ks!
Pa=
ul





--------=_MB00792A76-DBB6-40DD-9FE5-5A70ACACB35E--


From nobody Fri Feb 15 21:47:45 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0C7129A85; Fri, 15 Feb 2019 21:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0bI3qXbh2JN; Fri, 15 Feb 2019 21:47:33 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699511277D2; Fri, 15 Feb 2019 21:47:33 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1G5lMOr086429 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Feb 2019 23:47:24 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550296046; bh=Gfw/MhIVFSUIlJRiu9EOA0cJwfrzipc9cvk9jsCRWBQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=HxafWDh9+ySvREylyLVIGTMbm5XNI3YmsUYN5nPgjxW3R8OoKCvIu+pzcqFhp6/ij BodMXSXF4PAD/d1QfEUqawWvMh4FvI7PU9Pb9e5Hq/icV1Uy4qGB84vPkns3nyEG27 dDy6FKGQxPOVJmDl2bQU6E6TNvSEPtc93jPphKzs=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell 
Message-Id: <4B985943-DDA4-42EE-B6FD-F567A5841F75@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_D6517A40-C171-476F-A311-B70E7AD5F6ED"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 15 Feb 2019 23:47:21 -0600
In-Reply-To: 
Cc: Gorry Fairhurst , tsv-art@ietf.org, ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
To: "Paul E. Jones" 
References: <154930159870.28630.16457371613620717540@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [Perc] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2019 05:47:35 -0000

--Apple-Mail=_D6517A40-C171-476F-A311-B70E7AD5F6ED
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_777D7B2F-C0C1-49E2-AF73-0D3113ECD00B"


--Apple-Mail=_777D7B2F-C0C1-49E2-AF73-0D3113ECD00B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I have a comment on one point, below:

> On Feb 15, 2019, at 10:08 PM, Paul E. Jones  =
wrote:
>=20
>>=20
>> Some keywords appear not defined before first used - whilst these are =
likely
>> to be well-known by the coimmunity of interest, it would =
none-the-less
>> be helpful to define these:
>>=20
>> SRTP; RTCP; SIP; SDP.
>=20
> Most of these have a reference that follows them (RTCP was the one =
exception, I think). Are you saying we should fully state what SRTP =
stands for, for example, or are you saying references were missing?

Abbreviations should be expanded except for those listed as =
=E2=80=9Cwell-known=E2=80=9D by the RFC editor, whether or not they have =
a citation. The list is at =
https://www.rfc-editor.org/materials/abbrev.expansion.txt =
 . Well-known =
abbreviations are marked with an asterisk.

To save you from searching: SIP is marked as well-known. SRTP, RTCP, and =
SDP are not.

Thanks!

Ben.

--Apple-Mail=_777D7B2F-C0C1-49E2-AF73-0D3113ECD00B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
have a comment on one point, below:

On Feb =
15, 2019, at 10:08 PM, Paul E. Jones <paulej@packetizer.com> wrote:


Some keywords appear not defined before first used - whilst =
these are likely
to be well-known by the coimmunity of =
interest, it would none-the-less
be helpful to define =
these:

SRTP; RTCP; SIP; SDP.

Most of these have a reference that follows them (RTCP was =
the one exception, I think). Are you saying we should fully state what =
SRTP stands for, for example, or are you saying references were =
missing?

Abbreviations should be expanded except for those listed as =
=E2=80=9Cwell-known=E2=80=9D by the RFC editor, whether or not they have =
a citation. The list is at https://www.rfc-editor.org/materials/abbrev.expansion.txt&n=
bsp;. Well-known abbreviations are marked with an =
asterisk. 

To save you from searching: SIP is marked as well-known. =
SRTP, RTCP, and SDP are not.

Thanks!

Ben.
=

--Apple-Mail=_777D7B2F-C0C1-49E2-AF73-0D3113ECD00B--

--Apple-Mail=_D6517A40-C171-476F-A311-B70E7AD5F6ED
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxno+kACgkQgFZKbJXz
1A0aOw//cVoG7R6aNBcOkceJmQJdHZUlIWV00IHkViYMk2UW14CeCWlYJ1U6Odfy
TW39EN2LL73K1UnWXy2Tk1G4YPFkW3E/inIS+qMbY/TydHomeHSgKsrLYAXApL7l
1FR3J2zZsbWbtrtStLY44lU9ImYea+D1sYSeB5aNBlYfXFHHIEOGfAmxKjsJ+axB
ElETa3CTbbKcw93yc92HhhEvkq8oW3F7M1vHZ+xzXbzEbwzSSA2/rLCaxvEdlR0G
bOZsbi6p02+HONM1L9Y/M6EQjwfPDjD8LGZVhlzpe5eTDTlc1qAFC7Dz9vccrPbC
CQ7uTncsy2K79stNpaAIGK75JRd3ZvgTflNIlMLifpb5z8xBQazw2gVx5HDAhltG
T3uNx/2XUfPA6fbYySs6LG0jg3mTzLNkrOG5dTpYmWdXU18M2RaVmIAuCGCPLK0F
pRzpEBD/jvXOwm6vG7ITE7MWiIJZWt04OwKOeXYo3UCVoO3k0+7v+/dxSlLg7+3A
VIAWR0i9tqgL0IB3leS7aKIoxJTiRZ6vlvfIVKjhhe1ZBeGdU+VuAsuOuX+uPP+Z
xZDV+4BHwnpbjhCg24ihGdogIlhvTBK2Lffj1M8q+jVk48AQ0rsYsH/0xBwVxDbd
zSdJVLKNOB2mFk7OU2zTxrSDYt7GZhTp8dCUA1HUGMkXRGlNmuw=
=CjDS
-----END PGP SIGNATURE-----

--Apple-Mail=_D6517A40-C171-476F-A311-B70E7AD5F6ED--


From nobody Fri Feb 15 23:06:50 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6284A12D4E7; Fri, 15 Feb 2019 23:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlbLeFzQe7w9; Fri, 15 Feb 2019 23:06:47 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A9B1277D2; Fri, 15 Feb 2019 23:06:47 -0800 (PST)
Received: from authuser (localhost [127.0.0.1]) 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550300799; bh=NICydiXCB1iGhnPHuhTObo0DSRAccfqZPNDdrfCxTzA=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=dr750xGV+PeatM5pCKeQHpD3d0htVK0/c0S1SAt819tKD7JVgdQ4B43R6sLUEo1Rc YIowjzfAiUytkUsT2FdbYn2s9GoXryeEpxeTa/t7i/LINMhjdPvF/56Eu/xYScyOCj PwGBBzlAzRaeu8imaJx5ZOD3eeOda9iLF59de8oQ=
From: "Paul E. Jones" 
To: "Ben Campbell" 
Cc: "Gorry Fairhurst" , tsv-art@ietf.org, ietf@ietf.org,  draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
Date: Sat, 16 Feb 2019 07:06:35 +0000
Message-Id: 
In-Reply-To: <4B985943-DDA4-42EE-B6FD-F567A5841F75@nostrum.com>
References: <154930159870.28630.16457371613620717540@ietfa.amsl.com>  <4B985943-DDA4-42EE-B6FD-F567A5841F75@nostrum.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.34208.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBCF828596-1F7A-46A2-88B0-35135603390A"
Archived-At: 
Subject: Re: [Perc] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2019 07:06:49 -0000

--------=_MBCF828596-1F7A-46A2-88B0-35135603390A
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks, Ben.  I wasn't aware of this list.  I've expanded as appropriate=20
in my local copy.  That should appear in the next version.

Paul

------ Original Message ------
From: "Ben Campbell" 
To: "Paul E. Jones" 
Cc: "Gorry Fairhurst" ; tsv-art@ietf.org;=20
ietf@ietf.org; draft-ietf-perc-private-media-framework.all@ietf.org;=20
perc@ietf.org
Sent: 2/16/2019 12:47:21 AM
Subject: Re: [Perc] Tsvart last call review of=20
draft-ietf-perc-private-media-framework-08

>I have a comment on one point, below:
>
>>On Feb 15, 2019, at 10:08 PM, Paul E. Jones =20
>>wrote:
>>
>>>
>>>Some keywords appear not defined before first used - whilst these are=20
>>>likely
>>>to be well-known by the coimmunity of interest, it would=20
>>>none-the-less
>>>be helpful to define these:
>>>
>>>SRTP; RTCP; SIP; SDP.
>>
>>Most of these have a reference that follows them (RTCP was the one=20
>>exception, I think). Are you saying we should fully state what SRTP=20
>>stands for, for example, or are you saying references were missing?
>
>Abbreviations should be expanded except for those listed as=20
>=E2=80=9Cwell-known=E2=80=9D by the RFC editor, whether or not they have a =
citation.=20
>The list is at=20
>https://www.rfc-editor.org/materials/abbrev.expansion.txt . Well-known=20
>abbreviations are marked with an asterisk.
>
>To save you from searching: SIP is marked as well-known. SRTP, RTCP,=20
>and SDP are not.
>
>Thanks!
>
>Ben.
--------=_MBCF828596-1F7A-46A2-88B0-35135603390A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


=
Thanks, Ben. =C2=A0I wasn't aware of this list. =C2=A0I've expanded as appr=
opriate in my local copy. =C2=A0That should appear in the next version.

Paul





------ Original Message ------


From: "Ben Campbell" <ben@nostru=
m.com>


To: "Paul E. Jones" <paule=
j@packetizer.com>



Sent: 2/16/2019 12:47:21 AM


Subject: Re: [Perc] Tsvart last call review of draft-ietf-perc-private=
-media-framework-08




I have a comment on one point, below:

On Feb 15, 2019, at 1=
0:08 PM, Paul E. Jones <paulej@packetizer.com> wrote:


Some keywords appear not defined before first used - whilst these=
 are likely
to be well-known by the coimmunity of interest,=
 it would none-the-less
be helpful to define these:

SRTP; RTCP; SIP; SDP.

Most of these have a refer=
ence that follows them (RTCP was the one exception, I think). Are you sayin=
g we should fully state what SRTP stands for, for example, or are you sayin=
g references were missing?
<=
/div>

Abbreviation=
s should be expanded except for those listed as =E2=80=9Cwell-known=E2=80=
=9D by the RFC editor, whether or not they have a citation. The list is at=
=C2=A0https://www.rfc-editor.org/materials/abbrev.expansion.txt=
=C2=A0. Well-known abbreviations are marked with an asterisk.=C2=A0

To save you from searc=
hing: SIP is marked as well-known. SRTP, RTCP, and SDP are not.

Thanks!

Ben.


--------=_MBCF828596-1F7A-46A2-88B0-35135603390A--


From nobody Sat Feb 16 01:58:32 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24812D4EF; Sat, 16 Feb 2019 01:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OWnmQEDfF9C; Sat, 16 Feb 2019 01:58:19 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2619D12D4E7; Sat, 16 Feb 2019 01:58:18 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0BB2F1B0023D; Sat, 16 Feb 2019 09:58:09 +0000 (GMT)
Message-ID: <5C67DEB1.6020204@erg.abdn.ac.uk>
Date: Sat, 16 Feb 2019 09:58:09 +0000
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Paul E. Jones" 
CC: "Paul E. Jones" ,  tsv-art@ietf.org, ietf@ietf.org,  draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
References: <154930159870.28630.16457371613620717540@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Perc] [Tsv-art] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2019 09:58:22 -0000

On 16/02/2019, 04:08, Paul E. Jones wrote:
> Gorry,
>
> Thanks for your review.  Please see comment/questions in-line.
>
>> General comments
>>
>> Some keywords appear not defined before first used - whilst these are 
>> likely
>> to be well-known by the coimmunity of interest, it would none-the-less
>> be helpful to define these:
>>
>> SRTP; RTCP; SIP; SDP.
>
> Most of these have a reference that follows them (RTCP was the one 
> exception, I think). Are you saying we should fully state what SRTP 
> stands for, for example, or are you saying references were missing?
>
RFCs are read by people with many backgrounds for many reasons. With 
this in mind, I was just suggesting to expand the acconyms.
>
>> In section 8.1, there is a sentence starting "Off-path atttackers 
>> may" ... while this
>> is lower case, the authors may wish toi consider using "could" to 
>> remove any
>> possibility of this being regarded as permissive.
>
> Agreed. Changed as suggested.
>
>> In 8.1, the text "could incorrectly assuming their packets..." 
>> probably ought to
>> read could incorrectly assume their packets..."
>
> Thanks. Fixed that and another small grammatical error there.
>
>> In section 8.2.1. there is a dscription of a resource consumption 
>> attack, but
>> no miitigation is described. It could be possible to consider using  
>> rate-limiting
>> of requests to reduce the impact - a mthod commonly suggested in other
>> attacks on the transport endpoints
> Good point. We cannot stop this entirely, but there are certainly 
> implementation-specific approaches that could be employed.
>
> I appended that paragraph with the following:
>
> "While resource consumption attacks cannot be mitigated entirely, 
> rate-limiting packets might help reduce the effectiveness of such 
> attacks."
>
> I'm open to alternative wording, but I think that should suffice.
>
Maybe /effectiveness/ could be /impact/ ?
... I'd personally prefer to not suggest attacks are effective, but 
happy with some such words.
> Thanks,
> Paul
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
Best wishes,

Gorry


From nobody Sat Feb 16 16:41:29 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F5212DF71; Sat, 16 Feb 2019 16:41:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: perc-chairs@ietf.org, Suhas Nandakumar , suhasietf@gmail.com, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155036408153.28622.17720265202357870501.idtracker@ietfa.amsl.com>
Date: Sat, 16 Feb 2019 16:41:21 -0800
Archived-At: 
Subject: [Perc] Eric Rescorla's No Objection on draft-ietf-perc-srtp-ekt-diet-09: (with COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2019 00:41:22 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3741



IMPORTANT
S 4.4.1.
>      FullEKTField is retransmitted 3 times, that only counts as 1
>      encryption.
>   
>      Security requirements for EKT ciphers are discussed in Section 6.
>   
>   4.4.1.  Ciphers

How do I know which cipher is in use? Is it attached to EKTKey?


S 5.2.2.
>      Note: To be clear, EKT can be used with versions of DTLS prior to
>      1.3.  The only difference is that in a pre-1.3 TLS stacks will not
>      have built-in support for generating and processing Ack messages.
>   
>      If an EKTKey message is received that cannot be processed, then the
>      recipient MUST respond with an appropriate DTLS alert.

How important is it that you (a) be able to change EKTKeys and (b) be
able to work with DTLS < 1.3? Because if the answer to these is "no",
then you can just send EKTKeys in EncryptedExtensions.


S 6.
>      With EKT, each SRTP sender and receiver MUST generate distinct SRTP
>      master keys.  This property avoids any security concern over the re-
>      use of keys, by empowering the SRTP layer to create keys on demand.
>      Note that the inputs of EKT are the same as for SRTP with key-
>      sharing: a single key is provided to protect an entire SRTP session.
>      However, EKT remains secure even when SSRC values collide.

How am I supposed to decrypt in case I don't have a FullEKTField? Am I
supposed to use the IP address.


S 6.
>      context, e.g., from a different sender.  When the underlying SRTP
>      transform provides integrity protection, this attack will just result
>      in packet loss.  If it does not, then it will result in random data
>      being fed to RTP payload processing.  An attacker that is in a
>      position to mount these attacks, however, could achieve the same
>      effects more easily without attacking EKT.

Why don't you add an epoch so that you can't roll back?

COMMENTS
S 4.1.
>        :                                                               :
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   Security Parameter Index    | Length                        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |0 0 0 0 0 0 1 0|
>        +-+-+-+-+-+-+-+-+

This encoding seems suboptimal, in that you burn an extra byte for
every FullEKTField. Given that:

1. You are only defining two types
2. It seems unlikely that there will ever be an EKTCiphertext longer
than 128 bits.

I would suggest the following encoding:

- The first bit of the last byte indicates whether this is
FullEKTField or . If it's FullEKTField, the rest is
used for length. Otherwise, the rest is used for type.



From nobody Sat Feb 16 18:54:55 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EB21294FA; Sat, 16 Feb 2019 18:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uao8zxwgsX3J; Sat, 16 Feb 2019 18:54:46 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442C7126D00; Sat, 16 Feb 2019 18:54:46 -0800 (PST)
Received: from authuser (localhost [127.0.0.1]) 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550372076; bh=KTjeG/jetWYTX/D5SZgI4zCN931+dFT6/CklYJ6NgZs=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=fvoWZqVfrEFMacInV2VUSE9eg0UQphdZVBqRuOEPN9w8E7gUVsy4R6JWBtSgeqaiV hrHkyJDsjLbdLF5Eg9d94DU28JVnP8xXmhjz7GXkw1LaCSMUU7iLS7ggKySfEQv7RV xRxupa7W+9Zm0paggZ5XT09SNr7piX0TcTYevIIE=
From: "Paul E. Jones" 
To: gorry@erg.abdn.ac.uk
Cc: "Paul E. Jones" , tsv-art@ietf.org, ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
Date: Sun, 17 Feb 2019 02:54:32 +0000
Message-Id: 
In-Reply-To: <5C67DEB1.6020204@erg.abdn.ac.uk>
References: <154930159870.28630.16457371613620717540@ietfa.amsl.com>  <5C67DEB1.6020204@erg.abdn.ac.uk>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.34208.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Perc] [Tsv-art] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Feb 2019 02:54:47 -0000

Gorry,

>>Most of these have a reference that follows them (RTCP was the one except=
ion, I think). Are you saying we should fully state what SRTP stands for, f=
or example, or are you saying references were missing?
>>
>RFCs are read by people with many backgrounds for many reasons. With this=
 in mind, I was just suggesting to expand the acconyms.

Understood, and done. It will appear that way in the next publication.

>>I appended that paragraph with the following:
>>
>>"While resource consumption attacks cannot be mitigated entirely, rate-li=
miting packets might help reduce the effectiveness of such attacks."
>>
>>I'm open to alternative wording, but I think that should suffice.
>>
>Maybe /effectiveness/ could be /impact/ ?
>... I'd personally prefer to not suggest attacks are effective, but happy=
 with some such words.

Sure, that change sounds good. I'm always the optimist, but optimism in=20
the wrong direction isn't so positive. :)

Thanks!
Paul


From nobody Tue Feb 19 06:08:35 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0799129741; Tue, 19 Feb 2019 06:08:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155058531271.20695.13022201580750157140.idtracker@ietfa.amsl.com>
Date: Tue, 19 Feb 2019 06:08:32 -0800
Archived-At: 
Subject: [Perc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-perc-srtp-ekt-diet-09=3A_=28with_COMMENT=29?=
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2019 14:08:33 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just a quick clarification question:
Sec 4.2.1: "   Outbound packets SHOULD continue to use the old SRTP Master Key
for
   250 ms after sending any new key.  This gives all the receivers in
   the system time to get the new key before they start receiving media
   encrypted with the new key."
I assume that 250ms is selected under the assumption that longer RTTs are a
problem for interactive communication anyway? Or where does this value come
from?



From nobody Tue Feb 19 09:40:16 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E81F12950A; Tue, 19 Feb 2019 09:40:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155059801437.20845.617758365697782940.idtracker@ietfa.amsl.com>
Date: Tue, 19 Feb 2019 09:40:14 -0800
Archived-At: 
Subject: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2019 17:40:15 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[this is a placeholder Discuss  to indicate a couple of broad issues early; a full
review and ballot position is forthcoming]

I think  we need to discuss whether the mechanism described in Section 4.1 contains
an EKT-specific extension mechanism or is in fact a more general mechanism for
including extensions in SRTP packets outside the SRTP cryptographic protection.
(If so, we would probably need to Update 3711 to indicate as much, and perhaps allow
for multiple extension types to be present adjacently.)  In particular, how would this
EKT extension interact with any other future mechanism that needs to add data to
SRTP  packets outside the SRTP cryptographic wrapper?

I also think we need to discuss whether it is appropriate to set a precedent that any
standards-track protocol can get a dedicated TLS HandshakeType (noting that this is
a potentially scarce one-octet field.  Would it be more appropriate to define a generic
"key transport" container that can be generally applicable to many protocols, and have
an internal extension point that allows for an SRTP+EKT-specific usage within the
TLS HandshakeType?





From nobody Tue Feb 19 19:57:56 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AEE12F1A2; Tue, 19 Feb 2019 19:57:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: perc@ietf.org
Message-ID: <155063506891.20755.6539178358754464256@ietfa.amsl.com>
Date: Tue, 19 Feb 2019 19:57:48 -0800
Archived-At: 
Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-09.txt
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 03:57:49 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Privacy Enhanced RTP Conferencing  WG of the IETF.

        Title           : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing
        Authors         : Paul E. Jones
                          David Benham
                          Christian Groves
	Filename        : draft-ietf-perc-private-media-framework-09.txt
	Pages           : 24
	Date            : 2019-02-19

Abstract:
   This document describes a solution framework for ensuring that media
   confidentiality and integrity are maintained end-to-end within the
   context of a switched conferencing environment where media
   distributors are not trusted with the end-to-end media encryption
   keys.  The solution aims to build upon existing security mechanisms
   defined for the real-time transport protocol (RTP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-09
https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framework-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Feb 19 21:59:46 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA15A12D84D; Tue, 19 Feb 2019 21:59:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155064237866.20629.17492215651852136003.idtracker@ietfa.amsl.com>
Date: Tue, 19 Feb 2019 21:59:38 -0800
Archived-At: 
Subject: [Perc] Adam Roach's Yes on draft-ietf-perc-srtp-ekt-diet-09: (with COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 05:59:39 -0000

Adam Roach has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks to the work that everyone has put in on getting an EKT mechanism
specified and finalized. I have a handful of comments that I would like to see
considered prior to publication of the document.

---------------------------------------------------------------------------

§1:

>  EKT provides a way for an SRTP session participant, to securely
>  transport its SRTP master key and current SRTP rollover counter to
>  the other participants in the session.

Nit: "...participant to securely..."

---------------------------------------------------------------------------

§4.1:

>   EKTMsgTypeExtension = %x03-FF

Shouldn't this be "%x01 / %x03-ff" ?

>   SRTPMasterKeyLength = BYTE
>   SRTPMasterKey = 1*256BYTE

I think this either needs to be "1*255BYTE", or we need text that explicitly
indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably
the former.

I think this is even further constrained by the fact that EKTCiphertext is
limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey,
SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength
can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is
more appropriate?

---------------------------------------------------------------------------

§4.2.1:

>  The creation of the EKTField MUST precede the normal SRTP
>  packet processing.

Why? This seems unnecessary and unnecessarily complicated. If the order of
operations has an impact on the bits on the wire (I don't see how it does?),
then please include some explanatory text here that clarifies the reason for
this constraint.

---------------------------------------------------------------------------


§4.2.1:

>  When a packet is sent with the ShortEKTField, the ShortEKFField is
>  simply appended to the packet.

Nit: s/ShortEKFField/ShortEKTField/

---------------------------------------------------------------------------

§4.2.1:

>  5.  If the SSRC in the EKTPlaintext does not match the SSRC of the
>      SRTP packet received, then all the information from this
>      EKTPlaintext MUST be discarded and the following steps in this
>      list are skipped.

I can see implementors easily interpreting this as requiring them to discard
the RTP payload as well. If that's not the intention (I don't think it is),
consider adding text like "The FullEKTField is removed from the packet then
normal SRTP or SRTCP processing occurs."

---------------------------------------------------------------------------

§4.3:

>  Section 4.2.1 recommends that SRTP senders continue using an old key
>  for some time after sending a new key in an EKT tag.

This is the first appearance of the phrase "EKT tag," which never seems to be
properly defined. I presume this is meant to be the combination of the EKT
Ciphertext and the SPI?

In any case, please clearly define this term somewhere, preferably before using
it the first time.

---------------------------------------------------------------------------

§4.3:

>  cannot be used and they also need to create a counter that keeps
>  track of how many times the key has been used to encrypt data to
>  ensure it does not exceed the T value for that cipher (see ).

The parenthetical phrase appears to be missing something here.


>  If
>  either of these limits are exceeded, the key can no longer be used

Nit: "...either... is exceeded..."

>  for encryption.  At this point implementation need to either use the

Nit: "...implementations need..."

---------------------------------------------------------------------------

§4.5:

>  If a source has its EKTKey changed by the key management, it MUST
>  also change its SRTP master key

I suppose it's not terribly important for interop, but the implication that this
change takes place immediately seems to contradict the 250 ms period specified
in §4.2.1. Perhaps a few words here about how these two normative statements
are intended to interact would save implementors a bit of grief.

---------------------------------------------------------------------------

§4.6:

>  This document defines the use of EKT with SRTP.  Its use with SRTCP
>  would be similar, but is reserved for a future specification.

After reading this far, I was quite surprised to find this qualification. If
this is the intention for this document, please adjust the rest of the text to
match. Some examples follow.

>  The following shows the syntax of the EKTField expressed in ABNF
>  [RFC5234].  The EKTField is added to the end of an SRTP or SRTCP
>  packet.
-----
>  Rollover Counter (ROC): On the sender side, this is set to the
>  current value of the SRTP rollover counter in the SRTP/SRTCP context
>  associated with the SSRC in the SRTP or SRTCP packet.
-----
>  1.  The final byte is checked to determine which EKT format is in
>      use.  When an SRTP or SRTCP packet contains a ShortEKTField, the
>      ShortEKTField is removed from the packet then normal SRTP or
>      SRTCP processing occurs.
-----
>      The reason for
>      using the last byte of the packet to indicate the type is that
>      the length of the SRTP or SRTCP part is not known until the
>      decryption has occurred.
-----
>  7.  At this point, EKT processing has successfully completed, and the
>      normal SRTP or SRTCP processing takes place.
-----
>  This allows
>  those peers to process EKT keying material in SRTP (or SRTCP) and
>  retrieve the embedded SRTP keying material.

---------------------------------------------------------------------------

§4.7:

>     To accommodate packet loss, it is
>     RECOMMENDED that three consecutive packets contain the
>     FullEKTField be transmitted.

Nit: "...containing..." (alternately, remove "be transmitted" -- both make a
grammatically correct sentance)

More substantially -- under "New sender:", I'm a little surprised that there
isn't any mention of other senders re-keying in response to a new sender
joining. In the vast majority of conferences, when a sender joins, that same
entity generally will also be a receiver. It seems this should trigger other
senders to include the key in their next packet.

---------------------------------------------------------------------------

§4.7:

>  Rekey:
>     By sending EKT tag over SRTP, the rekeying event shares fate with
>     the SRTP packets protected with that new SRTP master key.

Is this actually true? Going back to the 250 ms period specified in §4.2.1, it
seems that the master key is sent out in packets pretty far removed from those
it actually protects.

Between this and the inconsistency I mention in §4.5 above, this increasingly
feels like maybe there were two different ways of reasoning about the timing
of sending a master key versus the timing of actually using it. Does the text
in §4.2.1 perhaps represent an outdated notion of how this is intended to
work?

---------------------------------------------------------------------------

§4.7:

>     If sending audio and video, the RECOMMENDED
>     frequency is the same as the rate of intra coded video frames.  If
>     only sending audio, the RECOMMENDED frequency is every 100ms.

Is this "100ms" correct?  Assuming, say, the use of Opus at voice quality with
20 ms packets, this is taking packets on the order of 40 bytes in length and
tacking on something like 20 to 30 bytes to every fifth packet. That's an
increase in overall stream size on the order of roughly 15% to 20%.

At the same time, when using real-time video, intra frames are going to happen
roughly every 500 ms to 1500 ms. If a cadence on that order is okay for
audiovisual streams, I have to imagine it's okay for audio streams.

So, to clarify: is this "100ms" a typo for "1000 ms"?

---------------------------------------------------------------------------

§7.2:

>                  +----------+-------+---------------+
>                  | Name     | Value | Specification |
>                  +----------+-------+---------------+
>                  | AESKW128 |     1 | RFCAAAA       |
>                  | AESKW256 |     2 | RFCAAAA       |
>                  | Reserved |   255 | RFCAAAA       |
>                  +----------+-------+---------------+
>
>                        Table 3: EKT Cipher Types

Section 5.2.1 reserves "0" as well. I suspect we want to replicate that
reservation in this table.



From nobody Wed Feb 20 05:25:39 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91463124408; Wed, 20 Feb 2019 05:25:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155066913758.31303.1282920476578920472.idtracker@ietfa.amsl.com>
Date: Wed, 20 Feb 2019 05:25:37 -0800
Archived-At: 
Subject: [Perc] Alexey Melnikov's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 13:25:38 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The document is generally quite readable, which is great. But I have a few
small issues I would like to get clarification on before recommending approval
of this document:

In 4.1:

   Message Type: The last byte is used to indicate the type of the
   EKTField.  This MUST be 2 for the FullEKTField format and 0 in
   ShortEKTField format.  Values less than 64 are mandatory to
   understand while other values are optional to understand.

I thought I knew what this meant when I read it, and then I saw this:

   A receiver
   SHOULD discard the whole EKTField if it contains any message type
   value that is less than 64 and that is not understood.

"SHOULD discard ... EKTField" makes this field NOT mandatory. (If you said
"SHOULD discard the whole packet", that would have been different.) Also, how
"discard" different from the following sentence suggesting "ignore"? I think
you have some inconsistencies/terminology problem here!

   Message type
   values that are 64 or greater but not implemented or understood can
   simply be ignored.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Benjamin's concern about extensibility.

General:

Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the
document. There is a note later on explaining that either can be used, but it
would be better for readers to see this note earlier in the document.

In 4.1:

  EKTMsgLength = 2BYTE;

and similarly:

   SPI = 2BYTE

The document doesn't seem to say whether or not this is in network byte order.

In 4.2.1:

   2.  The EKTPlaintext field is computed from the SRTP Master Key,
       SSRC, and ROC fields, as shown in Section 4.1.  The ROC, SRTP
       Master Key, and SSRC used in EKT processing SHOULD be the same as
       the one used in the SRTP processing.

When can they be different? I.e. why is this not a MUST?

   The computed value of the FullEKTField is written into the SRTP
   packet.

I think this might be misleading. Do you just mean appended to the end of the
SRTP packet after encrypted data? If yes, please say so to avoid confusion with
writing it into encrypted data before encryption.

In 4.3:

   When receiving a new EKTKey, implementations need to use the ekt_ttl
   field (see Section 5.2.2) to create a time after which this key
   cannot be used and they also need to create a counter that keeps
   track of how many times the key has been used to encrypt data to
   ensure it does not exceed the T value for that cipher (see ).

Missing reference after "see" here.

In 4.4.1:

   The default EKT Cipher is the Advanced Encryption Standard (AES) Key
   Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
   length M that is at least one octet, and it returns a ciphertext with
   a length of N = M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I
couldn't figure out how you came up with the N value above. In particular,
where is the "+ 8" coming from?

In 4.7:

   New sender:
      A new sender SHOULD send a packet containing the FullEKTField as
      soon as possible, always before or coincident with sending its
      initial SRTP packet.  To accommodate packet loss, it is
      RECOMMENDED that three consecutive packets contain the
      FullEKTField be transmitted.  If the sender does not send a
      FullEKTField in its initial packets and receivers have not
      otherwise been provisioned with a decryption key, then decryption
      will fail and SRTP packets will be dropped until the the receives

Nit: duplicated "the".

      a FullEKTField from the sender.

In 6:

   An attacker who tampers with the bits in FullEKTField can prevent the
   intended receiver of that packet from being able to decrypt it.  This
   is a minor denial of service vulnerability.  Similarly the attacker
   could take an old FullEKTField from the same session and attach it to
   the packet.  The FullEKTField would correctly decode and pass
   integrity checks.  However, the key extracted from the FullEKTField ,
   when used to decrypt the SRTP payload, would be wrong and the SRTP
   integrity check would fail.  Note that the FullEKTField only changes
   the decryption key and does not change the encryption key.  None of
   these are considered significant attacks as any attacker that can
   modify the packets in transit and cause the integrity check to fail.

The last sentence seems to be incomplete. Did you mean "can" instead of the
last "end"?



From nobody Wed Feb 20 08:34:00 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 394C11277D2; Wed, 20 Feb 2019 08:33:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155068043822.31482.3547890208864938980.idtracker@ietfa.amsl.com>
Date: Wed, 20 Feb 2019 08:33:58 -0800
Archived-At: 
Subject: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 16:33:58 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we need to discuss whether the mechanism described in Section 4.1
contains an EKT-specific extension mechanism or is in fact a more general
mechanism for including extensions in SRTP packets outside the SRTP
cryptographic protection.  (If so, we would probably need to Update 3711 to
indicate as much, and perhaps allow for multiple extension types to be
present adjacently.)  In particular, how would this EKT extension interact
with any other future mechanism that needs to add data to SRTP  packets
outside the SRTP cryptographic wrapper?

I also think we need to discuss whether it is appropriate to set a
precedent that any standards-track protocol can get a dedicated TLS
HandshakeType (noting that this is a potentially scarce one-octet field.
Would it be more appropriate to define a generic "key transport" container
that can be generally applicable to many protocols, and have an internal
extension point that allows for an SRTP+EKT-specific usage within the TLS
HandshakeType?

I'll also hold a discuss for the IANA NOT OK (I noticed the need for more
columns for TLS extension type, at least, and there seems to be more in
their review).

Please state clearly what the scope of an SPI value (and its binding to
EKTKey and  other parameters) is; e.g., that it is only defined within a
given communications session.

Section 4.2.1

   Outbound packets SHOULD continue to use the old SRTP Master Key for
   250 ms after sending any new key.  This gives all the receivers in
   the system time to get the new key before they start receiving media
   encrypted with the new key.

What channel is the "sending any new key" to occur on?  The most
straightforward reading would be in the FullEKTField, but that does not
seem to make much sense.  (Also, is the "any new key" an SRTP master key or
an EKTKey?)

Section 5's one-paragraph intro doesn't really paint a clear picture for me
of why/which DTLS connections are "secure" in a way that the central media
distribution is not.  From reading the whole doc, my perception is that
basically this scheme is useful in cases when you have a central hub for
DTLS negotiation that's trusted to have access to media plaintext, plus a
mesh of SRTP streams (whether centrally mediated or directly connected),
and that it's not appropriate when the  central hub is not trusted with
media access or when there is not a single DTLS party that can distribute
the EKT to all (other) participants).  Could we get some clear explanation
of where this technique is and is not expected to be utilized?

Section 5.5.2 has:

   Note: To be clear, EKT can be used with versions of DTLS prior to
   1.3.  The only difference is that in a pre-1.3 TLS stacks will not
   have built-in support for generating and processing Ack messages.

You need to be more clear about the Ack being needed even when pre-1.3 is
in use (which would seem to make DLTS 1.3 a normative reference).
(See also the COMMENT about citing both DTLS 1.2 and 1.3.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is no cryptographic binding between the EKTCiphertext and the main
SRTP packet, nor is there an authentication tag on the EKTCiphertext that
protects the SPI or length fields (or, for that matter, the message type).
The consequences of this are probably minor, given that an attacker who can
tamper with them could also tamper with the main plaintext, but there is
perhaps potential for causing trouble later in the pipeline, especially
since (as this document admits) there is the possibility of SRTP transforms
that do not provide integrity protection.

The EKT is a group shared symmetric key, with all the usual caveats that
any group member can spoof a message "from" any other group member.
(Reading the group's messages is of course a necessary feature.)
The EKT is furthermore possessed by the central broker in the portrayed
deployment scenario, allowing the broker access to the plaintext of media
if it did not already have such access.

It's probably worth mentioning somewhere what the master salt is used for
so the reader not familiar with the details of RFC 3711 is not left
wondering why we are conveying it.

Section 1

   This document defines Encrypted Key Transport (EKT) for SRTP and
   reduces the amount of external signaling control that is needed in a
   SRTP session with multiple receivers.  EKT securely distributes the
   SRTP master key and other information for each SRTP source.  With
   this method, SRTP entities are free to choose SSRC values as they see
   fit, and to start up new SRTP sources with new SRTP master keys
   within a session without coordinating with other entities via
   external signaling or other external means.

I think you need an explanation and/or reference for previous systems that
required central SSRC allocation (or otherwise why the "free to choose" is
noteworthy here).

   EKT provides a way for an SRTP session participant, to securely
   transport its SRTP master key and current SRTP rollover counter to
   the other participants in the session.  [...]

nit: spurious comma.

                                  This reduces the amount of CPU time
   needed for encryption and can be used for some optimization to media
   sending that use source specific multicast.

nit: I think there's a singular/plural mismatch here.

Section 4

   EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
   Identifier) or with SRTP's  [RFC3711], as those SRTP
   features duplicate some of the functions of EKT.  Senders MUST NOT
   include MKI when using EKT.  Receivers SHOULD simply ignore any MKI
   field received if EKT is in use.

It feels like we're specifically emphasizing the prohibition on EKT with
MKI, and only saying once that EKT with  is prohibited.  Is there
a reason to have a stronger prohibition of the one than the other?

Section 4.1

   The EKTField uses the format defined in Figure 1 for the FullEKTField
   and ShortEKTField.

nit: the ShortEKTField is in Figure 2.

    SRTPMasterKeyLength = BYTE
    SRTPMasterKey = 1*256BYTE
    SSRC = 4BYTE; SSRC from RTP
    ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC

nit: is it conventional to all-caps "FOR THE GIVEN"?

   EKTCiphertext: The data that is output from the EKT encryption
   operation, described in Section 4.4.  This field is included in SRTP
   packets when EKT is in use.  The length of EKTCiphertext can be
   larger than the length of the EKTPlaintext that was encrypted.

Doesn't it *need* to be larger in order to provide the stated properties?
(I.e., it "will be larger".)

   SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes.  This
   depends on the cipher suite negotiated for SRTP using SDP Offer/
   Answer [RFC3264] for the SRTP.

This text would seem to forbid using EKT with any mechanism other than SDP
Offer/Answer for central control.

Do we want to say why a Message Type of 1 is not usable?

Section 4.2.2

[Isn't there a step 0 to figure out whether any EKT/extensions are in use?]

   5.  If the SSRC in the EKTPlaintext does not match the SSRC of the
       SRTP packet received, then all the information from this
       EKTPlaintext MUST be discarded and the following steps in this
       list are skipped.

Does this mean I just ignore EKT and attempt to process the SRTP packet
with whatever non-EKT material I have on hand?

       *  Unless the transform specifies other acceptable key lengths,
          the length of the SRTP Master Key MUST be the same as the

This is the first usage of "transform" in this document; perhaps a reminder
to the reader that this is a stock SRTP concept is in order.

          master key length for the SRTP transform in use.  If this is
          not the case, then the receiver MUST abort EKT processing and
          SHOULD discared the whole UDP packet.

nit: The "this" in "if this is not the case" should probably be spelled out
more clearly, as it seems to require both that the master key length is
different from the master key length for the SRTP transform in use and that
the transform specifies other acceptable key lengths.  (Presumably the
master key still needs to match one of those other acceptable key lengths,
though?)

       *  If the length of the SRTP Master Key is less than the master
          key length for the SRTP transform in use, and the transform
          specifies that this length is acceptable, then the SRTP Master
          Key value is used to replace the first bytes in the existing
          master key.  [...]

Do we need to be more clear about what the "existing master key" is?  (Are
there reordering issues where we could operate on a different key than
intended?)  Also, what do I do if the length of the SRTP master key is
larger than the master key length for the transform in use?

Section 4.3

   Section 4.2.1 recommends that SRTP senders continue using an old key
   for some time after sending a new key in an EKT tag.  Receivers that
   wish to avoid packet loss due to decryption failures MAY perform
   trial decryption with both the old key and the new key, keeping the
   result of whichever decryption succeeds.  Note that this approach is

We have multiple types of key floating around; please be clear about which
ones are which.

   only compatible with SRTP transforms that include integrity
   protection.

What's the guidance for when that's not the case?

   When receiving a new EKTKey, implementations need to use the ekt_ttl
   field (see Section 5.2.2) to create a time after which this key
   cannot be used and they also need to create a counter that keeps
   track of how many times the key has been used to encrypt data to
   ensure it does not exceed the T value for that cipher (see ).  If

Since we knowingly create EKTCiphertexts that are identical, do we count
those as a single encryption or do we count each time we send them?
(I guess Section 4.4 mostly answers this by way of example but a
non-example statement is probably in order.)

                    At this point implementation need to either use the
   call signaling to renegotiate a new session or need to terminate the

nit: "call signaling" seems more SIP-specific than necessary.

   The encryption function returns a ciphertext value C whose length is
   N bytes, where N may be larger than M.  [...]

(same comment about "may be larger" as above)

Section 4.4.2

   An EKTCipher determines how the EKTCiphertext field is written, and
   how it is processed when it is read.  This field is opaque to the
   other aspects of EKT processing.  EKT ciphers are free to use this
   field in any way, but they SHOULD NOT use other EKT or SRTP fields as
   an input.  [...]

Why is this SHOULD NOT instead of MUST NOT?

Section 4.5

Is it worth mentioning (or internally referencing) the 250ms delay before
using the new key?

Section 5.2.1

Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246
the syntax reference?

Section 5.2.2

   If the server did not provide a supported_ekt_ciphers extension in
   its ServerHello, then EKTKey messages MUST NOT be sent by the client
   or the server.

The general text and Figure 4 only show EKTKey being sent by the server.
Is it ever allowed to be sent by the client?

   When an EKTKey is received and processed successfully, the recipient
   MUST respond with an Ack handshake message as described in Section 7
   of [I-D.ietf-tls-dtls13].  The EKTKey message and Ack MUST be
   retransmitted following the rules in Section 4.2.4 of [RFC6347].

It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent
sentences.

Section 6

   With EKT, each SRTP sender and receiver MUST generate distinct SRTP
   master keys.  [...]

Er, isn't this just senders?

   Note that the inputs of EKT are the same as for SRTP with key-

"inputs" in terms of shared cryptographic material that is fed into the
SRTP (plus EKT) protocol collection?

   sharing: a single key is provided to protect an entire SRTP session.
   However, EKT remains secure even when SSRC values collide.

I think you need to say more about what "secure" is supposed to mean, here.

   The presence of the SSRC in the EKTPlaintext ensures that an attacker
   cannot substitute an EKTCiphertext from one SRTP stream into another
   SRTP stream.

Depends on the attacker; if one of the call participants has the network
positioning to do so, their knowledge of the EKT allows for generating an
EKTCiphertext that matches the SSRC of an arbitrary message.  (I guess
technically that involves modifying and not straight substitution of the
EKTCiphertext.)

   An attacker who tampers with the bits in FullEKTField can prevent the
   intended receiver of that packet from being able to decrypt it.  This
   is a minor denial of service vulnerability.  Similarly the attacker
   could take an old FullEKTField from the same session and attach it to
   the packet.  The FullEKTField would correctly decode and pass
   integrity checks.  However, the key extracted from the FullEKTField ,
   when used to decrypt the SRTP payload, would be wrong and the SRTP
   integrity check would fail.  Note that the FullEKTField only changes
   the decryption key and does not change the encryption key.  None of
   these are considered significant attacks as any attacker that can
   modify the packets in transit and cause the integrity check to fail.

I think this last sentence went a bit funky; presumably it's "any attacker
that can modify the packets in transit can already cause the SRTP integrity
check to fail even in the absence of EKT".

   An attacker could send packets containing a FullEKTField, in an
   attempt to consume additional CPU resources of the receiving system
   by causing the receiving system to decrypt the EKT ciphertext and
   detect an authentication failure.  In some cases, caching the
   previous values of the Ciphertext as described in Section 4.3 helps
   mitigate this issue.

I'm not really sure what cases those are supposed to be, since an attacker
can send arbitrary junk and tweak it by a bit each time, and the recipient
has to do the full decryption to validate the integrity IV.

   In a similar vein, EKT has no replay protection, so an attacker could
   implant improper keys in receivers by capturing EKTCiphertext values
   encrypted with a given EKTKey and replaying them in a different
   context, e.g., from a different sender.  When the underlying SRTP

Wouldn't the SSRC check block this particular replay?

   transform provides integrity protection, this attack will just result
   in packet loss.  If it does not, then it will result in random data
   being fed to RTP payload processing.  An attacker that is in a
   position to mount these attacks, however, could achieve the same
   effects more easily without attacking EKT.

maybe add "by directly modifying the SRTP packet contents"?

   The confidentiality, integrity, and authentication of the EKT cipher
   MUST be at least as strong as the SRTP cipher and at least as strong
   as the DTLS-SRTP ciphers.

EKT doesn't carry anything that's an input to DTLS, so shouldn't this
restriction be that the DTLS cipher must be as stront as the EKT one?

Section 7.1

   All new EKT messages MUST be defined to have a length as second from
   the last element.

"16-bit", right?

section 7.4

   IANA is requested to add ekt_key as a new entry in the "TLS
   HandshakeType Registry" table of the "Transport Layer Security (TLS)
   Parameters" registry with a reference to this specification, a DTLS-
   OK value of "Y", and allocate a value of TBD to for this content
   type.

HandshakeType != content type



From nobody Wed Feb 20 14:39:58 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4411130E8B; Wed, 20 Feb 2019 14:39:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155070239679.31452.10759582876250060766.idtracker@ietfa.amsl.com>
Date: Wed, 20 Feb 2019 14:39:56 -0800
Archived-At: 
Subject: [Perc] Alissa Cooper's No Objection on draft-ietf-perc-srtp-ekt-diet-09: (with COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 22:39:57 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think I-D.ietf-tls-dtls13 needs to be a normative reference.



From nobody Wed Feb 20 14:41:40 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1551130E63; Wed, 20 Feb 2019 14:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=E/Ep6uJf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FfMkICoI
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHtVr5E7flM9; Wed, 20 Feb 2019 14:41:29 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B809512D7EA; Wed, 20 Feb 2019 14:41:29 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id BE25D31B4; Wed, 20 Feb 2019 17:41:28 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 20 Feb 2019 17:41:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=5Wslj8eYe08EnDrMxXkFqMn XcnhDIsF/sgNeALAW0s0=; b=E/Ep6uJfFPNtrn1HYl7QITKJQG8JokckhsRNbUJ +/IekwAYJSiv0kDo7uhIGa0HB8TMFeUgdzOzo21cfIac0LoGo5mS3bxv+O5Wj1NK 8Aj5h7V8Y9hroHmksz0SDEqEzueLRCs/U/kDF2hct6FKh4TPhPnU2UMIESL3uXkA DX1dJK0Xt/0sHayNNu0gFGLmQkaVG1i2Wior20JMvBD9JpxSFGMNHnv6lOqxLfIE di7QtgskgpsVl/72Vch6XD/WirqlEyF+2vsXKwTf1+Ks+nG1UHpEIGpKR6/BNxZ3 htDh4gSKPFcBdhZ8wwTiMPD7ldafKJGvgT8ZUAMdUIqYmqg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5Wslj8 eYe08EnDrMxXkFqMnXcnhDIsF/sgNeALAW0s0=; b=FfMkICoIa19gDZFnoNTU91 e8JcZFQMylP7VBPIAQmKRzEMONGMq4MQbbxT20O3b0rtVwRMbYPULInZc/fUr+CF 3BZdQ2uDNbjJbQsgq+ATZNX1finDKtaniBud4TBMPCy1bv0VDXJtLKuUnKhpH0AL i3xmufJS/ZGrR4cOOC3ko+N/aWFWrdZdLoeq3x6elha7X6Bp8RyCNcJemoY5siTu WApB5d7R+MRZgpiFOt72tTTCwhL5e3AxXkQYVUpd/iLM3I6zvIyb7gKJ2x3zaGHr CFeTvJz89LJE6BsPJxseno7cRw8LYO2o2KyLYYN/JKiu6i6OclXY/jry2wd3LXDg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdejucdltddurdegtdelrddttddmucetuf doteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgrucev ohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfkphepuddtgedrudehfedrvddvgedr udeileenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrd hinhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: from [172.19.249.51] (unknown [104.153.224.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 0DA1510310; Wed, 20 Feb 2019 17:41:21 -0500 (EST)
From: Alissa Cooper 
Message-Id: <0E76378A-3129-4801-8C13-66184E295CCF@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AD1B654-74D2-4BDB-88A0-E8E8826C3F44"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 20 Feb 2019 17:41:13 -0500
In-Reply-To: 
Cc: IETF Gen-ART , perc@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org
To: Richard Barnes , Christer Holmberg 
References: <154007316490.13794.11476150183128445420@ietfa.amsl.com> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [Perc] [Gen-art] Genart last call review of draft-ietf-perc-srtp-ekt-diet-09
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2019 22:41:33 -0000

--Apple-Mail=_5AD1B654-74D2-4BDB-88A0-E8E8826C3F44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Christer, thanks for your review. Richard, thanks for your responses. I =
entered a No Objection ballot.

Alissa

> On Feb 7, 2019, at 3:18 PM, Richard Barnes  wrote:
>=20
> Hi Christer,
>=20
> Sorry, just now seeing this.  Responses inline.  PR here:
>=20
> https://github.com/ietf/perc-wg/pull/165 =

>=20
> --RLB
>=20
> On Sat, Oct 20, 2018 at 6:06 PM Christer Holmberg =
> =
wrote:
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>=20
> For more information, please see the FAQ at
>=20
> >.
>=20
> Document: draft-ietf-perc-srtp-ekt-diet-09
> Reviewer: Christer Holmberg
> Review Date: 2018-10-20
> IETF LC End Date: 2018-11-01
> IESG Telechat date: Not scheduled for a telechat
>=20
> Summary: The document is well written, and easy to read. But, I think =
some
> things still need to be clarified. I also have some editorial =
modification
> suggestions.
>=20
> Major issues:
> --------------
>=20
> Q1_1:
>=20
> The text in section 1 says that EKT removes the need for co-ordinating =
SSRCs,
> and that an endpoint can choose whatever value it wants.
>=20
> However, I can't find any explanation on how EKT removes that need.
>=20
> The answer is toward the end of the introduction: "EKT does not =
control the manner in which the SSRC is generated..." -- it just makes =
the distribution of security information easier..  I extended that =
paragraph to clarify.
>=20
> =20
> Q1_3:
>=20
> The text in section 1 says that EKT is not intended to replace key
> establishment mechanisms, but to "be used in conjunction".
>=20
> However, there is no description on how that works in conjunction with =
existing
> mechanisms (e.g., together with SDP Offer/Answer), and whether =
existing
> mechanisms need to be modified in order to work in conjunction with =
EKT.
>=20
> Section 5.3 does say that the SDP O/A exchange is not affected. If =
that is
> true, then you need to describe how SSRC values etc signalled in SDP =
relate to
> values signalled using EKT, what happens if there are mismatches etc.
>=20
> This document only defines one such augmentation -- the integration =
with DTLS-SRTP.  I extended the relevant part of the introduction to say =
this.
>=20
> =20
> Minor issues:
> --------------
>=20
> Q1_2:
>=20
> The text in section 1 says:
>=20
>    "However, there are several cases in which conventional signaling =
systems
>    cannot easily provide all of the coordination required."
>=20
> I think some examples would be useful.
>=20
> Disagree.
> =20
> Q1_4:
>=20
> The text in section 1 says that providing SSRCs etc using signaling =
systems
> cause layer violations.
>=20
> Is this layer violation described somewhere? If so, I think a =
reference would
> be useful.
>=20
> I just deleted this sentence..  It wasn't adding much.
>=20
> =20
> Q4-2_1:
>=20
> The text in section 4.2 says:
>=20
>    "All of the received EKT parameter sets SHOULD be stored by all of =
the
>    participants in an SRTP session, for use in processing inbound SRTP
>    and SRTCP traffic."
>=20
> What is the reason for SHOULD, instead of MUST? What happens if an =
endpoint
> does NOT store the EKT parameter sets?
>=20
> I think the SHOULD here is to allow, e.g., cache management.  =
Clarified the consequences.
>=20
> =20
> Q4-2-1_2:
>=20
> The text in section 4.2.1 says:
>=20
>    "Outbound packets SHOULD continue to use the old SRTP Master Key =
for
>    250 ms after sending any new key."
>=20
> What is the reason for SHOULD, instead of MUST?
>=20
> I don't think this should be a MUST.  For example, how accurately are =
you going to measure compliance?  If the change-over is 10ms short 10% =
of the time, is the endpoint out of compliance. Plus, there's minimal =
interop impact; this just helps things go smoothly.
>=20
> =20
> Q4-3_2:
>=20
> The text in section 4.3 says:
>=20
>    "Section 4.2.1 recommends that SRTP senders continue using an old =
key
>    for some time after sending a new key in an EKT tag."
>=20
> The text in section 4.2.1 contains a SHOULD, so it is more than a
> recommendation.
>=20
> According to RFC 2119, a SHOULD is precisely a recommendation:
>=20
> """
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> """
>=20
> https://tools.ietf.org/html/rfc2119#section-3 =

>=20
> =20
> Nits/editorial comments:
> --------------------------
>=20
> Q1_5:
>=20
> I think Section 1 should also indicate that EKT is an DTLS extension, =
similar
> to the Abstract. Otherwise, when you say that EKT is a way to =
distribute
> information, it is unclear why EKT doesn't violate layers.
>=20
> Done.
>=20
> =20
> I think that Section 2 (Overview) could be combined with Section 1
> (Introduction). Introduction sections in RFCs typically provide both
> background, problem statement and an overview of the mechanism - and =
sometimes
> also the document structure.
>=20
> Disagree.
> =20
> Q4_1:
>=20
> The text in section 4.1 says:
>=20
>    "EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
>    Identifier) or with SRTP's  [RFC3711], as those SRTP
>    features duplicate some of the functions of EKT.  Senders MUST NOT
>    include MKI when using EKT.  Receivers SHOULD simply ignore any MKI
>    field received if EKT is in use."
>=20
> I suggest to put this text in a dedicated Applicability section.
>=20
> Disagree.
> =20
> Q4-1_1:
>=20
> The text in section 4.1 says:
>=20
>    "Together, these data elements are called an EKT parameter set.  =
Each
>    distinct EKT parameter set that is used MUST be associated with a
>    distinct SPI value to avoid ambiguity."
>=20
> I suggest to defined "EKT parameter set" in the same way as the other
> terminology. I.e.,
>=20
>   "EKT parameter set: The parameters indicated by the SPI"
>=20
> .....or something like that.
>=20
> There's not a terminology section, so I didn't do exactly what you =
say.  But I pulled this out into a separate section so that it doesn't =
interrupt the flow, and clarified that the SPI-params association is set =
up by the DTLS-SRTP extension.
> =20
>=20
> Q4-2-1_1:
>=20
> For the section names of sections 4.2.1 and 4.2.2, I suggest to talk =
about
> sending/transmitting and receiving instead of inbound and outbound.
>=20
> Disagree
> =20
> Q4-3_1:
>=20
> In section 4.3, I  think the name of the section ("Implementation =
Notes") is a
> little confusing. Also, is there a reason why the text is not in =
section 4.2.1
> and/or 4.2.2?
>=20
> Just folded this into section 4.2.2.
>=20
> =20
> Q4-4_1:
>=20
> Sections 4.4 and 4.4.1 have the same section names. Please change one =
of them
> (e.g., change 4.4.1 to "Default Cipher").
>=20
> Changed to "AES Key Wrap"
>=20
> =20
> Q4-6_1:
>=20
> I think the text in section 4.6 should be placed in the Applicability =
section I
> suggested earlier (Q4_1).
>=20
> Merged it into section 4.
>=20
> =20
> Q5_1:
>=20
> In section 5, I  suggest to change the section name to "DTLS-SRTP
> Considerations".
>=20
> Disagree.
> =20
>=20
>=20
> _______________________________________________
> Perc mailing list
> Perc@ietf.org 
> https://www.ietf.org/mailman/listinfo/perc =

> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


--Apple-Mail=_5AD1B654-74D2-4BDB-88A0-E8E8826C3F44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Christer, thanks for your review. Richard, thanks for your =
responses. I entered a No Objection ballot.

Alissa

On Feb =
7, 2019, at 3:18 PM, Richard Barnes <rlb@ipv.sx> wrote:

Hi =
Christer,

Sorry,=
 just now seeing this.  Responses inline.  PR here:

https://github.com/ietf/perc-wg/pull/165

--RLB

On Sat, Oct 20, 2018 at 6:06 PM =
Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Reviewer: Christer Holmberg

Review result: Ready with Issues



I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments =
just

like any other last call comments.



For more information, please see the FAQ at



<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.



Document: draft-ietf-perc-srtp-ekt-diet-09

Reviewer: Christer Holmberg

Review Date: 2018-10-20

IETF LC End Date: 2018-11-01

IESG Telechat date: Not scheduled for a telechat



Summary: The document is well written, and easy to read. But, I think =
some

things still need to be clarified. I also have some editorial =
modification

suggestions.



Major issues:

--------------



Q1_1:



The text in section 1 says that EKT removes the need for co-ordinating =
SSRCs,

and that an endpoint can choose whatever value it wants.



However, I can't find any explanation on how EKT removes that need.

The answer is toward the end of the introduction: "EKT does =
not control the manner in which the SSRC is generated..." -- it just =
makes the distribution of security information easier..  I extended =
that paragraph to clarify.

 

Q1_3:



The text in section 1 says that EKT is not intended to replace key

establishment mechanisms, but to "be used in conjunction".



However, there is no description on how that works in conjunction with =
existing

mechanisms (e.g., together with SDP Offer/Answer), and whether =
existing

mechanisms need to be modified in order to work in conjunction with =
EKT.



Section 5.3 does say that the SDP O/A exchange is not affected. If that =
is

true, then you need to describe how SSRC values etc signalled in SDP =
relate to

values signalled using EKT, what happens if there are mismatches etc.

This document only defines one such augmentation -- the =
integration with DTLS-SRTP.  I extended the relevant part of the =
introduction to say this.

 

Minor issues:

--------------



Q1_2:



The text in section 1 says:



   "However, there are several cases in which conventional =
signaling systems

   cannot easily provide all of the coordination required."



I think some examples would be useful.

Disagree.
 

Q1_4:



The text in section 1 says that providing SSRCs etc using signaling =
systems

cause layer violations.



Is this layer violation described somewhere? If so, I think a reference =
would

be useful.

I just deleted this sentence..  It =
wasn't adding much.

 

Q4-2_1:



The text in section 4.2 says:



   "All of the received EKT parameter sets SHOULD be stored by =
all of the

   participants in an SRTP session, for use in processing =
inbound SRTP

   and SRTCP traffic."



What is the reason for SHOULD, instead of MUST? What happens if an =
endpoint

does NOT store the EKT parameter sets?

I think the SHOULD here =
is to allow, e.g., cache management.  Clarified the =
consequences.

 

Q4-2-1_2:



The text in section 4.2.1 says:



   "Outbound packets SHOULD continue to use the old SRTP =
Master Key for

   250 ms after sending any new key."



What is the reason for SHOULD, instead of MUST?

I don't think this should be a MUST.  For example, how =
accurately are you going to measure compliance?  If the change-over =
is 10ms short 10% of the time, is the endpoint out of compliance. Plus, =
there's minimal interop impact; this just helps things go smoothly.

 

Q4-3_2:



The text in section 4.3 says:



   "Section 4.2.1 recommends that SRTP senders continue using =
an old key

   for some time after sending a new key in an EKT tag."



The text in section 4.2.1 contains a SHOULD, so it is more than a

recommendation.

According to RFC 2119, a SHOULD is =
precisely a recommendation:

"""
3. SHOULD   This word, or =
the adjective "RECOMMENDED", mean that there
   =
may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must =
be understood and
   carefully weighed before =
choosing a different course.
"""

https://tools.ietf.org/html/rfc2119#section-3

 

Nits/editorial comments:

--------------------------



Q1_5:



I think Section 1 should also indicate that EKT is an DTLS extension, =
similar

to the Abstract. Otherwise, when you say that EKT is a way to =
distribute

information, it is unclear why EKT doesn't violate layers.

Done.

 

I think that Section 2 (Overview) could be combined with Section 1

(Introduction). Introduction sections in RFCs typically provide both

background, problem statement and an overview of the mechanism - and =
sometimes

also the document structure.

Disagree.
 

Q4_1:



The text in section 4.1 says:



   "EKT MUST NOT be used in conjunction with SRTP's MKI =
(Master Key

   Identifier) or with SRTP's <From, To> [RFC3711], as =
those SRTP

   features duplicate some of the functions of EKT.  =
Senders MUST NOT

   include MKI when using EKT.  Receivers SHOULD simply =
ignore any MKI

   field received if EKT is in use."



I suggest to put this text in a dedicated Applicability section.

Disagree.
 

Q4-1_1:



The text in section 4.1 says:



   "Together, these data elements are called an EKT parameter =
set.  Each

   distinct EKT parameter set that is used MUST be associated =
with a

   distinct SPI value to avoid ambiguity."



I suggest to defined "EKT parameter set" in the same way as the other

terminology. I.e.,



  "EKT parameter set: The parameters indicated by the SPI"



.....or something like that.

There's not a =
terminology section, so I didn't do exactly what you say.  But I =
pulled this out into a separate section so that it doesn't interrupt the =
flow, and clarified that the SPI-params association is set up by the =
DTLS-SRTP extension.
 


Q4-2-1_1:



For the section names of sections 4.2.1 and 4.2.2, I suggest to talk =
about

sending/transmitting and receiving instead of inbound and outbound.

Disagree
 

Q4-3_1:



In section 4.3, I  think the name of the section ("Implementation =
Notes") is a

little confusing. Also, is there a reason why the text is not in section =
4.2.1

and/or 4.2.2?

Just folded this into section 4.2.2.

 

Q4-4_1:



Sections 4.4 and 4.4.1 have the same section names. Please change one of =
them

(e.g., change 4.4.1 to "Default Cipher").

Changed to "AES Key =
Wrap"

 

Q4-6_1:



I think the text in section 4.6 should be placed in the Applicability =
section I

suggested earlier (Q4_1).

Merged it into section 4.

 

Q5_1:



In section 5, I  suggest to change the section name to =
"DTLS-SRTP

Considerations".

Disagree.
 





_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc



_______________________________________________
Gen-art =
mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

=

--Apple-Mail=_5AD1B654-74D2-4BDB-88A0-E8E8826C3F44--


From nobody Thu Feb 21 09:17:46 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB8130FFE; Thu, 21 Feb 2019 09:17:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155076945730.18457.277208716711107907.idtracker@ietfa.amsl.com>
Date: Thu, 21 Feb 2019 09:17:37 -0800
Archived-At: 
Subject: [Perc] Ben Campbell's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 17:17:37 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm adding a process discuss to hold things until we get clarity around the
IANA expert reviews.

I know Benjamin mentioned this in his DISCUSS; I am duplicating it here in case
we clear up the rest of Benjamin's discuss points prior to the IANA questions.





From nobody Thu Feb 21 09:57:54 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200DB131011 for ; Thu, 21 Feb 2019 09:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiBs4Cn9j4Kd for ; Thu, 21 Feb 2019 09:57:51 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25124130F99 for ; Thu, 21 Feb 2019 09:57:51 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id i12so31700664wrw.0 for ; Thu, 21 Feb 2019 09:57:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=7u5LuoN/ouBsYgUW7mVJrRHi5Ecj449kT7jkyR15V5s=; b=Yah0Ncsjdb88EQ3GkXpveacRciwJJWSA8msOwUYPAKh1dVA8It2LLsRSd8rATNlN+h NgSo9atpPZsBpCDXSH7f79zbrAVKg7YZwPh1sTG278XU5gPDiIDFINEUycsdffRpJiKs EJRFTq9uj0FeJo9dcAaxi+UeZArYNsZEplROMf0aszFfqr5ylgS60qK19BaqqYiONXLz /qH9awhipje6jw35HRsVStvXpzXgXX2iEgyZd/YciT80M6MMqkhj1Hqa0zeGKEpAgY9Q 9bVEFFu8FDwm2gJzxDbrLLyVUhcuApfEol+c0G/RR9QM/R30g5P1TzTqrzFgr/2ulvLZ 5Efw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=7u5LuoN/ouBsYgUW7mVJrRHi5Ecj449kT7jkyR15V5s=; b=KTSbHYywzrr8yysTTukAxW30a2J+ruubAPLDcpFkFNzPKJwtYtUrSIzby+8BzFT/EY eD+85aCDPM5xzpgJ2yCv66N0jMjNxs4wAJWWP5/5PtUKHkoLYdRQ84tpRsPbkjwhrhdH Y+ZqQbZidebIL668piFVdREczq8k1gaT07lJwTuR6SzYU23naj1viNbLFk2Ylt++maFi gvEmIDj/0kHWRFF+3PRWypVup6f48pbMBTvRAEQff1+52XTepQUZHj8YvCM6XDnjgPgy 3/nj46LMc9y1yYCzMtkslo4whh0rOm13gRCzI7dridZTm5QmbMrnYnVxwcAG5t1aR7w2 6NRA==
X-Gm-Message-State: AHQUAubckjFN5Ur38yLVnicWGdwl4CmIh4pQMZwkbORFqomKNo6YLH5E +re5KWbsT/Yfr3BfjpNAwULtaVyE
X-Google-Smtp-Source: AHgI3IYAJgN+jP/qmpobxYVRL0jJmx7qBfyxbGHc05QEUpzeAcliXwiqyiDb2VA4Pw2h1JxZVf1GQQ==
X-Received: by 2002:adf:8447:: with SMTP id 65mr28117747wrf.328.1550771869249;  Thu, 21 Feb 2019 09:57:49 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id 132sm25028587wmd.27.2019.02.21.09.57.48 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 09:57:48 -0800 (PST)
To: "perc@ietf.org" 
From: Sergio Garcia Murillo 
Message-ID: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com>
Date: Thu, 21 Feb 2019 19:02:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------7B41591198D2DED906317F9E"
Content-Language: en-US
Archived-At: 
Subject: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 17:57:53 -0000

This is a multi-part message in MIME format.
--------------7B41591198D2DED906317F9E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

In the media framework it is stated the following regarding SSRC 
splicing attacks:

    The splicing attack is an attack where a Media Distributor receiving
    multiple media sources splices one media stream into the other.  If
    the Media Distributor is able to change the SSRC without the receiver
    having any method for verifying the original source ID, then the
    Media Distributor could first deliver stream A and then later forward
    stream B under the same SSRC as stream A was previously using.  By
    not allowing the Media Distributor to change the SSRC, PERC mitigates
    this attack.

However, if BUNDLE and MID are used, and there is no ssrc signaling done 
in SDP, the following RTP demuxing rules from BUNDLE spec applies:

    If the packet has a MID, and the packet's extended sequence number
    is greater than that of the last MID update, as discussed in
    [RFC7941], Section 4.2.6  , update the MID associated with the RTP
    stream to match the MID carried in the RTP packet, then update the
    mapping tables to include an entry that maps the SSRC of that RTP
    stream to the "m=" section for that MID.

Given that MID is by definition HBH as it must match the negotiated SDP 
O/A, then the MD could arbitrarily change the MID for an RTP packet and 
associate it with whatever transceiver it wishes, effectively having the 
same effect than the SSRC splicing attack (at least in perc double where 
all participants share the same inner e2e key and there).

Best regards

Sergio



--------------7B41591198D2DED906317F9E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
In the media framework it is stated the following regarding SSRC
      splicing attacks:

    
   The splicing attack is an attack where a Media Distributor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.

    
However, if BUNDLE and MID are used, and there is no ssrc
      signaling done in SDP, the following RTP demuxing rules from
      BUNDLE spec applies:

    

    
   If the packet has a MID, and the packet's extended sequence number
   is greater than that of the last MID update, as discussed in
   [RFC7941], Section 4.2.6, update the MID associated with the RTP
   stream to match the MID carried in the RTP packet, then update the
   mapping tables to include an entry that maps the SSRC of that RTP
   stream to the "m=" section for that MID.


    
Given that MID is by definition HBH as it must match the
      negotiated SDP O/A, then the MD could arbitrarily change the MID
      for an RTP packet and associate it with whatever transceiver it
      wishes, effectively having the same effect than the SSRC splicing
      attack (at least in perc double where all participants share the
      same inner e2e key and there).

    

    
Best regards

    
Sergio

    

    



  


--------------7B41591198D2DED906317F9E--


From nobody Thu Feb 21 10:40:45 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10626131109; Thu, 21 Feb 2019 10:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2dnp2k8t6Kq; Thu, 21 Feb 2019 10:40:34 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7C0131108; Thu, 21 Feb 2019 10:40:34 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id q17so10218023uam.0; Thu, 21 Feb 2019 10:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hstXO3gfD3PZjl4wyWR00KlZxWi5k8k0UIB41XFYQQc=; b=g4Z2DukDbG2BfI578/5yvDWihJc+d0Jh3H5/WTP8dZTMyUHLXXzDRSBYOfnvnfnK2g PIKfE4n5eTzZzs51KSjjNmbAMSsasVFSsT26auzRtOTCBSffjrup4bdWG3aOYdX7zJ9N b0rRnWRw+o5HhMjzymMhZjpPJPJuibK5RvZksl18Tvm6dGJ5OoWX0KT7NpI2AVTxUAe2 JMcTfJAJbIJH8hq66Y36UZXVQxL2e9CJgADMXnJ02wAz6KGOZSyuCPtTfMGapvorEF0Y LvRC7I6RIAtBjtac69qI8UJtJSD6XUyTW9B3QmAVJPyKgCLnnG4HqEnVvjxUd3ScK4JI bSEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hstXO3gfD3PZjl4wyWR00KlZxWi5k8k0UIB41XFYQQc=; b=rXxYa5Pez8Idt5Q2jALxJtm99A3UuPFiLL1peqhI4x4Oo28Qu6QQW48Lvw1o7vOM2g VgYPlirf37SXGpB7FW037WuD3wVPskLByEWn/2+HWNQ5UBQboouivCxRt4rBx9CfE4E/ y2atbuL/uaA99L2RSwov7y9zncYqlJE0yLa0CexTpbqmwMUIJIIWmdY+blwH6UvG+z4o PKEqiC+sKEB+toWpDX1bLaxcsQLlo76SNsWLP2To2D91igwhpSoJyNE182Xo3WWGomvC 6a6GUSWA2Ny/X7/cOYmdADwkW8iqFPUhNff5UP5i9DUYmvcbYVq/NUcqDva1yuliZXd4 6B0Q==
X-Gm-Message-State: AHQUAuZYtiPMPqmYtUtvooytWuiH/6f9tyGezO3LRG97AvuGwlJGvFun ly59RgiTKz3aEdbsxSKFJQEWfLKQnO3y/yCPweo=
X-Google-Smtp-Source: AHgI3IY9H0YuRyQYeP6Q4qiHlesp05CCLpvn+1BCNkKd2cDqJUtNf8NHE3UGohrtcXTJDyfK/+lluWFzA38thUTvGz8=
X-Received: by 2002:a67:7a04:: with SMTP id v4mr17898356vsc.127.1550774432404;  Thu, 21 Feb 2019 10:40:32 -0800 (PST)
MIME-Version: 1.0
References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com>
In-Reply-To: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com>
From: Bernard Aboba 
Date: Thu, 21 Feb 2019 10:40:22 -0800
Message-ID: 
To: Sergio Garcia Murillo 
Cc: "perc@ietf.org" , IETF discussion list 
Content-Type: multipart/alternative; boundary="0000000000002b984505826bcfaa"
Archived-At: 
Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 18:40:36 -0000

--0000000000002b984505826bcfaa
Content-Type: text/plain; charset="UTF-8"

"By not allowing the Media Distributor to change the SSRC, PERC mitigates this
attack."

[BA] The security threat is mis-stated, and the "fix" is worse than the
problem.

In most situations modifying the SSRC will not represent an attack, just an
attempt on the part of the SFU to weave received simulcast streams together
to form a single stream so that an endpoint that does not support simulcast
reception can render it.  So the "fix" is inherently incompatible with
endpoints that can not receive simulcast, not a good tradeoff.

The actual threat to worry about is not "splicing" but "deep fakes" where
an attacker with access to cleartext audio and video can modify the media
(such as putting someone else's face on another body), while still
retaining synchronization between audio and video to make the "fake"
believable.  Addressing this kind of attack requires control of endpoint
access to cleartext media and recording APIs.  AFAICT, PERC does not
prevent this kind of attack because of key sharing.

"Given that MID is by definition HBH as it must match the negotiated SDP
O/A, then the MD could arbitrarily change the MID for an RTP packet and
associate it with whatever transceiver it wishes, effectively having the
same effect than the SSRC splicing attack (at least in perc double where
all participants share the same inner e2e key and there)."

[BA] MID modification is quite likely in scenarios such as "dominant
speaker" where the video (and audio) will switch between participants as
they take turns speaking.  Again, in most situations, this does not
constitute an attack, and where it does, PERC will not be of much help.

On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> In the media framework it is stated the following regarding SSRC splicing
> attacks:
>
>    The splicing attack is an attack where a Media Distributor receiving
>    multiple media sources splices one media stream into the other.  If
>    the Media Distributor is able to change the SSRC without the receiver
>    having any method for verifying the original source ID, then the
>    Media Distributor could first deliver stream A and then later forward
>    stream B under the same SSRC as stream A was previously using.  By
>    not allowing the Media Distributor to change the SSRC, PERC mitigates
>    this attack.
>
> However, if BUNDLE and MID are used, and there is no ssrc signaling done
> in SDP, the following RTP demuxing rules from BUNDLE spec applies:
>
>    If the packet has a MID, and the packet's extended sequence number
>    is greater than that of the last MID update, as discussed in
>    [RFC7941], Section 4.2.6 , update the MID associated with the RTP
>    stream to match the MID carried in the RTP packet, then update the
>    mapping tables to include an entry that maps the SSRC of that RTP
>    stream to the "m=" section for that MID.
>
> Given that MID is by definition HBH as it must match the negotiated SDP
> O/A, then the MD could arbitrarily change the MID for an RTP packet and
> associate it with whatever transceiver it wishes, effectively having the
> same effect than the SSRC splicing attack (at least in perc double where
> all participants share the same inner e2e key and there).
>
> Best regards
>
> Sergio
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>

--0000000000002b984505826bcfaa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


"By not allowing the Media Distributor to change=
 the SSRC, PERC mitigates=C2=A0this attack."

[BA] The security threat is mis-stated, and the "fix" is w=
orse than the problem.=C2=A0

In most situations mo=
difying the SSRC will not represent an attack, just an attempt on the part =
of the SFU to weave received simulcast streams together to form a single st=
ream so that an endpoint that does not support simulcast reception can rend=
er it.=C2=A0 So the "fix" is inherently incompatible with endpoin=
ts that can not receive simulcast, not a good tradeoff.=C2=A0
The actual threat to worry about is not "splicing" bu=
t "deep fakes" where an attacker with access to cleartext audio a=
nd video can modify the media (such as putting someone else's face on a=
nother body), while still retaining synchronization between audio and video=
 to make the "fake" believable.=C2=A0 Addressing this kind of att=
ack requires control of endpoint access to cleartext media and recording AP=
Is.=C2=A0 AFAICT, PERC does not prevent this kind of attack because of key =
sharing.=C2=A0

"Given that MID is by definiti=
on HBH as it must match the negotiated SDP O/A, then the MD could arbitrari=
ly change the MID for an RTP packet and associate it with whatever transcei=
ver it wishes, effectively having the same effect than the SSRC splicing at=
tack (at least in perc double where all participants share the same inner e=
2e key and there)."

[BA] MID modification is =
quite likely in scenarios such as "dominant speaker" where the vi=
deo (and audio) will switch between participants as they take turns speakin=
g.=C2=A0 Again, in most situations, this does not constitute an attack, and=
 where it does, PERC will not be of much help.=C2=A0

On Thu, Feb 21, 2=
019 at 9:57 AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

 =20

   =20
 =20
  

    
In the media framework it is stated the following regarding SSRC
      splicing attacks:

    
   The splicing attack is an attack where a Media Distri=
butor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.

    
However, if BUNDLE and MID are used, and there is no ssrc
      signaling done in SDP, the following RTP demuxing rules from
      BUNDLE spec applies:

    

    
   If the packet has a MID, and the packet's extende=
d sequence number
   is greater than that of the last MID update, as discussed in
   [RFC7941], Section=C2=A04.2.6, update the MID associated with t=
he RTP
   stream to match the MID carried in the RTP packet, then update the
   mapping tables to include an entry that maps the SSRC of that RTP
   stream to the "m=3D" section for that MID.


    
Given that MID is by definition HBH as it must match the
      negotiated SDP O/A, then the MD could arbitrarily change the MID
      for an RTP packet and associate it with whatever transceiver it
      wishes, effectively having the same effect than the SSRC splicing
      attack (at least in perc double where all participants share the
      same inner e2e key and there).

    

    
Best regards

    
Sergio

    

    

  


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




--0000000000002b984505826bcfaa--


From nobody Thu Feb 21 12:33:51 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE692131173; Thu, 21 Feb 2019 12:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaA7xc1P2CJV; Thu, 21 Feb 2019 12:33:40 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DBA130E7F; Thu, 21 Feb 2019 12:33:40 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id r5so18722334wrg.9; Thu, 21 Feb 2019 12:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AJp/Xn4gTec9Q0Z2DDXIwphAHA+JJTsFoCaBRdyxELs=; b=aVwaLiz/iXR1F7n7h6sXHZfLOemQbrTr39OsY9RiZRoBTwWgn8zbgkcZ9mURkreLYn 3Iw6L2PxHaIREA7fFwSSEwctoossb7/3G/zuLJCQF0YH3Fav1TklT4rem92ha6S0vzBd opFJOeGiwwuzwphbJQHyIvW6IxY2BlWDstXZ5af3cESmDmr+Tt9iBA6zZSbY8m0Uu9VE O6Qij2jcwYBUkNHDxp9TbI8zmClKGeu6JH9zMGyvUi1gRlbp6L2qDDkt0nKNp0TVJx7y bif7L5OyRxDyd/4g4io7KuRT91Tj0bDWJC3n+opS5xe6A2F/1Zhh55+YOz+tjlbecpZD y0lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AJp/Xn4gTec9Q0Z2DDXIwphAHA+JJTsFoCaBRdyxELs=; b=qB2JNg7MC8uMI/wCeFGi9FoETh82J8NY8i8YNlFGJf/yI7Hlq1rSugaumXKtzJ5KQL 74SPuFUKXwqIO42fnwBkeA14uGu5+43poXkGOd0TjzGYWu4t1aNQ6Aro1zdOQShsZ3s1 y/avfL6pm7+qV99y5//Nm3oNXxVPYcTGtImQe3SL298/mVEAFyccJM4ul6QYPzN1SeIN yzISfUK1b4EWLqSsJ75SVRf1pNWQMP/7yimZ5QJQ50HXF8GaxFy5sPy8UJY8Y44EIB2H m3wsw9m5ArYO8549MrnaLPZPerLxxXItZWDK7FYYvaWtqTK5XKYV5ztUzA5DYrLOolVA TWPA==
X-Gm-Message-State: AHQUAua2pDUqPA14oEC6gNwKV4GFZO+5RqOOqu2DxWfVS6dN4RALc7c0 7PT6AiE1fhTr+oOn2GJUOojPpYJm
X-Google-Smtp-Source: AHgI3IZ22TqZGOHhuWwrVb3mLDa4AZFECT+inwqYyqo4l7t4CPj3dh7/UMoo3KJVQP/XmRn4ba0Sng==
X-Received: by 2002:adf:9e0c:: with SMTP id u12mr266042wre.216.1550781218326;  Thu, 21 Feb 2019 12:33:38 -0800 (PST)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id z15sm10066234wmi.46.2019.02.21.12.33.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 12:33:37 -0800 (PST)
To: Bernard Aboba 
Cc: "perc@ietf.org" , IETF discussion list 
References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <15025cff-4aa9-c33f-0b90-0fc8610efcdb@gmail.com>
Date: Thu, 21 Feb 2019 21:38:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------ED98D3BEAAEFC4EBFD4259BF"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2019 20:33:43 -0000

This is a multi-part message in MIME format.
--------------ED98D3BEAAEFC4EBFD4259BF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Fully agree:

- The attack is not an attack but normal SFU behavior (the attack would 
be impersonation and/or deep fakes)
- Trying to prevent it, PERC forbids to rewriting ssrc which break most 
known SFUs up to date
- The attack is not prevented

IMHO PERC fails for WebRTC because it is not truly end to end, just 
browser to browser, as it doesn't take into consideration the role of 
the js app.

Only a e2ee solution integrated with IdP and isolated media streams 
which allows the receiver to assert the identity of the received packet 
would prevent impersonation and deep fakes. Without it, the user *MUST* 
trust the js application so that it doesn't send the media to an 
alternative server or create deep fakes as Bernard is stating.

Best regards
Sergio


On 21/02/2019 19:40, Bernard Aboba wrote:
> "By not allowing the Media Distributor to change the SSRC, PERC 
> mitigates this attack."
>
> [BA] The security threat is mis-stated, and the "fix" is worse than 
> the problem.
>
> In most situations modifying the SSRC will not represent an attack, 
> just an attempt on the part of the SFU to weave received simulcast 
> streams together to form a single stream so that an endpoint that does 
> not support simulcast reception can render it.  So the "fix" is 
> inherently incompatible with endpoints that can not receive simulcast, 
> not a good tradeoff.
>
> The actual threat to worry about is not "splicing" but "deep fakes" 
> where an attacker with access to cleartext audio and video can modify 
> the media (such as putting someone else's face on another body), while 
> still retaining synchronization between audio and video to make the 
> "fake" believable. Addressing this kind of attack requires control of 
> endpoint access to cleartext media and recording APIs.  AFAICT, PERC 
> does not prevent this kind of attack because of key sharing.
>
> "Given that MID is by definition HBH as it must match the negotiated 
> SDP O/A, then the MD could arbitrarily change the MID for an RTP 
> packet and associate it with whatever transceiver it wishes, 
> effectively having the same effect than the SSRC splicing attack (at 
> least in perc double where all participants share the same inner e2e 
> key and there)."
>
> [BA] MID modification is quite likely in scenarios such as "dominant 
> speaker" where the video (and audio) will switch between participants 
> as they take turns speaking.  Again, in most situations, this does not 
> constitute an attack, and where it does, PERC will not be of much help.
>
> On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo 
>  > wrote:
>
>     In the media framework it is stated the following regarding SSRC
>     splicing attacks:
>
>         The splicing attack is an attack where a Media Distributor receiving
>         multiple media sources splices one media stream into the other.  If
>         the Media Distributor is able to change the SSRC without the receiver
>         having any method for verifying the original source ID, then the
>         Media Distributor could first deliver stream A and then later forward
>         stream B under the same SSRC as stream A was previously using.  By
>         not allowing the Media Distributor to change the SSRC, PERC mitigates
>         this attack.
>
>     However, if BUNDLE and MID are used, and there is no ssrc
>     signaling done in SDP, the following RTP demuxing rules from
>     BUNDLE spec applies:
>
>         If the packet has a MID, and the packet's extended sequence number
>         is greater than that of the last MID update, as discussed in
>         [RFC7941], Section 4.2.6  , update the MID associated with the RTP
>         stream to match the MID carried in the RTP packet, then update the
>         mapping tables to include an entry that maps the SSRC of that RTP
>         stream to the "m=" section for that MID.
>
>     Given that MID is by definition HBH as it must match the
>     negotiated SDP O/A, then the MD could arbitrarily change the MID
>     for an RTP packet and associate it with whatever transceiver it
>     wishes, effectively having the same effect than the SSRC splicing
>     attack (at least in perc double where all participants share the
>     same inner e2e key and there).
>
>     Best regards
>
>     Sergio
>
>     _______________________________________________
>     Perc mailing list
>     Perc@ietf.org 
>     https://www.ietf.org/mailman/listinfo/perc
>


--------------ED98D3BEAAEFC4EBFD4259BF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Fully agree:

    


    

    
- The attack is not an attack but
      normal SFU behavior (the attack would be impersonation and/or deep
      fakes)

    

    
- Trying to prevent it, PERC forbids to
      rewriting ssrc which break most known SFUs up to date

    

    
- The attack is not prevented

    


    

    
IMHO PERC fails for WebRTC because it
      is not truly end to end, just browser to browser, as it doesn't
      take into consideration the role of the js app. 

    

    


    

    
Only a e2ee solution integrated with
      IdP and isolated media streams which allows the receiver to assert
      the identity of the received packet would prevent impersonation
      and deep fakes. Without it, the user *MUST* trust the js
      application so that it doesn't send the media to an alternative
      server or create deep fakes as Bernard is stating. 

    


    

    
Best regards

    
Sergio

    


    

    


    

    
On 21/02/2019 19:40, Bernard Aboba
      wrote:

    

    

      
      
"By not allowing the Media Distributor to change the SSRC, PERC mitigates this attack."
        


        

        
[BA] The security threat is mis-stated, and the "fix" is
          worse than the problem. 

        


        

        
In most situations modifying the SSRC will not represent an
          attack, just an attempt on the part of the SFU to weave
          received simulcast streams together to form a single stream so
          that an endpoint that does not support simulcast reception can
          render it.  So the "fix" is inherently incompatible with
          endpoints that can not receive simulcast, not a good
          tradeoff. 

        


        

        
The actual threat to worry about is not "splicing" but
          "deep fakes" where an attacker with access to cleartext audio
          and video can modify the media (such as putting someone else's
          face on another body), while still retaining synchronization
          between audio and video to make the "fake" believable. 
          Addressing this kind of attack requires control of endpoint
          access to cleartext media and recording APIs.  AFAICT, PERC
          does not prevent this kind of attack because of key sharing. 

        


        

        
"Given that MID is by definition HBH as it must match the
          negotiated SDP O/A, then the MD could arbitrarily change the
          MID for an RTP packet and associate it with whatever
          transceiver it wishes, effectively having the same effect than
          the SSRC splicing attack (at least in perc double where all
          participants share the same inner e2e key and there)."

        


        

        
[BA] MID modification is quite likely in scenarios such as
          "dominant speaker" where the video (and audio) will switch
          between participants as they take turns speaking.  Again, in
          most situations, this does not constitute an attack, and where
          it does, PERC will not be of much help. 

      

      

      

        
On Thu, Feb 21, 2019 at 9:57
          AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
          wrote:

        

        

          

            
In the media framework it is stated the following
              regarding SSRC splicing attacks:

            
   The splicing attack is an attack where a Media Distributor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.

            
However, if BUNDLE and MID are used, and there is no ssrc
              signaling done in SDP, the following RTP demuxing rules
              from BUNDLE spec applies:

            

            
   If the packet has a MID, and the packet's extended sequence number
   is greater than that of the last MID update, as discussed in
   [RFC7941], Section 4.2.6, update the MID associated with the RTP
   stream to match the MID carried in the RTP packet, then update the
   mapping tables to include an entry that maps the SSRC of that RTP
   stream to the "m=" section for that MID.


            
Given that MID is by definition HBH as it must match the
              negotiated SDP O/A, then the MD could arbitrarily change
              the MID for an RTP packet and associate it with whatever
              transceiver it wishes, effectively having the same effect
              than the SSRC splicing attack (at least in perc double
              where all participants share the same inner e2e key and
              there).

            

            
Best regards

            
Sergio

            

          

          _______________________________________________

          Perc mailing list

          Perc@ietf.org

          https://www.ietf.org/mailman/listinfo/perc

        

      

    

    


    

  


--------------ED98D3BEAAEFC4EBFD4259BF--


From nobody Sat Feb 23 18:11:13 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FA212D4EC for ; Sat, 23 Feb 2019 18:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMLyu7aCEbqZ for ; Sat, 23 Feb 2019 18:11:08 -0800 (PST)
Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2EB12D4ED for ; Sat, 23 Feb 2019 18:11:08 -0800 (PST)
Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 454123E96; Sat, 23 Feb 2019 21:11:07 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id CC82F3DEA;  Sat, 23 Feb 2019 21:11:06 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 23 Feb 2019 21:11:07 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_94C13F5C-CB08-447B-9ADC-DED270074C8A"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Cullen Jennings 
In-Reply-To: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com>
Date: Sat, 23 Feb 2019 19:11:00 -0700
Cc: "perc@ietf.org" 
Message-Id: <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca>
References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com>
To: Sergio Garcia Murillo 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Feb 2019 02:11:11 -0000

--Apple-Mail=_94C13F5C-CB08-447B-9ADC-DED270074C8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo =
 wrote:
>=20
> In the media framework it is stated the following regarding SSRC =
splicing attacks:
>=20
>    The splicing attack is an attack where a Media Distributor =
receiving
>    multiple media sources splices one media stream into the other.  If
>    the Media Distributor is able to change the SSRC without the =
receiver
>    having any method for verifying the original source ID, then the
>    Media Distributor could first deliver stream A and then later =
forward
>    stream B under the same SSRC as stream A was previously using.  By
>    not allowing the Media Distributor to change the SSRC, PERC =
mitigates
>    this attack.
> However, if BUNDLE and MID are used, and there is no ssrc signaling =
done in SDP, the following RTP demuxing rules from BUNDLE spec applies:
>=20
>    If the packet has a MID, and the packet's extended sequence number
>    is greater than that of the last MID update, as discussed in
>    [RFC7941], Section=C2=A04.2.6 =
, update the MID =
associated with the RTP
>    stream to match the MID carried in the RTP packet, then update the
>    mapping tables to include an entry that maps the SSRC of that RTP
>    stream to the "m=3D" section for that MID.
> Given that MID is by definition HBH as it must match the negotiated =
SDP O/A, then the MD could arbitrarily change the MID for an RTP packet =
and associate it with whatever transceiver it wishes, effectively having =
the same effect than the SSRC splicing attack (at least in perc double =
where all participants share the same inner e2e key and there).
>=20
>=20

No, it would not have the same effect at all.=20



--Apple-Mail=_94C13F5C-CB08-447B-9ADC-DED270074C8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

In the media framework it is stated =
the following regarding SSRC splicing attacks:
   The splicing attack is an attack where a =
Media Distributor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.
However, if =
BUNDLE and MID are used, and there is no ssrc signaling done in SDP, the =
following RTP demuxing rules from BUNDLE spec applies:
   If the packet =
has a MID, and the packet's extended sequence number
   is greater than that of the last MID update, as discussed in
   [RFC7941], Section 4.2.6, update the MID associated =
with the RTP
   stream to match the MID carried in the RTP packet, then update the
   mapping tables to include an entry that maps the SSRC of that RTP
   stream to the "m=3D" section for that MID.

Given that MID is =
by definition HBH as it must match the negotiated SDP O/A, then the MD =
could arbitrarily change the MID for an RTP packet and associate it with =
whatever transceiver it wishes, effectively having the same effect than =
the SSRC splicing attack (at least in perc double where all participants =
share the same inner e2e key and there).


No, it would not have the same effect at =
all. 


=

--Apple-Mail=_94C13F5C-CB08-447B-9ADC-DED270074C8A--


From nobody Sun Feb 24 00:01:34 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B690129441 for ; Sun, 24 Feb 2019 00:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOBYWb5jlgUE for ; Sun, 24 Feb 2019 00:01:30 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8065E124B0C for ; Sun, 24 Feb 2019 00:01:29 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id z7so4672857lji.0 for ; Sun, 24 Feb 2019 00:01:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=POb4c1rDP1d4Q40EdkbuKktlJ2xBLCkHdprP7Nkw8Tw=; b=fZt/Ci+uqi/7KhmHLOzeCkUm6Hqqijfum/GX46Ds/dz4y7KMl28hQBcT51tQQiS7Xh hS6sSpVydW8B9ZACXgG5OlbRtSMKYFb7+ECO2MtbTHIGSUVdbb926da7je4/MuHh3FN0 q1zg2TqsENRBrKNJZjuDkdUivhoNrt21BQj6J1UUT5Bf4xmgdYO28TD2AbLtPpMIT3ym E6UJlxn7l4FWWRnkcRuFbSmPvym2Kk9HFy74KXSxIQvlQJFZFlbPeSd0IjEIhv20w8V3 aMwTjhtghvLgOrX4cjPS46cZMfKBEYqch7RrmtYtpGPgsvs0UeX00xAhwrdDOGc3AY/K d9sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=POb4c1rDP1d4Q40EdkbuKktlJ2xBLCkHdprP7Nkw8Tw=; b=DqZLO6TaAFqWGP98LKjBunPGG2kXmPSpMcRhtRyWZv3IzFKSHnoEWpp2cLG2YWT9f+ n/YrNJq4aVNYB7iX9kDYeyt56EjEyhDuhQPVVtXIiZm72qQuWnWrLhSj0M/uWunbFtf6 oa37oQZUIiHhEzB7QcD2HQAil0l367aqDKf3bxeDsv3uBAKJIGi3t3a4SkLyop8A4HDA yew1FfbP4D8q9I+Ht6RtBzuO8So37rYU93yl6HnwdufIw9Hh3k7uLjUq8JrUm2PwjIHP sYo/koqsiVC72+qrTFUtUOAx0dOUjHq1+uyWRTsco6eYEBKQZIoIMf/YyqGyBrQqsnKn UzGQ==
X-Gm-Message-State: AHQUAuaz0QPWQA64E5MUxiJ+/GAxPTWKBn+up1Ai5jNjm3UMSNkfd+uC 2W9Kkzig79WRQxye+P387cvQnzyC0dQjQGizctU=
X-Google-Smtp-Source: AHgI3IYKPlucjU7N/vKHxkJT5LkFTMEhmcMcItgE0iZ045WMjhYBwOhKF5READyR2BBewKP1N9HYNCqvnqhtcOC3kyQ=
X-Received: by 2002:a2e:92ce:: with SMTP id k14-v6mr6854828ljh.154.1550995287398;  Sun, 24 Feb 2019 00:01:27 -0800 (PST)
MIME-Version: 1.0
References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca>
In-Reply-To: <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca>
From: Alexandre GOUAILLARD 
Date: Sun, 24 Feb 2019 16:01:43 +0800
Message-ID: 
To: Cullen Jennings 
Cc: Sergio Garcia Murillo , "perc@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000002765e605829f3bee"
Archived-At: 
Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Feb 2019 08:01:33 -0000

--0000000000002765e605829f3bee
Content-Type: text/plain; charset="UTF-8"

Cullen,

Would you mind to give more detail as to why you think it's different? From
where we stand, both approaches end-up deceiving the receiver into
believing some media is coming from one source while it's not. With that
definition of "effect", both the src splicing attack and Sergio proposed
attack have the same effect.
Agreed, PERC addresses the case where it is due to SSRC manipulation, but
if it does not address the other ways to achieve the same effect, it still
fail at protecting the receiver, at the perceived huge cost of removing the
capacity to support other important use cases cited before.

Do you have an implementation of PERC, as promised at IETF'99, for us and
others to test against?

Beyond the difference, do you think that the scenario sergio proposed:
- is a real problem ?
- should be addressed ?

Sergio,
feel free to prepare a working demo to make your point. If I understand
correctly, what you propose can be done today already quite easily.





On Sun, Feb 24, 2019 at 10:11 AM Cullen Jennings  wrote:

>
>
> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo <
> sergio.garcia.murillo@gmail.com> wrote:
>
> In the media framework it is stated the following regarding SSRC splicing
> attacks:
>
>    The splicing attack is an attack where a Media Distributor receiving
>    multiple media sources splices one media stream into the other.  If
>    the Media Distributor is able to change the SSRC without the receiver
>    having any method for verifying the original source ID, then the
>    Media Distributor could first deliver stream A and then later forward
>    stream B under the same SSRC as stream A was previously using.  By
>    not allowing the Media Distributor to change the SSRC, PERC mitigates
>    this attack.
>
> However, if BUNDLE and MID are used, and there is no ssrc signaling done
> in SDP, the following RTP demuxing rules from BUNDLE spec applies:
>
>    If the packet has a MID, and the packet's extended sequence number
>    is greater than that of the last MID update, as discussed in
>    [RFC7941], Section 4.2.6 , update the MID associated with the RTP
>    stream to match the MID carried in the RTP packet, then update the
>    mapping tables to include an entry that maps the SSRC of that RTP
>    stream to the "m=" section for that MID.
>
> Given that MID is by definition HBH as it must match the negotiated SDP
> O/A, then the MD could arbitrarily change the MID for an RTP packet and
> associate it with whatever transceiver it wishes, effectively having the
> same effect than the SSRC splicing attack (at least in perc double where
> all participants share the same inner e2e key and there).
>
>
> No, it would not have the same effect at all.
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>


-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

--0000000000002765e605829f3bee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Cullen,

Would you mind to give more det=
ail as to why you think it's different? From where we stand, both appro=
aches end-up deceiving the receiver into believing =
some media is coming from one source while it's not. With that d=
efinition of "effect", both the src splicing attack and Sergio pr=
oposed attack have the same effect.
Agreed, PERC addresses the ca=
se where it is due to SSRC manipulation, but if it does not address the oth=
er ways to achieve the same effect, it still fail at protecting the receive=
r, at the perceived huge cost of removing the capacity to support other imp=
ortant use cases cited before.

Do you have an impl=
ementation of PERC, as promised at IETF'99, for us and others to test a=
gainst?

Beyond the difference, do you think that t=
he scenario sergio proposed:
- is a real problem ?
- sh=
ould be addressed ?

Sergio,
feel free to=
 prepare a working demo to make your point. If I understand correctly, what=
 you propose can be done today already quite easily.





On Sun, Feb 24, 2019 at 10:11 AM=
 Cullen Jennings <fluffy@iii.ca>=
 wrote:


On Feb =
21, 2019, at 11:02 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com<=
/a>> wrote:

In t=
he media framework it is stated the following regarding SSRC splicing attac=
ks:
=
   The splicing attack is an attack where a Media Distributor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.
H=
owever, if BUNDLE and MID are used, and there is no ssrc signaling done in =
SDP, the following RTP demuxing rules from BUNDLE spec applies:
   If the p=
acket has a MID, and the packet's extended sequence number
   is greater than that of the last MID update, as discussed in
   [RFC7941], Section=C2=A04.2.6, update the MID associated with t=
he RTP
   stream to match the MID carried in the RTP packet, then update the
   mapping tables to include an entry that maps the SSRC of that RTP
   stream to the "m=3D" section for that MID.

Given that MID i=
s by definition HBH as it must match the negotiated SDP O/A, then the MD co=
uld arbitrarily change the MID for an RTP packet and associate it with what=
ever transceiver it wishes, effectively having the same effect than the SSR=
C splicing attack (at least in perc double where all participants share the=
 same inner e2e key and there).


No, it wo=
uld not have the same effect at all.=C2=A0


_______________________________________________

Perc mailing list

Perc@ietf.org

https://www.ietf.org/mailman/listinfo/perc




-- 
Alex. Gouaillard, PhD, PhD, MBA
-------------=
-----------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
---------=
---------------------------------------------------------------------------=




--0000000000002765e605829f3bee--


From nobody Thu Feb 28 04:34:43 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CEB129741; Thu, 28 Feb 2019 04:34:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-perc-double@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155135728186.28740.798781663201721215.idtracker@ietfa.amsl.com>
Date: Thu, 28 Feb 2019 04:34:41 -0800
Archived-At: 
Subject: [Perc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-perc-double-10=3A_=28with_COMMENT=29?=
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 12:34:42 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-perc-double-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-double/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would believe that it would be useful to add a reference to RFC3550,
especially as PT, SEQ, and M are referenced. Maybe even spell out what those
abbreviations mean. Also maybe the doc could say a little more why it is
important for an MD to be able to modify these values (given the original
values have to be attached for decryption purposes anyway)...?