From nobody Mon Jun 4 21:40:18 2018 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 DEE99130EBA; Mon, 4 Jun 2018 21:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 YJZSw0FAHApu; Mon, 4 Jun 2018 21:40:14 -0700 (PDT) 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 16768130EB9; Mon, 4 Jun 2018 21:40:10 -0700 (PDT) Received: from [10.0.1.83] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w554e7b0028479 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Jun 2018 23:40:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.83] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_A2F5B906-17AF-4744-8F6B-7BEF336E8124"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <5AFC524E-7C2A-4C8F-B66B-7BAA3F048403@nostrum.com> Date: Mon, 4 Jun 2018 23:40:06 -0500 Cc: perc@ietf.org To: draft-ietf-perc-double.all@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Perc] AD Evaluation of draft-ietf-perc-double-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 04:40:17 -0000 --Apple-Mail=_A2F5B906-17AF-4744-8F6B-7BEF336E8124 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this = work; I think it is important and on the right track, but suffers from = some readability issues, especially from =C2=A77 onwards. I=E2=80=99d = like to discuss my comments prior to IETF last call. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94 *** Substantive Comments *** General: Does it make sense to progress this prior to = draft-ietf-perc-private-media-framework rather than wait and progress = them together? it seems like one really needs to read the framework to = understand at least parts of this draft. (Which would, btw, suggest = making the framework a normative reference.) =C2=A72, Media Distributor: Should this be defined as switch-based? = Otherwise it seems circular. =C2=A75 and subsections: These sections are confusing in the treatment = of extensions. =C2=A75.1 step 3 says to truncate the header to remove = any extensions. Yet other sections of text repeatedly mention the = handling of extensions. I think the document needs a paragraph or two to = describe the handling of RTP extensions at a high level. Along those lines, it=E2=80=99s not entirely clear what is meant by = putting =E2=80=9C (12 + 4 * CC bytes)=E2=80=9D in parentheses after the = guidance to truncate in =C2=A75.1. Is that the amount to be truncated? = Amount left after truncation? (Same question for =C2=A75.3) =C2=A75.2: It would be helpful to include a paragraph or two to describe = the impact if multiple MDs modify the same field(s). I can infer that, = but it would be better to be explicit. (IIRC, there is a passing mention = in the security considerations, but it would be better to have more = here.) =C2=A78: Can you offer any guidance about selecting 128 vs 256? =C2=A79: - The security considerations mainly summarize the mechanism. I=E2=80=99d = like to see a description of the potential attacks or risks and how the = double mechanism mitigates them. - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection. = However, if future specifications define header extensions that needs = e2e integrity protection, the input to inner transform may be modified = to consider including the header.=E2=80=9D - 2nd paragraph: Why is the HBH key for an outgoing packet only = =E2=80=9Ctypically=E2=80=9D different than the key for the incoming = packet? Are there security implications if they are the same? - 2nd to last paragraph, last sentence: Please elaborate on those risks? *** Editorial comments and nits *** There are a number of abbreviations that need to be expanded on first = use. Please remember that abbreviations should be expanded both in the = abstract and the body. - SRTP - SSRC - SEQ - ROC - PRF - PT - SEQ - RTX - RED - FEC =C2=A72: - Please use the boilerplate from RFC8174. There are a number of lower = case instances of normative keywords. - Please use consistent sentence (or lack of sentence) structure for the = definitions in the bullet list. =C2=A73, - " Generate key and salt values of the length required for the combined = inner (end-to-end) and outer (hop-by-hop) algorithms.=E2=80=9D: The = document is inconsistent in whether it describes a single key with inner = and outer halves, or separate inner and outer keys. I realize that this = is an artifact of syntax, but it is likely to confuse a reader new to = the topic. - Paragraph starting with =E2=80=9CObviously, if the Media = Distributor=E2=80=A6=E2=80=9D: =E2=80=9CObviously=E2=80=9D is a null = word in context. =C2=A73.1: This section would be much more approachable if you defined = the terms (such as n, k, and x), rather than forcing readers to look = them up in 3711. Also, the doubled crypto suite IDs are likely to be = confusing to the reader who sees them here without the explanation later = in the draft. =C2=A75.2, step 2: =E2=80=9CChange any parts of the RTP packet=E2=80=A6=E2= =80=9D -The MS is limited to changing the 3 fields defined for the OHB, = right, at least as defined in this draft? Not just anything it wants? =C2=A75.3, last two paragraphs: It=E2=80=99s sort of an odd construction = to talk about =E2=80=9Cany of the following=E2=80=9D with a single entry = list. =C2=A77 and subsections: These could use another proofreading pass. In = particular, it is imprecise about inner vs outer encryption, which = actors do what, and has a number of pronouns with ambiguous antecedents. = The heavy use of passive voice obscures the actors in multiple places. I = will call out some specifics, but please do not treat my comments as = exhaustive. =C2=A77: =E2=80=9C The repair mechanism, when used with double, = typically operates on the double encrypted data and encrypts them using only the HBH key.=E2=80=9D Does =E2=80=9Cdouble = encrypted=E2=80=9D mean =E2=80=9Couter encrypted=E2=80=9D? Also, while I = recognize =E2=80=9Cdata=E2=80=9D as plural, it=E2=80=99s plural in a = non-countable sense; that is, s / them / it. =C2=A77.1: - =E2=80=9C =E2=80=A6 cached payloads MUST be the encrypted packets = =E2=80=A6=E2=80=9D - Inner or outer? What device enforces this? = (Consider active voice.) - Which element represents =E2=80=9Cthe other side=E2=80=9D? Are we = talking about an endpoint or MD? (Please stick to the defined = terminology) - =E2=80=9C When encrypting a retransmission packet, it MUST be = encrypted the packet in repair mode.=E2=80=9D - I can=E2=80=99t parse = the phrase after the comma. Also, what device MUST encrypt it? =C2=A77.2: - =E2=80=9Cthe primary encoding MAY contain=E2=80=A6=E2=80=9D - Is that = MAY a grant of permission or a statement of fact? - " The sender takes encrypted payload from the cached packets=E2=80=9D- = Missing article for encrypted payload? Or should this say =E2=80=9C=E2=80=A6= takes encrypted packets from the cached payload=E2=80=A6=E2=80=9D? - =E2=80=9C Any header extensions from the primary encoding are copied = to the RTP packet that will carry the RED payload and the other RTP = header information such as SSRC, SEQ, CSRC, etc are set to the same as = the primary payload. The RED RTP packet is then encrypted in repair = mode and sent.=E2=80=9D: This is confusing; parts are copied from the = primary encoding and others are the same as in the primary encoding? = Don=E2=80=99t both of those mean the same thing? - =E2=80=9C The receiver decrypts the payload=E2=80=A6=E2=80=9D: = Endpoint or MD? Is this inner or outer encryption? - Last paragraph: Seems like that belongs in the FEC section. Also, does = this document really need to make that sort of recommendation? It seems = like a general statement about RED and FEC that is not specific to = double. =C2=A77.3: - "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with = double, the negotiation of double for the crypto is the out of band = signaling that indicates that the repair packets MUST use the order of = operations of SRTP followed by FEC when encrypting.=E2=80=9D - The = sentence is hard to parse. Also, is MUST a normative requirement or a = statement of fact? (It seems odd to signal that you MUST do something). - =E2=80=9C=E2=80=A6 data, which is already encrypted, it MUST be = encrypted in repair mode packet.=E2=80=9D s/ =E2=80=9C, which=E2=80=9D / = =E2=80=9Cthat=E2=80=9D. Also, what actor MUST encrypt the data in repair = mode? (Consider active voice.) - =E2=80=9C The algorithm recommend=E2=80=A6=E2=80=9D s / recommend / = recommended =C2=A77.4: - s/ "sent with [RFC4733]=E2=80=9D / =E2=80=9Csent using the mechanism = in [RFC4733]=E2=80=9D - =E2=80=9C and the relay can not read it so it cannot be used=E2=80=9D = - missing comma between =E2=80=9Cit=E2=80=9D and =E2=80=9Cso=E2=80=9D. =C2=A78, last paragraph: =E2=80=9C For packets in repair mode, the data = they are caring is often already encrypted further increasing the = size.=E2=80=9D - I assume =E2=80=9Ccaring=E2=80=9D is not the intended = word. Did you mean =E2=80=9Ccarrying=E2=80=9D? If so, consider s / = =E2=80=9Cdata they are carrying=E2=80=9D / =E2=80=9Cdata they carry=E2=80=9D= . =C2=A79: - =E2=80=9C... all the RTP fields except headers created by the = sender=E2=80=A6=E2=80=9D Does that mean all the fields created by the = sender except headers? Or all the fields other than the headers created = by the sender? - s/ + / and - =E2=80=9C=E2=80=A6 this shouldn=E2=80=99t typically impact the = strength of e2e integrity given the fact that there doesn=E2=80=99t = exist header extensions defined today that needs e2e protection.=E2=80=9D = - hard to parse - " However, if future specifications define header extensions that = needs e2e integrity protection, the input to inner transform may be = modified to consider including the header.=E2=80=9D s/ =E2=80=9Cconsider = including the header=E2=80=9D / =E2=80=9Cinclude the header=E2=80=9D - s/ =E2=80=9CIt is obviously critical=E2=80=9D / =E2=80=9CIt is = critical=E2=80=9D - =E2=80=9C=E2=80=A6 the outer (hop-by-hop) algorithm key and not the = half of the key =E2=80=A6 =E2=80=9C inconsistent in talking about H2H = key vs half-key. - 11: It=E2=80=99s awkward to use =E2=80=9CThank you=E2=80=9D when = addressing 3rd persons. I suggest something like =E2=80=9CThanks for =E2=80= =A6 go to =E2=80=A6=E2=80=9D or =E2=80=9CThe authors would like to = thank =E2=80=A6 for=E2=80=A6=E2=80=9D - 12.2: It seems like some of these need to be normative: = [I-D.ietf-payload-flexible-fec-scheme], maybe = [I-D.ietf-perc-private-media-framework], and [RFC4733]. - Appendix A: Why is this relegated to an appendix? I think would be = helpful in the main body of the document. --Apple-Mail=_A2F5B906-17AF-4744-8F6B-7BEF336E8124 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsWFCYACgkQgFZKbJXz 1A3oxRAApg/MEIxcdO8fYjA1VYwaiwy0mCR1QzL/jgNBQNJH+q2npo4WPvsPqWTu 25r2snQDenWeVp+S4nIITB1UEpFOV0BsjUjUy0I4/8w8J7A1URoJ+WVqI0O/4WPy h4MxiIRtkoWu7wRw6/GUgL11Ymz2zpyXVxL+SVXeoALvXLVzUufkWOeMUpm9qtn6 T4XLd8W1KYWd0hZOwguqZJVLOIg2JE6QoHVsPe/v96Z3HMxIoZm4s0rYdeg3A7AU 9nKrbKr3M2cwnstcMjR7b4Yg9FXQyYLCBoo7JOivd5jDDbX/Ps+KRiLcMmhMxDgI ZpLIOlxc+zYbnSY3bejbjLv7a3yGwQfVfLnf1gMAwjdTLxBuXQx2IJG+EWHA/jDO dwBwh0Usrik9AvqQGBgL1CZ9mVy8eij3olZeGZNmbT1/+yJGTo3YfGoEM+s84F4k PNh/Q5ZIBSBFA/pm1oysFGSX6QqE56Bv5HYWae5RBdSslNoibE0zd/DnkjpukN4M 4DaA6oO8hQ6lLDtEnI8JJt9r00FvZhOMtOkzlb0MlgeAsNsYqUdbfkTQhdp4E224 lu5UdVqYu5RtJW1HSlw+RgpbfzN0LjMf6Bp1ieYWBCtmVMiI+VfQonlwWu4kmiCH 94A9XkbbdWXVP7GEHrv+R5VxlCDd84L9Cap1KlsbhPHu9RDYK9o= =zpa0 -----END PGP SIGNATURE----- --Apple-Mail=_A2F5B906-17AF-4744-8F6B-7BEF336E8124-- From nobody Fri Jun 15 11:39:04 2018 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 42C0B130F1E for ; Fri, 15 Jun 2018 11:38:54 -0700 (PDT) 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 IRtX0-FPNPMz for ; Fri, 15 Jun 2018 11:38:51 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 6AB52130F34 for ; Fri, 15 Jun 2018 11:38:51 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id a5-v6so7003187uao.8 for ; Fri, 15 Jun 2018 11:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=k/Cmyxn0azQGUuabNQ6Jitgry8s7o9XbglWCJZ8hd0U=; b=jihzYtJsXPqYCYtXPShYobW4ZiAdZBtj3LSXJMwE9gUNFsAxmjNdfF6QvfLMIv7vqH jfgFf14nobuUonQPJExnfuBbDWQvrv9JR9dbIFMqvuodMe+uB8cjb2YOcEiWxBF0W5Iw 3OJH3rLvs13XSpIzTE1FsVTTvO4O0iF5Afjz3imfeJSVB+UugcXOC+arU1jHELPI6419 TcfSQT4zCoebXSaWvLKe2Mukk/E6uz7tnb3qe2Pe/up8VxxtSW2w+5IY7dPxIdwsfAQL DTL1uixiEBcQeguubaNh5OIHpcWigaSX5zg9yviGsE2FOF5W2PF1MxDmxPuwCr9mpQ3X 4AmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k/Cmyxn0azQGUuabNQ6Jitgry8s7o9XbglWCJZ8hd0U=; b=t2akKlNDh22nolP5pHunU8XsPOglQdi8M6eHQAIG7tMmtxQrIcln9unhgMEUBygJpq FAUQPLMZBmLLDrbgkn5Ne1/UAhcem3/4W0TkpgTd88ADWk5ujQy2GdjE9Ck6sa65Dc4z rLs7QTZpn7CFXaFAvxpgJi1uMKwGZ+KmTbtfBEmNxcDbWV9Y6zQAVS5ie6V1+JRpWQc8 VnTNSPW0WY8Egu4RKryOtiEZ5g6CR6JQqr6kr9g4Yz39D61UGZzMBWlsOtO4GQjnpOBF cngrAVO2EXV7SSBbTrX0uVZ9YkKSWZu6i3oxFd7X/O0qqaQt/nq1iPQxx3bg8QWYVqK6 oRQQ== X-Gm-Message-State: APt69E2GUcD7t7apPR3k5ZwXc1oYHhp50lMC3fMi3uafzCCGgTZGL3OE 7M6LSdJZSVSyiXRaO4Ac38BIp1sJ8F+ixWdaOM+nksAh X-Google-Smtp-Source: ADUXVKIlqaj+xgpBnWQD8mToqQbhIU+OCPcupABq5G64xfzFFub3hBGLd3gZwtjJ7hAlkAujRxaXVFjqXI8x+YqkKnI= X-Received: by 2002:ab0:5278:: with SMTP id j53-v6mr1864434uaa.7.1529087929840; Fri, 15 Jun 2018 11:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:1d19:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 11:38:29 -0700 (PDT) From: Bernard Aboba Date: Fri, 15 Jun 2018 11:38:29 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="000000000000e37773056eb2863d" Archived-At: Subject: [Perc] Question about draft-ietf-perc-private-media-framework X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 18:39:03 -0000 --000000000000e37773056eb2863d Content-Type: text/plain; charset="UTF-8" The W3C WEBRTC WG has been discussing potential future APIs for enabling scenarios discussed in draft-ietf-perc-private-media-framework That discussion raises some questions about API implications for browser security. For example, the following paragraph from Section 2 says that the browser is a trusted entity: 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 Section 3.2.1, it says that an "endpoint" is assumed to be trusted: An endpoint is considered trusted and will have access to E2E key information. While it is possible for an endpoint to be compromised, subsequently performing in undesired ways, defining endpoint resistance to compromise is outside the scope of this document. Endpoints will take measures to mitigate the adverse effects of denial of service attacks (refer to Section 6 ) from other entities, including from other endpoints, to a level equal to or better than traditional conference (i.e., non-PERC) deployments. However, in Section 3.1 it says that the "conferencing infrastructure" is not trusted: The conferencing infrastructure in such a domain is still trusted with reliably connecting the participants together in a conference, but not trusted with keying material needed to decrypt any of the participant's media. So is a Javascript application considered to be an "endpoint" or part of the "conferencing infrastructure"? If the JS generates an Electron or React application, I might lean toward the "endpoint" interpretation. However, if this is JS downloaded from the conferencing provider, and running in a browser, it would seem to be part of the "conferencing infrastructure" just like the MDD. In that case, access to e2e keys or cleartext media would appear to be prohibited, right? --000000000000e37773056eb2863d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The W3C WEBRTC WG has been discussing potential future API= s for enabling scenarios discussed in=C2=A0draft-ietf-perc-private-media-fr= amework

That discussion raises some questions about API = implications for browser security.=C2=A0

For examp= le, the following paragraph from Section 2 says that the browser is a trust= ed entity:=C2=A0

   Trusted Endpoint: An RTP flow termi=
nating 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 Section 3.=
2.1, it says that an "endpoint" is assumed to be trusted:=C2=A0




   An endpoint is considered trusted a=
nd will have access to E2E key
   information.  While it is possible for an endpoint to be compromised,
   subsequently performing in undesired ways, defining endpoint
   resistance to compromise is outside the scope of this document.
   Endpoints will take measures to mitigate the adverse effects of
   denial of service attacks (refer to Section 6) fro=
m other entities,
   including from other endpoints, to a level equal to or better than
   traditional conference (i.e., non-PERC) deployments.






However, in Section 3.1 it says that the &q=
uot;conferencing infrastructure" is not trusted:=C2=A0

   The conferencing infrastructure in
   such a domain is still trusted with reliably connecting the
   participants together in a conference, but not trusted with keying
   material needed to decrypt any of the participant's media.






So is a Javascript application considered to be an "endpoint&qu=
ot; or part of the "conferencing infrastructure"?=C2=A0 If the JS=
 generates an Electron or React application, I might lean toward the "=
endpoint" interpretation.=C2=A0 However, if this is JS downloaded from=
 the conferencing provider, and running in a browser, it would seem to be p=
art of the "conferencing infrastructure" just like the MDD.=C2=A0=
 In that case, access to e2e keys or cleartext media would appear to be pro=
hibited, right?
--000000000000e37773056eb2863d-- From nobody Fri Jun 15 14:06:25 2018 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 E401A126CB6 for ; Fri, 15 Jun 2018 14:06:23 -0700 (PDT) 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 8PWJcQ2ht6yY for ; Fri, 15 Jun 2018 14:06:21 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 DFB37130E6A for ; Fri, 15 Jun 2018 14:06:20 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id c15-v6so12469378otl.3 for ; Fri, 15 Jun 2018 14:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TeswNOBb2LXiFZhH2pJlAmaOeTMgVqiRTp4YcGRMcfk=; b=Vw8Oorx1y3xJif38y+lhuLYZzIU5vhbdBSKgKPAmjUZs7vxWM3cUE90W6GsyBai+y/ m39i4Tm3Ii98PacJxhozBfACODEiLO5xkaai5o+Yj5pg2Gq3Rv07jmDNgzJD28ErXOsc 1YTUk758NNvrsTh1Y9W66qMlffyE0cJ5K1PYs0SXczpQTFsh6svt4UlRVEvPjFVVLz0z ORdcaYzT2n8LSlswO3ipvuzKeIbN7XnmDBE9JYYWyf09dyxQUa9CYN0K+3rkx0jOX1Rk W0FBHUT2w2AxbG2GZlwhe4dRSZ5+dhBlNhtpRzmzc8tFkN4rdT5pCqUdN5rJJ6JjwyJs ziZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TeswNOBb2LXiFZhH2pJlAmaOeTMgVqiRTp4YcGRMcfk=; b=ryioIjHUjFb3Vs+R8kDnXU3CHVmV1Xy2Q4Bmdyorh8w8iEaTCXLB+sX8v66QmpJRyq eCtMMXyDUTlF0P6lYkzre0Sn6xy8PD5QOQR2OCJWlXPb73ZENGsdhD0pqPELQixMRCNf 9lnvJmE7JFaDe4YDcNKDf2UfrwIuIlGDiWugdvYeBJJ2HhBEv3WsKZ7rkCPIQH5OgM4J WU0KxeuWWNdE7YRiAMCdxqFEdKgfoff1bV1uImQJHP6LJ01wy7E4dW6PVjVv2oEjk5zt +FSzhBuF7oB0AFcMYc9jLXyTTG8AmEERnFULFwjxaQ5v7Wo23z+HiStuMNFpvkxwVrXK zZWQ== X-Gm-Message-State: APt69E1W2RIyvCqt2O0l7ela2jvXvA+TJRTflm/f0VDm7glU2OQj3G2j sqOkyqLGn159ra8etl9q5L3wysAP6FLlaUtZCIQ9ZA== X-Google-Smtp-Source: ADUXVKJQVE4Rc0bZc/V3xXwwm1trz5JcDpQUW1xe8ZF9LiAbU5/dMNof3Rl5vhKQE4hW0nRfRo0fVLANcHLNMxaecaY= X-Received: by 2002:a9d:e2a:: with SMTP id c39-v6mr2138778otc.241.1529096780016; Fri, 15 Jun 2018 14:06:20 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Fri, 15 Jun 2018 14:06:12 -0700 Message-ID: To: perc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Perc] Related work X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 21:06:24 -0000 Folks, The MMUSIC working group has a draft that might be interesting to this group. They are currently looking for more reviews of draft-ietf-mmusic-sdp-uks This affects PERC to the extent that confusion about identity affects who has keys. Thanks, Martin From nobody Fri Jun 15 14:58:26 2018 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 3A917130E59 for ; Fri, 15 Jun 2018 14:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, UNPARSEABLE_RELAY=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=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 oT95mQZePbLS for ; Fri, 15 Jun 2018 14:58:21 -0700 (PDT) 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 3BB5012426A for ; Fri, 15 Jun 2018 14:58:21 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1529099899; bh=UKM9+gVIWfB+y4VZ94ll5VcuGqlBxonkifajQgUmazs=; h=Date:In-Reply-To:References:Subject:To:From; b=HBGJWNBCvxk67kk7Xdff6PBYP8aMLbtW6bDGzSrfGEsYpB6x9pMQ4re4AJWAuI2al jk9TC4EPKU5Z3wVg1VK8oPKU+7OmU3RzwjkN7DagnyZEdFKlsYN3zqlyASi4kgU2Js ULdCKvI7FMAiY7rNj03nBEXz0vJ/ewzCHbhIZSXs= Date: Sat, 16 Jun 2018 05:58:09 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----09GHSQOQEXH0SM5MWIOMHESFCSE5D1" Content-Transfer-Encoding: 7bit Autocrypt: addr=paulej@packetizer.com; keydata=mQQNBFHlwHIBIADPBuXxiC7IP3Aco lod+D4BWYKBDGgyX90mexkDt6Wi6D2LJlpadGp99NgG9Oc4m9QDEPPuhRHKvgexNAxAeILUZlOX6 m/30n83VuwGNZagxjawN9/Kv4WrLlDI+HSZeKwfVf8GBus/jB6c5WQtV6/L7LYCQLU08dWng8NlB i6dupyWC1rhtNWnPCqS4C3nINWJRx4grfIvkI5PbDMPca/BiluZxy0XntHuNWf51Gj4IIIAK2QNW QwDLaDnZ774Q1HfMTt4u4UwivsOt9Z49w92Q6FuN7/3sve7DwrEVtp0xCKqaBQOX2354VVOTMh0b hHGLprQ1BL3QAWlyg/ZkTs+kopd3h+mJ0Mkg3Es66umcG8UYbH+edmZ7mHWqHuWmNieEycZgmah6 kfrb7lUZeJnkkLfZ6SS3fhJIhJq3RwTKfvyF9LNvnZ7XXsOVSBKvVFPHWuDe3tbglTZCEYIcdFot gMcpZatdJF0ZPdLPGECc/XCZOgQpICGZ6b0dt/uJKOPC1OYRlFfIWc9bDgRCQY0MCqTsYiGevMNd QTlZHgTactm4h886bETFdbSoDniPls7LuI3cAr++iHmF56ohwh9Hl8KVzsv+uSL1mmrfE/X+lEaJ nPUrQopByFQySE4D+hvOFLNh2iv7BHyXX9G0Dv9jDB6hW+61RYBf23GRZWSEVMyoYfbbU7Tg5JNr VRLU7nUMVbla2fGIKz9K3ejtCy/35QAjt7DIrVVe9k9J54rZ1yD8ZXfQXv869/q/mHGVzxdtgO+P crIXJYck8R7jSDB2wIo3g5z+2P3Lt2gvB4w9UUSNZ4deE95MNc6FvqqTMlBzoxzBf2E+SoUZKTl4 i48XJhKI+Bk71NnMug2ER2NbyQIg6aH7l4t4t38mK6yt/cd00f8UtKxp7z2EnqXJ+/kx0pq9zECp 76oAPv9JlInntbcl89jRS4qMAMgZFEy6sYOMftfhVgDkci/JR+2s4V65aUxcR6PLtXRHg3ZZ2F4h EBkBxJQt4LZ6lWzMXuWkCfjca032WOq/Zl+RMrs18dywVohDXqSaYoSCzkfeCbzTE4cCuE8o9FUx 7B/nS6g+h0wvrGDcLeGIwVWYO+Q0gf+vbLq2ZfykWjS5Fa3ZKLdEOWaNas/8UlW33lU3u9nj84dJ gMcP/VAugd8N9QWJ9NKszL8689NmwQnzoIU43+ucRd0WgCAWgXtV6MmG2WUpKN6y/ARqis6NvKTp l/t7SMznBxZGg2ZUC7pBpT/cq6vi18+tWP1ghRGJgJJ4t6vD64fBQTAaaN9MxU46OIlcWtjvf5zz L0pwebYOdInN/wA7YOOK3Q/wQsPaD5dvY+6H9yrCLMBwGyRl3TB/bsaYqtFABEBAAG0JVBhdWwgR S4gSm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbT6JBDgEEwECACIFAlOH4kACGy8GCwkIBwMCB hUIAgkKCwQWAgMBAh4BAheAAAoJEHropU4WcvKlpF4gAI34iWlJY84nB8y12sqLldU0d9rSnk6eu OYf7HIIJ8yHGCHVkQJUksjcwPOAr/zw4XjftSEv8JN3PDLpkhvQ2snEIZ7UPFafUmbq3BQLPkN0M pamx7br7vpLwpRMwbPyWYc4Z0+Ag4t6p/01troi++v3DLDNAjAov/Q526pL7qFkIJpadMcVcTEgr 5XEsVVxw5TbGrqyDwam+aNIVcxDNxzOG4nFJ1bjUGAeoRcVJnz0X0CQUFzxgMceyjuqI3Qyj5kp3 gZkoibJyfZ6/6FFVV5dGAlHluL52H6KiUAkWPf0qbGo6ELuxsnSX9JPVUtr14B6HfZP8kWX740Hu 2yBQTAxhsfhhsR4LNUxKcdNFSJ/Ozpo3i7fvek3CF+ash7l25JAkI+1TH4kh7dYpndwTWwXDNqTM QR+I+JtsKgATpx/pBWaNK0zvWKuxjoM/CVn4NPWf9aqfdF3wvTq5EMDarQ8Leou0LsKLKZsJHYYx FlMlD37/+q4UsIy5iPatNl8qm4YM4LykjvB+Ozsd3OZ3z+buSdJ+6QwOnje21tPLhSI8dEIw8S+D Kl+80I/2bEd3+wKptHcB0NU3OF9B3N1ClOp7wFIrgsQ0pTHA2pchxWyC9pngYhErJS6nZaQeWwrN 7VH9RkS2SPPkAzf5N27ayky2rF8nDZrkO1OuXCaH9gyi2CQfJEtbAPMXfAJo5Ls0trEMqQGDAW3/ GxCo5NoX70bXjPd+NXBIYBaC9dc6Iyqei3xQJNsE2vtPEo3glJaE3mFMpUOILqQkU8hjs3+J1rNk pkmaoenlvbDVUqM0TVGzHFJlPtLXR/DsDjgjk1uaS+xIlD0exwLp3/Bgs4nXAQ1UYlPOLC/BokUP wAuSuUrCAYHfAzwsynIgI8j/EHeKgyjyuQ4f1uIlzy63rVd8QVvGt6qV2hO0Bj4FzIMG9xG4KZ7c PziHmAh5tR0PbV35vJLww3HbmL6LzC5CaB2cYkLuOL4BuhUD+b20GiThhtYaPBQr49NBNViCB+Rl hojKIS4Ou9+ngg2L4EWe6rY0yzR+BWPBvNtZNantozb49PuIcYhfxzWFjK7Gt6zlQeUfsBGtdjR1 p4emdH4c/VFdzj4bNPtKv56mkUrcFQpE1vym/PPYyvG3wBzUXF/d/W5NqojZmuQLO+GfMPo2sbT3 V0LTELlfRfzOstA7SpdQgYpMoRQwErxIwn2lUVjt6DjXeaRoOkQgYAgQqHYLrWef6gYLy05xHEN6 Ow6t7VDxuZOtjrJqQ3oyfcyR9EsyAET8CvSSaHABOaqWOiwE+TzU9/42ei0Qph08xL8BQMQVsnOJ ZLM8DMNWzWB3wVxCaVil+unNTnmw7mjClcPFuBjFyc= To: perc@ietf.org, Bernard Aboba From: "Paul E. Jones" Message-ID: <927AFC00-D54E-4A7F-8DD6-A8789E21AA7D@packetizer.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (dublin.packetizer.com [172.30.5.58]); Fri, 15 Jun 2018 17:58:19 -0400 (EDT) X-Scanned-By: MIMEDefang 2.84 Archived-At: Subject: Re: [Perc] Question about draft-ietf-perc-private-media-framework X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 21:58:25 -0000 ------09GHSQOQEXH0SM5MWIOMHESFCSE5D1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What has been discussed in meetings before is that people didn't want to ex= tend trust to the JS layer responsible for rendering the UI or used to init= iate PERC calls=2E The desire is to ensure that layer doesn't have access t= o the keys=2E Thus, the downloaded JS that you're referencing is special=2E It's part of= the endpoint, in my mind, that's not trusted=2E Paul -------- Original Message -------- From: Bernard Aboba Sent: June 16, 2018 2:38:29 AM GMT+08:00 To: perc@ietf=2Eorg Subject: [Perc] Question about draft-ietf-perc-private-media-framework The W3C WEBRTC WG has been discussing potential future APIs for enabling scenarios discussed in draft-ietf-perc-private-media-framework That discussion raises some questions about API implications for browser security=2E For example, the following paragraph from Section 2 says that the browser is a trusted entity: Trusted Endpoint: An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption=2E 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=2E In Section 3=2E2=2E1, it says that an "endpoint" is assumed to be trusted: An endpoint is considered trusted and will have access to E2E key information=2E While it is possible for an endpoint to be compromised, subsequently performing in undesired ways, defining endpoint resistance to compromise is outside the scope of this document=2E Endpoints will take measures to mitigate the adverse effects of denial of service attacks (refer to Section 6 ) from other entities, including from other endpoints, to a level equal to or better than traditional conference (i=2Ee=2E, non-PERC) deployments=2E However, in Section 3=2E1 it says that the "conferencing infrastructure" is not trusted: The conferencing infrastructure in such a domain is still trusted with reliably connecting the participants together in a conference, but not trusted with keying material needed to decrypt any of the participant's media=2E So is a Javascript application considered to be an "endpoint" or part of the "conferencing infrastructure"? If the JS generates an Electron or React application, I might lean toward the "endpoint" interpretation=2E However, if this is JS downloaded from the conferencing provider, and running in a browser, it would seem to be part of the "conferencing infrastructure" just like the MDD=2E In that case, access to e2e keys or cleartext media would appear to be prohibited, right? ------09GHSQOQEXH0SM5MWIOMHESFCSE5D1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable What has been discussed in meetings before is that= people didn't want to extend trust to the JS layer responsible for ren= dering the UI or used to initiate PERC calls=2E The desire is to ensure tha= t layer doesn't have access to the keys=2E

Thus, the downloaded JS that you're referencing is special=2E It's= part of the endpoint, in my mind, that's not trusted=2E

Paul

From: Bernard Aboba <bernard=2Eaboba@gmail=2Ecom>
Sent: June 16, 2018 2:38:29 AM GMT+08:00
To: perc@ietf=2Eorg
Subject: [Perc] Question about draft-ietf-perc-private-media-framew= ork

The W3C WEBRTC WG has been discussing potential future AP= Is for enabling scenarios discussed in draft-ietf-perc-private-media-f= ramework

That discussion raises some questions about API= implications for browser security=2E 

For ex= ample, the following paragraph from Section 2 says that the browser is a tr= usted entity: 

   Trusted Endpoint: An RTP flow te=
rminating entity that has possession
   of E2E media encryption keys and terminates E2E encryption=2E  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=2E

<=
span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sm=
all;white-space:normal;background-color:rgb(255,255,255);text-decoration-st=
yle:initial;text-decoration-color:initial;float:none;display:inline">In Sec=
tion 3=2E2=2E1, it says that an "endpoint" is assumed to be trusted: <=
/span>




   An endpoint is considered truste=
d and will have access to E2E key
   information=2E  While it is possible for an endpoint to be compromised,
   subsequently performing in undesired ways, defining endpoint
   resistance to compromise is outside the scope of this document=2E
   Endpoints will take measures to mitigate the adverse effects of
   denial of service attacks (refer to Section 6=
) from other entities,
   including from other endpoints, to a level equal to or better than
   traditional conference (i=2Ee=2E, non-PERC) deployments=2E






However, in Section 3=2E1 it says that t=
he "conferencing infrastructure" is not trusted: 

   The conferencing infrastructure in
   such a domain is still trusted with reliably connecting the
   participants together in a conference, but not trusted with keying
   material needed to decrypt any of the participant's media=2E






So is a Javascript application considered to be an "endpoint" or pa=
rt of the "conferencing infrastructure"?  If the JS generates an Elect=
ron or React application, I might lean toward the "endpoint" interpretation=
=2E  However, if this is JS downloaded from the conferencing provider,=
 and running in a browser, it would seem to be part of the "conferencing in=
frastructure" just like the MDD=2E  In that case, access to e2e keys o=
r cleartext media would appear to be prohibited, right?
=
------09GHSQOQEXH0SM5MWIOMHESFCSE5D1--