From nobody Mon Jan 14 15:11: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 48D4212DF72; Mon, 14 Jan 2019 15:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 V8sk65RlEUI0; Mon, 14 Jan 2019 15:11:37 -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 A0F9612D84D; Mon, 14 Jan 2019 15:11:34 -0800 (PST) Received: from [10.0.1.45] (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 x0ENBWBE056746 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 17:11:33 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547507494; bh=lOPHpwJ+B4szZDcIXbF/Mq54Dgq829croCrgPgubpWc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=pOOGtx14Fk2pa1szqTuPvaUmwuFXGmOU9o+Jh/HkanioztiIMOdNRH3vJWflLNbga IMjNiEfM/209zKhwCrY8GtKrjKJZEl8cuk6uF2Bz0pGipHnH8ckfGAFD5eDYvUW9hh 4evD2ll4hMCVrtSvT9qzIxAcrGDETUAu6t1SR07U= 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.45] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9ED3B02B-5240-43D5-9A75-D5026877AFD9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 17:11:32 -0600 In-Reply-To: <8F9C11FD-9CCD-48DD-96E8-286CA2569626@nostrum.com> Cc: perc@ietf.org To: draft-ietf-perc-private-media-framework.all@ietf.org References: <8F9C11FD-9CCD-48DD-96E8-286CA2569626@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-private-media-framework-07 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: Mon, 14 Jan 2019 23:11:40 -0000 --Apple-Mail=_9ED3B02B-5240-43D5-9A75-D5026877AFD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, What=E2=80=99s the status of getting an update? It would be nice to get = this through IETF LC and the IESG evaluation before Prague. Thanks! Ben. > On Oct 22, 2018, at 2:47 PM, Ben Campbell wrote: >=20 > Hi, >=20 > This is my AD Evaluation of = draft-ietf-perc-private-media-framework-07. >=20 > I appreciate all the work that has gone into this, but I think this = draft still needs some work before the IETF last call. I have some = substantive and significant editorial comments that I would like to = resolve prior to the LC. >=20 > Thanks! >=20 > Ben. >=20 > ------------------------- >=20 > Substantive Comments: >=20 > =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together = better. It says the ability to deploy in virtual environments is an = advantage, but the rest of the paragraph seems to argue why doing so is = insecure. I _think_ the idea is to say that this draft helps improve = that security, thus helping remove a barrier to taking advantage of = virtual/cloud environments? If so, please say so. >=20 > =C2=A72: Please use the new boilerplate from RFC 8174. There are = multiple uses of lower-case =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=E2=80= =9D in the document that don=E2=80=99t appear to be intended as = normative. >=20 > =C2=A72, definition of MD: It seems like this definition is a little = too focused on the PERC trust model, and leaves out the definition of it = as a middlebox that forwards the active stream without modification. (I = guess that=E2=80=99s caught in the reference to 7667, but it would be = better to include the core of the definition here, rather than imply it = by reference. >=20 > =C2=A73.1.1: "The actual > media content MUST NOT not be decryptable by a Media Distributor, so > it is untrusted to have access to the E2E media encryption keys.=E2=80=9D= >=20 > I=E2=80=99m not sure that MUST NOT should be stated normatively, as = it=E2=80=99s really a statement of fact, or at least a foundational = assumption. >=20 > =C2=A73.1.1, paragraph 3: "A Media Distributor MUST perform its role = in properly forwarding > media packets while taking measures to mitigate the adverse effects > of denial of service attacks (refer to Section 6), etc, to a level > equal to or better than traditional conferencing (i.e. non-PERC) > deployments.=E2=80=9D >=20 > That requirement is too vague for a normative MUST. Consider leaving = the normative language to section 6. >=20 > =C2=A73.1.2, last paragraph: "In any deployment scenario where the = call processing function is > considered trusted, the call processing function MUST ensure the > integrity of received messages before forwarding to other entities.=E2=80= =9D >=20 > Please describe why that is important in a PERC environment. >=20 > =C2=A74.2, first paragraph: "participants in the conference > MUST keep track of the E2E keys=E2=80=9D >=20 > This seems redundant to similar requirement in 4.3. The requirements = in 4.3 are more precise, so I suggest stating this one descriptively. >=20 > =C2=A74.3: "prior E2E keys SHOULD be retained=E2=80=9D >=20 > I think there=E2=80=99s some disagreement internal to this document, = and between this and EKT (and maybe double?). Please see related comment = 0n section 4.5.2: >=20 > =C2=A74.4: First paragraph: "this framework requires that every packet = be authenticated=E2=80=9D: Is that a statement of fact that this = framework states a normative requirement elsewhere, or is it this = intended to be a normative requirement in itself? >=20 > =C2=A74.4, 2nd paragraph: "Using hop-by-hop authentication gives the = Media Distributor the > ability to change certain RTP header values.=E2=80=9D > That=E2=80=99s not really a true statement. It=E2=80=99s the lack of = E2E authentication that enables that. It seems like the real point is = that, since we can=E2=80=99t use E2E authentication, HBH authentication = is better than nothing. >=20 > =C2=A74.4, 3rd paragraph: "If there is a need to encrypt one or more = RTP header extensions hopby- > hop, ...=E2=80=9D : Is that optional? >=20 > =C2=A74.4, last paragraph: "Note that when RTP header extensions are = encrypted, > all hops - in the untrusted domain at least - will need to decrypt > and re-encrypt these encrypted header extensions.=E2=80=9D >=20 > I=E2=80=99m confused by this; the document requires distinct keys for = each hop. is there an exception for trusted MDs? >=20 > =C2=A74.5.1, > - 2nd to last paragraph: "Endpoints MAY use the DTLSSRTP > generated E2E key for transmission or MAY generate a fresh E2E > key.=E2=80=9D: They have to do one or the other, right? That wording = allows then to do neither. >=20 > - Last paragraph: It would be helpful to describe the security = associations involved. Do I understand correctly that an endpoint has an = SA with the KD, but not the MD? But peer MDs do have SAs with each = other? >=20 > =C2=A74.5.2, 3rd paragraph: >=20 > I think there=E2=80=99s some disagreement on the normative keywords = for delaying the switch to new keys. I discussed this offline with = Richard, and he replied with the following: >=20 >> There's sort of a conflict here. The crux is here: >>=20 >> """ >> Since it may take some time for all of the >> endpoints in conference to finish re-keying, senders MUST delay a >> short period of time before sending media encrypted with the new >> master key, but it MUST be prepared to make use of the information >> from a new inbound EKT Key immediately. >> """ >>=20 >> The first part talks about media keys, which conflicts with EKT; it = should probably be deleted. The second part is about processing EKT = tags, and should be kept. So we probably end up with something like the = following: >>=20 >> """ >> In order to allow time for all endpoints in the conference to = receive the new keys, >> the sender should follow the recommendations in Section XXX of = [I-D.ietf-perc-srtp-ekt-diet]. >> On receiving a new EKT Key, endpoints MUST be prepared to decrypt = EKT tags using the >> new key. The EKT SPI field can be used to differentiate between = tags encrypted with >> the old and new keys. >> """ >=20 > =C2=A75.2, 2nd paragraph: If the fingerprint is signed, does the = entire signaling network still need to be trusted? Also, should the = reference to 4474 be 8224? >=20 > =C2=A76: This is written in forward-looking language about how the = framework needs to be designed. That design is complete now, what are = the considerations for it=E2=80=99s use as designed? >=20 > Also, there are considerations for attacks other than DOS attacks, = right? >=20 > =C2=A76.2.1: This section seems odd to me. I understand not trusting = the MD to keep communication confidential or to not tamper with it, etc. = But if the MD wants to deny service, it can find much easier ways. For = example, simply not forwarding packets. >=20 > =C2=A7A.1: "Assuming the use of Double...=E2=80=9D > Is that optional? >=20 > - "The media distributor doesn=E2=80=99t perform DTLS-SRTP,...=E2=80=9D >=20 > The document describes one case where it does (connections between = peer MDs) >=20 > =C2=A7A.3: "To reduce complexity, PERC > *RECOMMENDS* that endpoints create random SRTP master keys locally to > be used for E2E encryption.=E2=80=9D >=20 > Is RECOMMENDS intended as normative? If not, where is the actual = recommendation? >=20 > Editorial Comments: >=20 > - General: I found the draft to have some issues with flow and = fragmentation. I expected this draft give a big-picture overview tying = together the moving parts of PERC in a way that tells me how they work = together. I was surprised to find that the text that does that was = relegated to the appendices, which I usually see reserved for more = optional reading. I recommend promoting the appendix text into a = non-normative introduction. (If you follow this recommendation, please = edit that text for tone; it veers a bit too far on the casual side in = places for a standards track RFC.) >=20 > - General: Please be consistent between using =E2=80=9CE2E" or = "end-to-end=E2=80=9D when referring to keys. (Same with HBH and = "hop-by-hop") >=20 > - General: Please be consistent in using present vs future tense when = describing procedures. Present tense is usually more readable for that = sort of thing. >=20 > =C2=A71, first paragraph: > - "Instead, media flows transmitted by > conference participants are simply forwarded by the Media Distributor > to each of the other participants, often forwarding only a subset of > flows based on voice activity detection or other criteria.=E2=80=9D >=20 > The sentence seems to switch subjects half way through. Suggest = breaking into two sentences, with the second starting with =E2=80=9CMedia = Distributors often forward only a subset..=E2=80=9D >=20 > =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together = better. It says the ability to deploy in virtual environments is an = advantage, but the rest of the paragraph seems to argue why doing so is = insecure. I _think_ the idea is to say that this draft helps improve = that security, thus helping remove a barrier to taking advantage of = virtual/cloud environments? If so, please say so. >=20 > =C2=A73.1.1, 2nd paragraph: "An endpoint=E2=80=99s ability to join a = conference hosted by a Media > Distributor MUST NOT alone be interpreted as being authorized to have > access to the E2E media encryption keys, as the Media Distributor > does not have the ability to determine whether an endpoint is > authorized.=E2=80=9D >=20 > MUST NOT be interpreted by what? (consider active voice). Also, I=E2=80=99= m not sure what it means for "the ability to join a conference" to be = authorized. Consider something to the effect of =E2=80=9C... to imply = that the endpoint is authorized...=E2=80=9D >=20 > =C2=A74.1, first paragraph: "access of the end-to- > end key information=E2=80=9D > s/of/to >=20 > =C2=A74.2, first paragraph: Please expand =E2=80=9CSSRC" on first = mention. >=20 > =C2=A74.3: > - 2nd paragraph:"Receiving > endpoints MUST discard old E2E keys no later than when it leaves the > conference.=E2=80=9D: singular/plural disagreement. >=20 > -3rd paragraph:"an encryption key is derived=E2=80=9D: Derived by = what? (consider active voice). >=20 > =C2=A74.4, section title: should =E2=80=9CHop Operations=E2=80=9D be = =E2=80=9CPer-hop Operations=E2=80=9D? >=20 > =C2=A74.4, last paragraph: "an encryption key is derived=E2=80=9D: = derived by what? (consider active voice.) >=20 > =C2=A74.5.2, last paragraph: "Endpoints are at liberty to change the = E2E encryption key used at any > time. Endpoints MUST generate a new E2E encryption key whenever it > receives a new EKT Key.=E2=80=9D >=20 > To be consistent with the =E2=80=9CMUST" in the 2nd sentence, it seems = like =E2=80=9Care at liberty to=E2=80=9D should be =E2=80=9CMAY=E2=80=9D. >=20 > =C2=A75: =E2=80=9CThe key requirements is...=E2=80=9D : plural = disagreement. >=20 > =C2=A76.1, 2nd paragraph: "If not > making use of HBH authentication on the Media Distributor, such an > attack could only be detected in the receiving endpoints where the > forged packets would finally be dropped.=E2=80=9D >=20 > The sentence suggests that an attack might make use of HBH = authentication. I don=E2=80=99t think that=E2=80=99s the intent. >=20 > =C2=A76.2.2: Missing article before =E2=80=9CReplay=E2=80=9D >=20 > Appendix A: >=20 > -- "The time required to retain old keys (either EKT Keys or SRTP = master > keys) is not specified, but they should be retained at least for the > period of time required to re-key the conference or handle = latearriving > or out-of-order packets. A period of 60s should be > considered a generous retention period, but endpoints may keep old > keys on hand until the end of the conference.=E2=80=9D >=20 > That should be stated in the main body. >=20 > -- "Or more detailed explanation of each of the keys follows.=E2=80=9D >=20 > Sentence fragment. >=20 > Appendix B: >=20 > It really seems like the packet format should go in the main body (if = it=E2=80=99s needed in this document at all.) >=20 > Also, is there really anything called a PERC packet? That would be" = SRTP with double", or something like that, right? >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_9ED3B02B-5240-43D5-9A75-D5026877AFD9 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw9FyQACgkQgFZKbJXz 1A082g//Uw5mKuOsfghytaFChHdxaNtzUtizZB2b8/0kMCfcBQ0PVTXBD1Rilhqp 2lvUbtaYYbA5/0M10L6JRdPGsCw3P00IHs9Ner8hUHco6qosHj/vsdiHbZ6X+h83 i+VAJKsmQbaePRcotGDUBWl+eO90W2WhnfrosfySViJXY7OAL9UnOuq+0Em0Wbf3 i3fZau0scegK4i5xP0FIzoIbJx1l54W8HkU52UeGcVMo1PbXGpGLFR0RPJwFke21 3b1a3Q8kJvgAlR07iPrgV+oaWptL0+5JTvJ4yaHq3xyoqz04Ks7X5388HxWlauRl wdKSHYKN+q+ez0YOkKVjoM9Q7D2ZZgxibUA9x9hdTFUHNV+ZrlhE1ay32Exf8NnS zxbAJ3zVY3qhEg5RvxIzzuThjcMC7J0vR9zLiUEW+CZLjiMWB91OfWxGizjqRr2l oiOqkXcq2K+cEFF4HKpH85xAQJ5jIfORVYTzua/6GM//9zXi1TFR80+6oOqpOmLK Trh+hvwQCCjTIvRbwaoAh4BsV03y1oBdcqIdcWaiuInnq6RWNUp1kxUO2ntcb9ob ++gDfS6aXmx5XxYbtvIGnJ37v4joYchddDO4zRtVlLDbOK1cyhpP/g+VHNKKzGxG 0xnHYCNBWy2ogB9etZWDBmollyC79F1jVW/1xyBSZU5/cESufow= =hccm -----END PGP SIGNATURE----- --Apple-Mail=_9ED3B02B-5240-43D5-9A75-D5026877AFD9-- From nobody Mon Jan 14 15:17: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 7025F131017; Mon, 14 Jan 2019 15:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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=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 7tC4uvgzieGf; Mon, 14 Jan 2019 15:17:09 -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 11253130FF2; Mon, 14 Jan 2019 15:17:08 -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=1547507826; bh=MXH6q5kf+mK41CcLOEdx6p/6xqXrYiz6QYTdOfn9QAM=; h=Date:In-Reply-To:References:Subject:To:CC:From; b=JeFDxBO9H5PoatZGImbAaB9UtHiCY4/Ab2NUBG1XbSHz6e9inD3jkx24Hakt6bjnt ukaxSDObiKlo1dS3ikPABKGBJnlM4u4Ieqb/9h6NMtABca0U3T0PjCqFeTtFzcpk91 +yd5/o0+AFa2JNGIBqTFvxB8qJaHB4ajQJlXBGvQ= Date: Mon, 14 Jan 2019 18:17:04 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <8F9C11FD-9CCD-48DD-96E8-286CA2569626@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----FGUCTI7AXA3190JERE8G8DNSJVT841" Content-Transfer-Encoding: 7bit Autocrypt: addr=paulej@packetizer.com; keydata= mQQNBFHlwHIBIADPBuXxiC7IP3Acolod+D4BWYKBDGgyX90mexkDt6Wi6D2LJlpadGp99NgG9Oc4 m9QDEPPuhRHKvgexNAxAeILUZlOX6m/30n83VuwGNZagxjawN9/Kv4WrLlDI+HSZeKwfVf8GBus/ jB6c5WQtV6/L7LYCQLU08dWng8NlBi6dupyWC1rhtNWnPCqS4C3nINWJRx4grfIvkI5PbDMPca/B iluZxy0XntHuNWf51Gj4IIIAK2QNWQwDLaDnZ774Q1HfMTt4u4UwivsOt9Z49w92Q6FuN7/3sve7 DwrEVtp0xCKqaBQOX2354VVOTMh0bhHGLprQ1BL3QAWlyg/ZkTs+kopd3h+mJ0Mkg3Es66umcG8U YbH+edmZ7mHWqHuWmNieEycZgmah6kfrb7lUZeJnkkLfZ6SS3fhJIhJq3RwTKfvyF9LNvnZ7XXsO VSBKvVFPHWuDe3tbglTZCEYIcdFotgMcpZatdJF0ZPdLPGECc/XCZOgQpICGZ6b0dt/uJKOPC1OY RlFfIWc9bDgRCQY0MCqTsYiGevMNdQTlZHgTactm4h886bETFdbSoDniPls7LuI3cAr++iHmF56o hwh9Hl8KVzsv+uSL1mmrfE/X+lEaJnPUrQopByFQySE4D+hvOFLNh2iv7BHyXX9G0Dv9jDB6hW+6 1RYBf23GRZWSEVMyoYfbbU7Tg5JNrVRLU7nUMVbla2fGIKz9K3ejtCy/35QAjt7DIrVVe9k9J54r Z1yD8ZXfQXv869/q/mHGVzxdtgO+PcrIXJYck8R7jSDB2wIo3g5z+2P3Lt2gvB4w9UUSNZ4deE95 MNc6FvqqTMlBzoxzBf2E+SoUZKTl4i48XJhKI+Bk71NnMug2ER2NbyQIg6aH7l4t4t38mK6yt/cd 00f8UtKxp7z2EnqXJ+/kx0pq9zECp76oAPv9JlInntbcl89jRS4qMAMgZFEy6sYOMftfhVgDkci/ JR+2s4V65aUxcR6PLtXRHg3ZZ2F4hEBkBxJQt4LZ6lWzMXuWkCfjca032WOq/Zl+RMrs18dywVoh DXqSaYoSCzkfeCbzTE4cCuE8o9FUx7B/nS6g+h0wvrGDcLeGIwVWYO+Q0gf+vbLq2ZfykWjS5Fa3 ZKLdEOWaNas/8UlW33lU3u9nj84dJgMcP/VAugd8N9QWJ9NKszL8689NmwQnzoIU43+ucRd0WgCA WgXtV6MmG2WUpKN6y/ARqis6NvKTpl/t7SMznBxZGg2ZUC7pBpT/cq6vi18+tWP1ghRGJgJJ4t6v D64fBQTAaaN9MxU46OIlcWtjvf5zzL0pwebYOdInN/wA7YOOK3Q/wQsPaD5dvY+6H9yrCLMBwGyR l3TB/bsaYqtFABEBAAG0JVBhdWwgRS4gSm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbT6JBDgE EwECACIFAlOH4kACGy8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHropU4WcvKlpF4gAI34 iWlJY84nB8y12sqLldU0d9rSnk6euOYf7HIIJ8yHGCHVkQJUksjcwPOAr/zw4XjftSEv8JN3PDLp khvQ2snEIZ7UPFafUmbq3BQLPkN0Mpamx7br7vpLwpRMwbPyWYc4Z0+Ag4t6p/01troi++v3DLDN AjAov/Q526pL7qFkIJpadMcVcTEgr5XEsVVxw5TbGrqyDwam+aNIVcxDNxzOG4nFJ1bjUGAeoRcV Jnz0X0CQUFzxgMceyjuqI3Qyj5kp3gZkoibJyfZ6/6FFVV5dGAlHluL52H6KiUAkWPf0qbGo6ELu xsnSX9JPVUtr14B6HfZP8kWX740Hu2yBQTAxhsfhhsR4LNUxKcdNFSJ/Ozpo3i7fvek3CF+ash7l 25JAkI+1TH4kh7dYpndwTWwXDNqTMQR+I+JtsKgATpx/pBWaNK0zvWKuxjoM/CVn4NPWf9aqfdF3 wvTq5EMDarQ8Leou0LsKLKZsJHYYxFlMlD37/+q4UsIy5iPatNl8qm4YM4LykjvB+Ozsd3OZ3z+b uSdJ+6QwOnje21tPLhSI8dEIw8S+DKl+80I/2bEd3+wKptHcB0NU3OF9B3N1ClOp7wFIrgsQ0pTH A2pchxWyC9pngYhErJS6nZaQeWwrN7VH9RkS2SPPkAzf5N27ayky2rF8nDZrkO1OuXCaH9gyi2CQ fJEtbAPMXfAJo5Ls0trEMqQGDAW3/GxCo5NoX70bXjPd+NXBIYBaC9dc6Iyqei3xQJNsE2vtPEo3 glJaE3mFMpUOILqQkU8hjs3+J1rNkpkmaoenlvbDVUqM0TVGzHFJlPtLXR/DsDjgjk1uaS+xIlD0 exwLp3/Bgs4nXAQ1UYlPOLC/BokUPwAuSuUrCAYHfAzwsynIgI8j/EHeKgyjyuQ4f1uIlzy63rVd 8QVvGt6qV2hO0Bj4FzIMG9xG4KZ7cPziHmAh5tR0PbV35vJLww3HbmL6LzC5CaB2cYkLuOL4BuhU D+b20GiThhtYaPBQr49NBNViCB+RlhojKIS4Ou9+ngg2L4EWe6rY0yzR+BWPBvNtZNantozb49Pu IcYhfxzWFjK7Gt6zlQeUfsBGtdjR1p4emdH4c/VFdzj4bNPtKv56mkUrcFQpE1vym/PPYyvG3wBz UXF/d/W5NqojZmuQLO+GfMPo2sbT3V0LTELlfRfzOstA7SpdQgYpMoRQwErxIwn2lUVjt6DjXeaR oOkQgYAgQqHYLrWef6gYLy05xHEN6Ow6t7VDxuZOtjrJqQ3oyfcyR9EsyAET8CvSSaHABOaqWOiw E+TzU9/42ei0Qph08xL8BQMQVsnOJZLM8DMNWzWB3wVxCaVil+unNTnmw7mjClcPFuBjFyc= To: Ben Campbell , draft-ietf-perc-private-media-framework.all@ietf.org CC: perc@ietf.org From: "Paul E. Jones" Message-ID: Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-private-media-framework-07 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: Mon, 14 Jan 2019 23:17:13 -0000 ------FGUCTI7AXA3190JERE8G8DNSJVT841 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ben, I was chasing people down for comment=2E I got that end of last week, so I= hope to get a new draft put later this week or the weekend=2E Paul -------- Original Message -------- From: Ben Campbell Sent: January 14, 2019 6:11:32 PM EST To: draft-ietf-perc-private-media-framework=2Eall@ietf=2Eorg Cc: perc@ietf=2Eorg Subject: Re: AD Evaluation of draft-ietf-perc-private-media-framework-07 Hi, What=E2=80=99s the status of getting an update? It would be nice to get th= is through IETF LC and the IESG evaluation before Prague=2E Thanks! Ben=2E > On Oct 22, 2018, at 2:47 PM, Ben Campbell wrote: >=20 > Hi, >=20 > This is my AD Evaluation of draft-ietf-perc-private-media-framework-07= =2E >=20 > I appreciate all the work that has gone into this, but I think this draf= t still needs some work before the IETF last call=2E I have some substantiv= e and significant editorial comments that I would like to resolve prior to = the LC=2E >=20 > Thanks! >=20 > Ben=2E >=20 > ------------------------- >=20 > Substantive Comments: >=20 > =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together b= etter=2E It says the ability to deploy in virtual environments is an advant= age, but the rest of the paragraph seems to argue why doing so is insecure= =2E I _think_ the idea is to say that this draft helps improve that securit= y, thus helping remove a barrier to taking advantage of virtual/cloud envir= onments? If so, please say so=2E >=20 > =C2=A72: Please use the new boilerplate from RFC 8174=2E There are multi= ple uses of lower-case =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=E2=80=9D = in the document that don=E2=80=99t appear to be intended as normative=2E >=20 > =C2=A72, definition of MD: It seems like this definition is a little too= focused on the PERC trust model, and leaves out the definition of it as a = middlebox that forwards the active stream without modification=2E (I guess = that=E2=80=99s caught in the reference to 7667, but it would be better to i= nclude the core of the definition here, rather than imply it by reference= =2E >=20 > =C2=A73=2E1=2E1: "The actual > media content MUST NOT not be decryptable by a Media Distributor, so > it is untrusted to have access to the E2E media encryption keys=2E=E2=80= =9D >=20 > I=E2=80=99m not sure that MUST NOT should be stated normatively, as it= =E2=80=99s really a statement of fact, or at least a foundational assumptio= n=2E >=20 > =C2=A73=2E1=2E1, paragraph 3: "A Media Distributor MUST perform its role= in properly forwarding > media packets while taking measures to mitigate the adverse effects > of denial of service attacks (refer to Section 6), etc, to a level > equal to or better than traditional conferencing (i=2Ee=2E non-PERC) > deployments=2E=E2=80=9D >=20 > That requirement is too vague for a normative MUST=2E Consider leaving t= he normative language to section 6=2E >=20 > =C2=A73=2E1=2E2, last paragraph: "In any deployment scenario where the c= all processing function is > considered trusted, the call processing function MUST ensure the > integrity of received messages before forwarding to other entities=2E=E2= =80=9D >=20 > Please describe why that is important in a PERC environment=2E >=20 > =C2=A74=2E2, first paragraph: "participants in the conference > MUST keep track of the E2E keys=E2=80=9D >=20 > This seems redundant to similar requirement in 4=2E3=2E The requirements= in 4=2E3 are more precise, so I suggest stating this one descriptively=2E >=20 > =C2=A74=2E3: "prior E2E keys SHOULD be retained=E2=80=9D >=20 > I think there=E2=80=99s some disagreement internal to this document, and= between this and EKT (and maybe double?)=2E Please see related comment 0n = section 4=2E5=2E2: >=20 > =C2=A74=2E4: First paragraph: "this framework requires that every packet= be authenticated=E2=80=9D: Is that a statement of fact that this framework= states a normative requirement elsewhere, or is it this intended to be a n= ormative requirement in itself? >=20 > =C2=A74=2E4, 2nd paragraph: "Using hop-by-hop authentication gives the M= edia Distributor the > ability to change certain RTP header values=2E=E2=80=9D > That=E2=80=99s not really a true statement=2E It=E2=80=99s the lack of E= 2E authentication that enables that=2E It seems like the real point is that= , since we can=E2=80=99t use E2E authentication, HBH authentication is bett= er than nothing=2E >=20 > =C2=A74=2E4, 3rd paragraph: "If there is a need to encrypt one or more R= TP header extensions hopby- > hop, =2E=2E=2E=E2=80=9D : Is that optional? >=20 > =C2=A74=2E4, last paragraph: "Note that when RTP header extensions are e= ncrypted, > all hops - in the untrusted domain at least - will need to decrypt > and re-encrypt these encrypted header extensions=2E=E2=80=9D >=20 > I=E2=80=99m confused by this; the document requires distinct keys for ea= ch hop=2E is there an exception for trusted MDs? >=20 > =C2=A74=2E5=2E1, > - 2nd to last paragraph: "Endpoints MAY use the DTLSSRTP > generated E2E key for transmission or MAY generate a fresh E2E > key=2E=E2=80=9D: They have to do one or the other, right? That wording a= llows then to do neither=2E >=20 > - Last paragraph: It would be helpful to describe the security associat= ions involved=2E Do I understand correctly that an endpoint has an SA with = the KD, but not the MD? But peer MDs do have SAs with each other? >=20 > =C2=A74=2E5=2E2, 3rd paragraph: >=20 > I think there=E2=80=99s some disagreement on the normative keywords for = delaying the switch to new keys=2E I discussed this offline with Richard, a= nd he replied with the following: >=20 >> There's sort of a conflict here=2E The crux is here: >>=20 >> """ >> Since it may take some time for all of the >> endpoints in conference to finish re-keying, senders MUST delay a >> short period of time before sending media encrypted with the new >> master key, but it MUST be prepared to make use of the information >> from a new inbound EKT Key immediately=2E >> """ >>=20 >> The first part talks about media keys, which conflicts with EKT; it sho= uld probably be deleted=2E The second part is about processing EKT tags, a= nd should be kept=2E So we probably end up with something like the followi= ng: >>=20 >> """ >> In order to allow time for all endpoints in the conference to receive= the new keys, >> the sender should follow the recommendations in Section XXX of [I-D= =2Eietf-perc-srtp-ekt-diet]=2E >> On receiving a new EKT Key, endpoints MUST be prepared to decrypt EKT= tags using the >> new key=2E The EKT SPI field can be used to differentiate between ta= gs encrypted with >> the old and new keys=2E >> """ >=20 > =C2=A75=2E2, 2nd paragraph: If the fingerprint is signed, does the entir= e signaling network still need to be trusted? Also, should the reference to= 4474 be 8224? >=20 > =C2=A76: This is written in forward-looking language about how the fram= ework needs to be designed=2E That design is complete now, what are the con= siderations for it=E2=80=99s use as designed? >=20 > Also, there are considerations for attacks other than DOS attacks, right= ? >=20 > =C2=A76=2E2=2E1: This section seems odd to me=2E I understand not trust= ing the MD to keep communication confidential or to not tamper with it, etc= =2E But if the MD wants to deny service, it can find much easier ways=2E Fo= r example, simply not forwarding packets=2E >=20 > =C2=A7A=2E1: "Assuming the use of Double=2E=2E=2E=E2=80=9D > Is that optional? >=20 > - "The media distributor doesn=E2=80=99t perform DTLS-SRTP,=2E=2E=2E=E2= =80=9D >=20 > The document describes one case where it does (connections between peer = MDs) >=20 > =C2=A7A=2E3: "To reduce complexity, PERC > *RECOMMENDS* that endpoints create random SRTP master keys locally to > be used for E2E encryption=2E=E2=80=9D >=20 > Is RECOMMENDS intended as normative? If not, where is the actual recomme= ndation? >=20 > Editorial Comments: >=20 > - General: I found the draft to have some issues with flow and fragmenta= tion=2E I expected this draft give a big-picture overview tying together th= e moving parts of PERC in a way that tells me how they work together=2E I = was surprised to find that the text that does that was relegated to the app= endices, which I usually see reserved for more optional reading=2E I recomm= end promoting the appendix text into a non-normative introduction=2E (If yo= u follow this recommendation, please edit that text for tone; it veers a bi= t too far on the casual side in places for a standards track RFC=2E) >=20 > - General: Please be consistent between using =E2=80=9CE2E" or "end-to-e= nd=E2=80=9D when referring to keys=2E (Same with HBH and "hop-by-hop") >=20 > - General: Please be consistent in using present vs future tense when de= scribing procedures=2E Present tense is usually more readable for that sort= of thing=2E >=20 > =C2=A71, first paragraph: > - "Instead, media flows transmitted by > conference participants are simply forwarded by the Media Distributor > to each of the other participants, often forwarding only a subset of > flows based on voice activity detection or other criteria=2E=E2=80=9D >=20 > The sentence seems to switch subjects half way through=2E Suggest breaki= ng into two sentences, with the second starting with =E2=80=9CMedia Distrib= utors often forward only a subset=2E=2E=E2=80=9D >=20 > =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together b= etter=2E It says the ability to deploy in virtual environments is an advant= age, but the rest of the paragraph seems to argue why doing so is insecure= =2E I _think_ the idea is to say that this draft helps improve that securit= y, thus helping remove a barrier to taking advantage of virtual/cloud envir= onments? If so, please say so=2E >=20 > =C2=A73=2E1=2E1, 2nd paragraph: "An endpoint=E2=80=99s ability to join a= conference hosted by a Media > Distributor MUST NOT alone be interpreted as being authorized to have > access to the E2E media encryption keys, as the Media Distributor > does not have the ability to determine whether an endpoint is > authorized=2E=E2=80=9D >=20 > MUST NOT be interpreted by what? (consider active voice)=2E Also, I=E2= =80=99m not sure what it means for "the ability to join a conference" to be= authorized=2E Consider something to the effect of =E2=80=9C=2E=2E=2E to im= ply that the endpoint is authorized=2E=2E=2E=E2=80=9D >=20 > =C2=A74=2E1, first paragraph: "access of the end-to- > end key information=E2=80=9D > s/of/to >=20 > =C2=A74=2E2, first paragraph: Please expand =E2=80=9CSSRC" on first ment= ion=2E >=20 > =C2=A74=2E3: > - 2nd paragraph:"Receiving > endpoints MUST discard old E2E keys no later than when it leaves the > conference=2E=E2=80=9D: singular/plural disagreement=2E >=20 > -3rd paragraph:"an encryption key is derived=E2=80=9D: Derived by what? = (consider active voice)=2E >=20 > =C2=A74=2E4, section title: should =E2=80=9CHop Operations=E2=80=9D be = =E2=80=9CPer-hop Operations=E2=80=9D? >=20 > =C2=A74=2E4, last paragraph: "an encryption key is derived=E2=80=9D: der= ived by what? (consider active voice=2E) >=20 > =C2=A74=2E5=2E2, last paragraph: "Endpoints are at liberty to change the= E2E encryption key used at any > time=2E Endpoints MUST generate a new E2E encryption key whenever it > receives a new EKT Key=2E=E2=80=9D >=20 > To be consistent with the =E2=80=9CMUST" in the 2nd sentence, it seems l= ike =E2=80=9Care at liberty to=E2=80=9D should be =E2=80=9CMAY=E2=80=9D=2E >=20 > =C2=A75: =E2=80=9CThe key requirements is=2E=2E=2E=E2=80=9D : plural dis= agreement=2E >=20 > =C2=A76=2E1, 2nd paragraph: "If not > making use of HBH authentication on the Media Distributor, such an > attack could only be detected in the receiving endpoints where the > forged packets would finally be dropped=2E=E2=80=9D >=20 > The sentence suggests that an attack might make use of HBH authenticatio= n=2E I don=E2=80=99t think that=E2=80=99s the intent=2E >=20 > =C2=A76=2E2=2E2: Missing article before =E2=80=9CReplay=E2=80=9D >=20 > Appendix A: >=20 > -- "The time required to retain old keys (either EKT Keys or SRTP master > keys) is not specified, but they should be retained at least for the > period of time required to re-key the conference or handle latearriving > or out-of-order packets=2E A period of 60s should be > considered a generous retention period, but endpoints may keep old > keys on hand until the end of the conference=2E=E2=80=9D >=20 > That should be stated in the main body=2E >=20 > -- "Or more detailed explanation of each of the keys follows=2E=E2=80=9D >=20 > Sentence fragment=2E >=20 > Appendix B: >=20 > It really seems like the packet format should go in the main body (if it= =E2=80=99s needed in this document at all=2E) >=20 > Also, is there really anything called a PERC packet? That would be" SRTP= with double", or something like that, right? >=20 >=20 >=20 >=20 >=20 >=20 >=20 ------FGUCTI7AXA3190JERE8G8DNSJVT841 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ben,

I was chasing people down for comment= =2E I got that end of last week, so I hope to get a new draft put later thi= s week or the weekend=2E

Paul

From: Ben Campbell <ben@nostrum=2Ecom>
Sent: January 14, 2019 6:11:32 PM EST
To: draft-ietf-perc-private-media-framework=2Eall@ietf=2Eorg
Cc: perc@ietf=2Eorg
Subject: Re: AD Evaluation of draft-ietf-perc-private-media-framewo= rk-07

Hi,

What=E2=80=99s the status of getting an u=
pdate? It would be nice to get this through IETF LC and the IESG evaluation=
 before Prague=2E

Thanks!

Ben=2E

On Oct 22, 2018, at 2:47 PM, Ben Campbell <b=
en@nostrum=2Ecom> wrote:

Hi,

This is my AD Evaluation of d=
raft-ietf-perc-private-media-framework-07=2E

I appreciate all the wo=
rk that has gone into this, but I think this draft still needs some work be=
fore the IETF last call=2E I have some substantive and significant editoria=
l comments that I would like to resolve prior to the LC=2E

Thanks!
Ben=2E
Substantive Comments:

=C2=A71, 2nd paragraph: This p=
aragraph needs to tie the ideas together better=2E It says the ability to d=
eploy in virtual environments is an advantage, but the rest of the paragrap=
h seems to argue why doing so is insecure=2E I _think_ the idea is to say t=
hat this draft helps improve that security, thus helping remove a barrier t=
o taking advantage of virtual/cloud environments? If so, please say so=2E
=C2=A72: Please use the new boilerplate from RFC 8174=2E There are mu=
ltiple uses of lower-case =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=E2=80=
=9D in the document that don=E2=80=99t appear to be intended as normative=
=2E

=C2=A72, definition of MD: It seems like this definition is a li=
ttle too focused on the PERC trust model, and leaves out the definition of =
it as a middlebox that forwards the active stream without modification=2E (=
I guess that=E2=80=99s caught in the reference to 7667, but it would be bet=
ter to include the core of the definition here, rather than imply it by ref=
erence=2E

=C2=A73=2E1=2E1: "The actual
media content MUST NOT not=
 be decryptable by a Media Distributor, so
it is untrusted to have acces=
s to the E2E media encryption keys=2E=E2=80=9D

I=E2=80=99m not sure =
that MUST NOT should be stated normatively, as it=E2=80=99s really a statem=
ent of fact, or at least a foundational assumption=2E

=C2=A73=2E1=2E=
1, paragraph 3: "A Media Distributor MUST perform its role in properly forw=
arding
media packets while taking measures to mitigate the adverse effec=
ts
of denial of service attacks (refer to Section 6), etc, to a levelequal to or better than traditional conferencing (i=2Ee=2E non-PERC)
de=
ployments=2E=E2=80=9D

That requirement is too vague for a normative =
MUST=2E Consider leaving the normative language to section 6=2E

=C2=
=A73=2E1=2E2, last paragraph: "In any deployment scenario where the call pr=
ocessing function is
considered trusted, the call processing function MU=
ST ensure the
integrity of received messages before forwarding to other =
entities=2E=E2=80=9D

Please describe why that is important in a PERC=
 environment=2E

=C2=A74=2E2, first paragraph: "participants in the c=
onference
MUST keep track of the E2E keys=E2=80=9D

This seems red=
undant to similar requirement in 4=2E3=2E The requirements in 4=2E3 are mor=
e precise, so I suggest stating this one descriptively=2E

=C2=A74=2E=
3: "prior E2E keys SHOULD be retained=E2=80=9D

I think there=E2=80=
=99s some disagreement internal to this document, and between this and EKT =
(and maybe double?)=2E Please see related comment 0n section 4=2E5=2E2:
=

=C2=A74=2E4: First paragraph: "this framework requires that every packe=
t be authenticated=E2=80=9D: Is that a statement of fact that this framewor=
k states a normative requirement elsewhere, or is it this intended to be a =
normative requirement in itself?

=C2=A74=2E4, 2nd paragraph: "Using =
hop-by-hop authentication gives the Media Distributor the
ability to cha=
nge certain RTP header values=2E=E2=80=9D
That=E2=80=99s not really a tr=
ue statement=2E It=E2=80=99s the lack of E2E authentication that enables th=
at=2E It seems like the real point is that, since we can=E2=80=99t use E2E =
authentication, HBH authentication is better than nothing=2E

=C2=A74=
=2E4, 3rd paragraph: "If there is a need to encrypt one or more RTP header =
extensions hopby-
hop, =2E=2E=2E=E2=80=9D : Is that optional?

=C2=
=A74=2E4, last paragraph: "Note that when RTP header extensions are encrypt=
ed,
all hops - in the untrusted domain at least - will need to decryptand re-encrypt these encrypted header extensions=2E=E2=80=9D

I=E2=
=80=99m confused by this; the document requires distinct keys for each hop=
=2E is there an exception for trusted MDs?

=C2=A74=2E5=2E1,
- 2nd=
 to  last paragraph: "Endpoints MAY use the DTLSSRTP
generated E2E key f=
or transmission or MAY generate a fresh E2E
key=2E=E2=80=9D: They have t=
o do one or the other, right? That wording allows then to do neither=2E
=

- Last paragraph:  It would be helpful to describe the security associa=
tions involved=2E Do I understand correctly that an endpoint has an SA with=
 the KD, but not the MD?  But peer MDs do have SAs with each other?

=
=C2=A74=2E5=2E2, 3rd paragraph:

I think there=E2=80=99s some disagre=
ement on the normative keywords for delaying the switch to new keys=2E I di=
scussed this offline with Richard, and he replied with the following:
There's sort of a confli=
ct here=2E  The crux is here:

"""
  Since it may take some time f=
or all of the
  endpoints in conference to finish re-keying, senders MUS=
T delay a
  short period of time before sending media encrypted with the=
 new
  master key, but it MUST be prepared to make use of the informatio=
n
  from a new inbound EKT Key immediately=2E
"""

The first pa=
rt talks about media keys, which conflicts with EKT; it should probably be =
deleted=2E  The second part is about processing EKT tags, and should be kep=
t=2E  So we probably end up with something like the following:

"""  In order to allow time for all endpoints in the conference to receive t=
he new keys,
  the sender should follow the recommendations in Section X=
XX of [I-D=2Eietf-perc-srtp-ekt-diet]=2E
  On receiving a new EKT Key, e=
ndpoints MUST be prepared to decrypt EKT tags using the
  new key=2E  Th=
e EKT SPI field can be used to differentiate between tags encrypted with  the old and new keys=2E
"""

=C2=A75=2E2, 2nd para=
graph: If the fingerprint is signed, does the entire signaling network stil=
l need to be trusted? Also, should the reference to 4474 be 8224?

=
=C2=A76:  This is written in forward-looking language about how the framewo=
rk needs to be designed=2E That design is complete now, what are the consid=
erations for it=E2=80=99s use as designed?

Also, there are considera=
tions for attacks other than DOS attacks, right?

=C2=A76=2E2=2E1: Th=
is section seems odd to me=2E  I understand not trusting the MD to keep com=
munication confidential or to not tamper with it, etc=2E But if the MD want=
s to deny service, it can find much easier ways=2E For example, simply not =
forwarding packets=2E

=C2=A7A=2E1: "Assuming the use of Double=2E=2E=
=2E=E2=80=9D
Is that optional?

- "The media distributor doesn=E2=
=80=99t perform DTLS-SRTP,=2E=2E=2E=E2=80=9D

The document describes =
one case where it does (connections between peer MDs)

=C2=A7A=2E3: "=
To reduce complexity, PERC
*RECOMMENDS* that endpoints create random SRT=
P master keys locally to
be used for E2E encryption=2E=E2=80=9D

I=
s RECOMMENDS intended as normative? If not, where is the actual recommendat=
ion?

Editorial Comments:

- General: I found the draft to have=
 some issues with flow and fragmentation=2E I expected this draft give a bi=
g-picture overview tying together the moving parts of PERC in a way that te=
lls me how they work together=2E  I was surprised to find that the text tha=
t does that was relegated to the appendices, which I usually see reserved f=
or more optional reading=2E I recommend promoting the appendix text into a =
non-normative introduction=2E (If you follow this recommendation, please ed=
it that text for tone; it veers a bit too far on the casual side in places =
for a standards track RFC=2E)

- General: Please be consistent betwee=
n using =E2=80=9CE2E" or "end-to-end=E2=80=9D when referring to keys=2E (Sa=
me with HBH and "hop-by-hop")

- General: Please be consistent in usi=
ng present vs future tense when describing procedures=2E Present tense is u=
sually more readable for that sort of thing=2E

=C2=A71, first paragr=
aph:
- "Instead, media flows transmitted by
conference participants a=
re simply forwarded by the Media Distributor
to each of the other partic=
ipants, often forwarding only a subset of
flows based on voice activity =
detection or other criteria=2E=E2=80=9D

The sentence seems to switch=
 subjects half way through=2E Suggest breaking into two sentences, with the=
 second starting with =E2=80=9CMedia Distributors often forward only a subs=
et=2E=2E=E2=80=9D

=C2=A71, 2nd paragraph: This paragraph needs to ti=
e the ideas together better=2E It says the ability to deploy in virtual env=
ironments is an advantage, but the rest of the paragraph seems to argue why=
 doing so is insecure=2E I _think_ the idea is to say that this draft helps=
 improve that security, thus helping remove a barrier to taking advantage o=
f virtual/cloud environments? If so, please say so=2E

=C2=A73=2E1=2E=
1, 2nd paragraph: "An endpoint=E2=80=99s ability to join a conference hoste=
d by a Media
Distributor MUST NOT alone be interpreted as being authoriz=
ed to have
access to the E2E media encryption keys, as the Media Distrib=
utor
does not have the ability to determine whether an endpoint is
au=
thorized=2E=E2=80=9D

MUST NOT be interpreted by what? (consider acti=
ve voice)=2E Also, I=E2=80=99m not sure what it means for "the ability to j=
oin a conference" to be authorized=2E Consider something to the effect of =
=E2=80=9C=2E=2E=2E to imply that the endpoint is authorized=2E=2E=2E=E2=80=
=9D

=C2=A74=2E1, first paragraph: "access of the end-to-
end key =
information=E2=80=9D
s/of/to

=C2=A74=2E2, first paragraph: Please=
 expand =E2=80=9CSSRC" on first mention=2E

=C2=A74=2E3:
- 2nd par=
agraph:"Receiving
endpoints MUST discard old E2E keys no later than when=
 it leaves the
conference=2E=E2=80=9D: singular/plural disagreement=2E
-3rd paragraph:"an encryption key is derived=E2=80=9D: Derived by wha=
t? (consider active voice)=2E

=C2=A74=2E4, section title: should =E2=
=80=9CHop Operations=E2=80=9D be =E2=80=9CPer-hop Operations=E2=80=9D?
<=
br>=C2=A74=2E4, last paragraph: "an encryption key is derived=E2=80=9D: der=
ived by what? (consider active voice=2E)

=C2=A74=2E5=2E2, last parag=
raph: "Endpoints are at liberty to change the E2E encryption key used at an=
y
time=2E Endpoints MUST generate a new E2E encryption key whenever itreceives a new EKT Key=2E=E2=80=9D

To be consistent with the =E2=
=80=9CMUST" in the 2nd sentence, it seems like =E2=80=9Care at liberty to=
=E2=80=9D should be =E2=80=9CMAY=E2=80=9D=2E

=C2=A75: =E2=80=9CThe k=
ey requirements is=2E=2E=2E=E2=80=9D : plural disagreement=2E

=C2=A7=
6=2E1, 2nd paragraph: "If not
making use of HBH authentication on the Me=
dia Distributor, such an
attack could only be detected in the receiving =
endpoints where the
forged packets would finally be dropped=2E=E2=80=9D<=
br>
The sentence suggests that an attack might make use of HBH authentic=
ation=2E I don=E2=80=99t think that=E2=80=99s the intent=2E

=C2=A76=
=2E2=2E2: Missing article before =E2=80=9CReplay=E2=80=9D

Appendix A=
:

-- "The time required to retain old keys (either EKT Keys or SRTP =
master
keys) is not specified, but they should be retained at least for =
the
period of time required to re-key the conference or handle latearriv=
ing
or out-of-order packets=2E A period of 60s should be
considered a=
 generous retention period, but endpoints may keep old
keys on hand unti=
l the end of the conference=2E=E2=80=9D

That should be stated in the=
 main body=2E

-- "Or more detailed explanation of each of the keys f=
ollows=2E=E2=80=9D

Sentence fragment=2E

Appendix B:

It=
 really seems like the packet format should go in the main body (if it=E2=
=80=99s needed in this document at all=2E)

Also, is there really any=
thing called a PERC packet? That would be" SRTP with double", or something =
like that, right?








------FGUCTI7AXA3190JERE8G8DNSJVT841-- From nobody Mon Jan 14 15:33: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 7BE4A131443; Mon, 14 Jan 2019 15:33:16 -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 dxDgfrze1p61; Mon, 14 Jan 2019 15:33:13 -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 98046131442; Mon, 14 Jan 2019 15:33:13 -0800 (PST) Received: from [10.0.1.45] (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 x0ENXBVh060309 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 17:33:12 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547508793; bh=+KixgKxNMRUU92COxkhHng+c7wvs6mmfCADMeC/O/dk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=YsJbzkGyadsxwzqLv68Op2lgHs+UoM4qVlhXdYDkDhso72rwJY6WTQPX9OXvVDWr3 d0uFz0X5Dpk0T73jf+Vj27BD0l4dsVuRNDl4Oi7j4Y1mgdZFcKduzNpdWFVSZl8uv2 bzErCYlgBIBODOSB2A6E9MphGS453SGtCaLtSf5Q= 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.45] From: Ben Campbell Message-Id: <48241CDA-86A8-4E16-8395-4047F7119284@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E4C4C341-1410-4CDC-89E6-B5C559454CC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 14 Jan 2019 17:33:10 -0600 In-Reply-To: Cc: draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org To: "Paul E. Jones" References: <8F9C11FD-9CCD-48DD-96E8-286CA2569626@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Perc] AD Evaluation of draft-ietf-perc-private-media-framework-07 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: Mon, 14 Jan 2019 23:33:17 -0000 --Apple-Mail=_E4C4C341-1410-4CDC-89E6-B5C559454CC9 Content-Type: multipart/alternative; boundary="Apple-Mail=_0FC5F770-A645-443E-9D76-64D9C55F717B" --Apple-Mail=_0FC5F770-A645-443E-9D76-64D9C55F717B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Excellent, thanks! Ben. > On Jan 14, 2019, at 5:17 PM, Paul E. Jones = wrote: >=20 > Ben, >=20 > I was chasing people down for comment. I got that end of last week, so = I hope to get a new draft put later this week or the weekend. >=20 > Paul >=20 > From: Ben Campbell > Sent: January 14, 2019 6:11:32 PM EST > To: draft-ietf-perc-private-media-framework.all@ietf.org > Cc: perc@ietf.org > Subject: Re: AD Evaluation of = draft-ietf-perc-private-media-framework-07 >=20 > Hi, >=20 > What=E2=80=99s the status of getting an update? It would be nice to = get this through IETF LC and the IESG evaluation before Prague. >=20 > Thanks! >=20 > Ben. >=20 > On Oct 22, 2018, at 2:47 PM, Ben Campbell wrote: >=20 > Hi, >=20 > This is my AD Evaluation of = draft-ietf-perc-private-media-framework-07. >=20 > I appreciate all the work that has gone into this, but I think this = draft still needs some work before the IETF last call. I have some = substantive and significant editorial comments that I would like to = resolve prior to the LC. >=20 > Thanks! >=20 > Ben. > Substantive Comments: >=20 > =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together = better. It says the ability to deploy in virtual environments is an = advantage, but the rest of the paragraph seems to argue why doing so is = insecure. I _think_ the idea is to say that this draft helps improve = that security, thus helping remove a barrier to taking advantage of = virtual/cloud environments? If so, please say so. >=20 > =C2=A72: Please use the new boilerplate from RFC 8174. There are = multiple uses of lower-case =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=E2=80= =9D in the document that don=E2=80=99t appear to be intended as = normative. >=20 > =C2=A72, definition of MD: It seems like this definition is a little = too focused on the PERC trust model, and leaves out the definition of it = as a middlebox that forwards the active stream without modification. (I = guess that=E2=80=99s caught in the reference to 7667, but it would be = better to include the core of the definition here, rather than imply it = by reference. >=20 > =C2=A73.1.1: "The actual > media content MUST NOT not be decryptable by a Media Distributor, so > it is untrusted to have access to the E2E media encryption keys.=E2=80=9D= >=20 > I=E2=80=99m not sure that MUST NOT should be stated normatively, as = it=E2=80=99s really a statement of fact, or at least a foundational = assumption. >=20 > =C2=A73.1.1, paragraph 3: "A Media Distributor MUST perform its role = in properly forwarding > media packets while taking measures to mitigate the adverse effects > of denial of service attacks (refer to Section 6), etc, to a level > equal to or better than traditional conferencing (i.e. non-PERC) > deployments.=E2=80=9D >=20 > That requirement is too vague for a normative MUST. Consider leaving = the normative language to section 6. >=20 > =C2=A73.1.2, last paragraph: "In any deployment scenario where the = call processing function is > considered trusted, the call processing function MUST ensure the > integrity of received messages before forwarding to other entities.=E2=80= =9D >=20 > Please describe why that is important in a PERC environment. >=20 > =C2=A74.2, first paragraph: "participants in the conference > MUST keep track of the E2E keys=E2=80=9D >=20 > This seems redundant to similar requirement in 4.3. The requirements = in 4.3 are more precise, so I suggest stating this one descriptively. >=20 > =C2=A74.3: "prior E2E keys SHOULD be retained=E2=80=9D >=20 > I think there=E2=80=99s some disagreement internal to this document, = and between this and EKT (and maybe double?). Please see related comment = 0n section 4.5.2: >=20 > =C2=A74.4: First paragraph: "this framework requires that every packet = be authenticated=E2=80=9D: Is that a statement of fact that this = framework states a normative requirement elsewhere, or is it this = intended to be a normative requirement in itself? >=20 > =C2=A74.4, 2nd paragraph: "Using hop-by-hop authentication gives the = Media Distributor the > ability to change certain RTP header values.=E2=80=9D > That=E2=80=99s not really a true statement. It=E2=80=99s the lack of = E2E authentication that enables that. It seems like the real point is = that, since we can=E2=80=99t use E2E authentication, HBH authentication = is better than nothing. >=20 > =C2=A74.4, 3rd paragraph: "If there is a need to encrypt one or more = RTP header extensions hopby- > hop, ...=E2=80=9D : Is that optional? >=20 > =C2=A74.4, last paragraph: "Note that when RTP header extensions are = encrypted, > all hops - in the untrusted domain at least - will need to decrypt > and re-encrypt these encrypted header extensions.=E2=80=9D >=20 > I=E2=80=99m confused by this; the document requires distinct keys for = each hop. is there an exception for trusted MDs? >=20 > =C2=A74.5.1, > - 2nd to last paragraph: "Endpoints MAY use the DTLSSRTP > generated E2E key for transmission or MAY generate a fresh E2E > key.=E2=80=9D: They have to do one or the other, right? That wording = allows then to do neither. >=20 > - Last paragraph: It would be helpful to describe the security = associations involved. Do I understand correctly that an endpoint has an = SA with the KD, but not the MD? But peer MDs do have SAs with each = other? >=20 > =C2=A74.5.2, 3rd paragraph: >=20 > I think there=E2=80=99s some disagreement on the normative keywords = for delaying the switch to new keys. I discussed this offline with = Richard, and he replied with the following: >=20 > There's sort of a conflict here. The crux is here: >=20 > """ > Since it may take some time for all of the > endpoints in conference to finish re-keying, senders MUST delay a > short period of time before sending media encrypted with the new > master key, but it MUST be prepared to make use of the information > from a new inbound EKT Key immediately. > """ >=20 > The first part talks about media keys, which conflicts with EKT; it = should probably be deleted. The second part is about processing EKT = tags, and should be kept. So we probably end up with something like the = following: >=20 > """ > In order to allow time for all endpoints in the conference to = receive the new keys, > the sender should follow the recommendations in Section XXX of = [I-D.ietf-perc-srtp-ekt-diet]. > On receiving a new EKT Key, endpoints MUST be prepared to decrypt = EKT tags using the > new key. The EKT SPI field can be used to differentiate between = tags encrypted with > the old and new keys. > """ >=20 > =C2=A75.2, 2nd paragraph: If the fingerprint is signed, does the = entire signaling network still need to be trusted? Also, should the = reference to 4474 be 8224? >=20 > =C2=A76: This is written in forward-looking language about how the = framework needs to be designed. That design is complete now, what are = the considerations for it=E2=80=99s use as designed? >=20 > Also, there are considerations for attacks other than DOS attacks, = right? >=20 > =C2=A76.2.1: This section seems odd to me. I understand not trusting = the MD to keep communication confidential or to not tamper with it, etc. = But if the MD wants to deny service, it can find much easier ways. For = example, simply not forwarding packets. >=20 > =C2=A7A.1: "Assuming the use of Double...=E2=80=9D > Is that optional? >=20 > - "The media distributor doesn=E2=80=99t perform DTLS-SRTP,...=E2=80=9D >=20 > The document describes one case where it does (connections between = peer MDs) >=20 > =C2=A7A.3: "To reduce complexity, PERC > *RECOMMENDS* that endpoints create random SRTP master keys locally to > be used for E2E encryption.=E2=80=9D >=20 > Is RECOMMENDS intended as normative? If not, where is the actual = recommendation? >=20 > Editorial Comments: >=20 > - General: I found the draft to have some issues with flow and = fragmentation. I expected this draft give a big-picture overview tying = together the moving parts of PERC in a way that tells me how they work = together. I was surprised to find that the text that does that was = relegated to the appendices, which I usually see reserved for more = optional reading. I recommend promoting the appendix text into a = non-normative introduction. (If you follow this recommendation, please = edit that text for tone; it veers a bit too far on the casual side in = places for a standards track RFC.) >=20 > - General: Please be consistent between using =E2=80=9CE2E" or = "end-to-end=E2=80=9D when referring to keys. (Same with HBH and = "hop-by-hop") >=20 > - General: Please be consistent in using present vs future tense when = describing procedures. Present tense is usually more readable for that = sort of thing. >=20 > =C2=A71, first paragraph: > - "Instead, media flows transmitted by > conference participants are simply forwarded by the Media Distributor > to each of the other participants, often forwarding only a subset of > flows based on voice activity detection or other criteria.=E2=80=9D >=20 > The sentence seems to switch subjects half way through. Suggest = breaking into two sentences, with the second starting with =E2=80=9CMedia = Distributors often forward only a subset..=E2=80=9D >=20 > =C2=A71, 2nd paragraph: This paragraph needs to tie the ideas together = better. It says the ability to deploy in virtual environments is an = advantage, but the rest of the paragraph seems to argue why doing so is = insecure. I _think_ the idea is to say that this draft helps improve = that security, thus helping remove a barrier to taking advantage of = virtual/cloud environments? If so, please say so. >=20 > =C2=A73.1.1, 2nd paragraph: "An endpoint=E2=80=99s ability to join a = conference hosted by a Media > Distributor MUST NOT alone be interpreted as being authorized to have > access to the E2E media encryption keys, as the Media Distributor > does not have the ability to determine whether an endpoint is > authorized.=E2=80=9D >=20 > MUST NOT be interpreted by what? (consider active voice). Also, I=E2=80=99= m not sure what it means for "the ability to join a conference" to be = authorized. Consider something to the effect of =E2=80=9C... to imply = that the endpoint is authorized...=E2=80=9D >=20 > =C2=A74.1, first paragraph: "access of the end-to- > end key information=E2=80=9D > s/of/to >=20 > =C2=A74.2, first paragraph: Please expand =E2=80=9CSSRC" on first = mention. >=20 > =C2=A74.3: > - 2nd paragraph:"Receiving > endpoints MUST discard old E2E keys no later than when it leaves the > conference.=E2=80=9D: singular/plural disagreement. >=20 > -3rd paragraph:"an encryption key is derived=E2=80=9D: Derived by = what? (consider active voice). >=20 > =C2=A74.4, section title: should =E2=80=9CHop Operations=E2=80=9D be = =E2=80=9CPer-hop Operations=E2=80=9D? >=20 > =C2=A74.4, last paragraph: "an encryption key is derived=E2=80=9D: = derived by what? (consider active voice.) >=20 > =C2=A74.5.2, last paragraph: "Endpoints are at liberty to change the = E2E encryption key used at any > time. Endpoints MUST generate a new E2E encryption key whenever it > receives a new EKT Key.=E2=80=9D >=20 > To be consistent with the =E2=80=9CMUST" in the 2nd sentence, it seems = like =E2=80=9Care at liberty to=E2=80=9D should be =E2=80=9CMAY=E2=80=9D. >=20 > =C2=A75: =E2=80=9CThe key requirements is...=E2=80=9D : plural = disagreement. >=20 > =C2=A76.1, 2nd paragraph: "If not > making use of HBH authentication on the Media Distributor, such an > attack could only be detected in the receiving endpoints where the > forged packets would finally be dropped.=E2=80=9D >=20 > The sentence suggests that an attack might make use of HBH = authentication. I don=E2=80=99t think that=E2=80=99s the intent. >=20 > =C2=A76.2.2: Missing article before =E2=80=9CReplay=E2=80=9D >=20 > Appendix A: >=20 > -- "The time required to retain old keys (either EKT Keys or SRTP = master > keys) is not specified, but they should be retained at least for the > period of time required to re-key the conference or handle = latearriving > or out-of-order packets. A period of 60s should be > considered a generous retention period, but endpoints may keep old > keys on hand until the end of the conference.=E2=80=9D >=20 > That should be stated in the main body. >=20 > -- "Or more detailed explanation of each of the keys follows.=E2=80=9D >=20 > Sentence fragment. >=20 > Appendix B: >=20 > It really seems like the packet format should go in the main body (if = it=E2=80=99s needed in this document at all.) >=20 > Also, is there really anything called a PERC packet? That would be" = SRTP with double", or something like that, right? >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_0FC5F770-A645-443E-9D76-64D9C55F717B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Excellent, thanks!

Ben.

On Jan 14, 2019, at 5:17 PM, = Paul E. Jones <paulej@packetizer.com> wrote:

Ben,

I was chasing people down = for comment. I got that end of last week, so I hope to get a new draft = put later this week or the weekend.

Paul

From: Ben Campbell <ben@nostrum.com>
Sent: January 14, 2019 6:11:32 PM EST
To: draft-ietf-perc-private-media-framework.all@ietf.org
Cc: perc@ietf.org
Subject: Re: AD Evaluation of = draft-ietf-perc-private-media-framework-07

Hi,

What=E2=80=99s =
the status of getting an update? It would be nice to get this through =
IETF LC and the IESG evaluation before Prague.

Thanks!

Ben.

On Oct =
22, 2018, at 2:47 PM, Ben Campbell <ben@nostrum.com> wrote:

Hi,

This is my AD Evaluation of =
draft-ietf-perc-private-media-framework-07.

I=
 appreciate all the work that has gone into this, but I think this draft =
still needs some work before the IETF last call. I have some substantive =
and significant editorial comments that I would like to resolve prior to =
the LC.

Thanks!

Ben.
Substantive Comments:

=C2=A71, 2nd paragraph: This paragraph needs to tie the ideas =
together better. It says the ability to deploy in virtual environments =
is an advantage, but the rest of the paragraph seems to argue why doing =
so is insecure. I _think_ the idea is to say that this draft helps =
improve that security, thus helping remove a barrier to taking advantage =
of virtual/cloud environments? If so, please say so.

=C2=A72: Please use the new boilerplate from RFC 8174. There =
are multiple uses of lower-case =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=
=E2=80=9D in the document that don=E2=80=99t appear to be intended as =
normative.

=C2=A72, definition of MD: It =
seems like this definition is a little too focused on the PERC trust =
model, and leaves out the definition of it as a middlebox that forwards =
the active stream without modification. (I guess that=E2=80=99s caught =
in the reference to 7667, but it would be better to include the core of =
the definition here, rather than imply it by reference.

=C2=A73.1.1: "The actual
media content MUST NOT =
not be decryptable by a Media Distributor, so
it is =
untrusted to have access to the E2E media encryption keys.=E2=80=9D

I=E2=80=99m not sure that MUST NOT should be =
stated normatively, as it=E2=80=99s really a statement of fact, or at =
least a foundational assumption.

=C2=A73.1.1,=
 paragraph 3: "A Media Distributor MUST perform its role in properly =
forwarding
media packets while taking measures to mitigate =
the adverse effects
of denial of service attacks (refer to =
Section 6), etc, to a level
equal to or better than =
traditional conferencing (i.e. non-PERC)
deployments.=E2=80=9D=


That requirement is too vague for a =
normative MUST. Consider leaving the normative language to section 6.

=C2=A73.1.2, last paragraph: "In any =
deployment scenario where the call processing function is
considered trusted, the call processing function MUST ensure =
the
integrity of received messages before forwarding to =
other entities.=E2=80=9D

Please describe =
why that is important in a PERC environment.

=C2=A74.2, first paragraph: "participants in the =
conference
MUST keep track of the E2E keys=E2=80=9D

This seems redundant to similar requirement in =
4.3. The requirements in 4.3 are more precise, so I suggest stating this =
one descriptively.

=C2=A74.3: "prior E2E =
keys SHOULD be retained=E2=80=9D

I think =
there=E2=80=99s some disagreement internal to this document, and between =
this and EKT (and maybe double?). Please see related comment 0n section =
4.5.2:

=C2=A74.4: First paragraph: "this =
framework requires that every packet be authenticated=E2=80=9D: Is that =
a statement of fact that this framework states a normative requirement =
elsewhere, or is it this intended to be a normative requirement in =
itself?

=C2=A74.4, 2nd paragraph: "Using =
hop-by-hop authentication gives the Media Distributor the
ability to change certain RTP header values.=E2=80=9D
That=E2=80=99s not really a true statement. It=E2=80=99s the =
lack of E2E authentication that enables that. It seems like the real =
point is that, since we can=E2=80=99t use E2E authentication, HBH =
authentication is better than nothing.

=C2=A7=
4.4, 3rd paragraph: "If there is a need to encrypt one or more RTP =
header extensions hopby-
hop, ...=E2=80=9D : Is that =
optional?

=C2=A74.4, last paragraph: "Note =
that when RTP header extensions are encrypted,
all hops - =
in the untrusted domain at least - will need to decrypt
and =
re-encrypt these encrypted header extensions.=E2=80=9D

I=E2=80=99m confused by this; the document requires distinct =
keys for each hop. is there an exception for trusted MDs?

=C2=A74.5.1,
- 2nd to  last =
paragraph: "Endpoints MAY use the DTLSSRTP
generated E2E =
key for transmission or MAY generate a fresh E2E
key.=E2=80=9D=
: They have to do one or the other, right? That wording allows then to =
do neither.

- Last paragraph:  It would be =
helpful to describe the security associations involved. Do I understand =
correctly that an endpoint has an SA with the KD, but not the MD?  But =
peer MDs do have SAs with each other?

=C2=A74.5.2, 3rd paragraph:

I =
think there=E2=80=99s some disagreement on the normative keywords for =
delaying the switch to new keys. I discussed this offline with Richard, =
and he replied with the following:

There's =
sort of a conflict here.  The crux is here:

"""
  Since it may take some time for all of =
the
  endpoints in conference to finish re-keying, senders =
MUST delay a
  short period of time before sending media =
encrypted with the new
  master key, but it MUST be =
prepared to make use of the information
  from a new =
inbound EKT Key immediately.
"""

The first part talks about media keys, which conflicts with =
EKT; it should probably be deleted.  The second part is about processing =
EKT tags, and should be kept.  So we probably end up with something like =
the following:

"""
  In order =
to allow time for all endpoints in the conference to receive the new =
keys,
  the sender should follow the recommendations in =
Section XXX of [I-D.ietf-perc-srtp-ekt-diet].
  On =
receiving a new EKT Key, endpoints MUST be prepared to decrypt EKT tags =
using the
  new key.  The EKT SPI field can be used to =
differentiate between tags encrypted with
  the old and =
new keys.
"""

=C2=A75.2, 2nd paragraph: If the fingerprint is signed, does =
the entire signaling network still need to be trusted? Also, should the =
reference to 4474 be 8224?

=C2=A76:  This =
is written in forward-looking language about how the framework needs to =
be designed. That design is complete now, what are the considerations =
for it=E2=80=99s use as designed?

Also, =
there are considerations for attacks other than DOS attacks, right?

=C2=A76.2.1: This section seems odd to me.  I =
understand not trusting the MD to keep communication confidential or to =
not tamper with it, etc. But if the MD wants to deny service, it can =
find much easier ways. For example, simply not forwarding packets.

=C2=A7A.1: "Assuming the use of =
Double...=E2=80=9D
Is that optional?

- "The media distributor doesn=E2=80=99t perform =
DTLS-SRTP,...=E2=80=9D

The document =
describes one case where it does (connections between peer MDs)

=C2=A7A.3: "To reduce complexity, PERC
*RECOMMENDS* that endpoints create random SRTP master keys =
locally to
be used for E2E encryption.=E2=80=9D

Is RECOMMENDS intended as normative? If not, =
where is the actual recommendation?

Editorial=
 Comments:

- General: I found the draft to =
have some issues with flow and fragmentation. I expected this draft give =
a big-picture overview tying together the moving parts of PERC in a way =
that tells me how they work together.  I was surprised to find that the =
text that does that was relegated to the appendices, which I usually see =
reserved for more optional reading. I recommend promoting the appendix =
text into a non-normative introduction. (If you follow this =
recommendation, please edit that text for tone; it veers a bit too far =
on the casual side in places for a standards track RFC.)
- General: Please be consistent between using =E2=80=9CE2E" =
or "end-to-end=E2=80=9D when referring to keys. (Same with HBH and =
"hop-by-hop")

- General: Please be =
consistent in using present vs future tense when describing procedures. =
Present tense is usually more readable for that sort of thing.

=C2=A71, first paragraph:
- =
"Instead, media flows transmitted by
conference =
participants are simply forwarded by the Media Distributor
to each of the other participants, often forwarding only a =
subset of
flows based on voice activity detection or other =
criteria.=E2=80=9D

The sentence seems to =
switch subjects half way through. Suggest breaking into two sentences, =
with the second starting with =E2=80=9CMedia Distributors often forward =
only a subset..=E2=80=9D

=C2=A71, 2nd =
paragraph: This paragraph needs to tie the ideas together better. It =
says the ability to deploy in virtual environments is an advantage, but =
the rest of the paragraph seems to argue why doing so is insecure. I =
_think_ the idea is to say that this draft helps improve that security, =
thus helping remove a barrier to taking advantage of virtual/cloud =
environments? If so, please say so.

=C2=A73.1=
.1, 2nd paragraph: "An endpoint=E2=80=99s ability to join a conference =
hosted by a Media
Distributor MUST NOT alone be =
interpreted as being authorized to have
access to the E2E =
media encryption keys, as the Media Distributor
does not =
have the ability to determine whether an endpoint is
authorized.=E2=80=9D

MUST NOT be =
interpreted by what? (consider active voice). Also, I=E2=80=99m not sure =
what it means for "the ability to join a conference" to be authorized. =
Consider something to the effect of =E2=80=9C... to imply that the =
endpoint is authorized...=E2=80=9D

=C2=A74.1,=
 first paragraph: "access of the end-to-
end key =
information=E2=80=9D
s/of/to

=C2=A74.2, first paragraph: Please expand =E2=80=9CSSRC" on =
first mention.

=C2=A74.3:
- =
2nd paragraph:"Receiving
endpoints MUST discard old E2E =
keys no later than when it leaves the
conference.=E2=80=9D: =
singular/plural disagreement.

-3rd =
paragraph:"an encryption key is derived=E2=80=9D: Derived by what? =
(consider active voice).

=C2=A74.4, section =
title: should =E2=80=9CHop Operations=E2=80=9D be =E2=80=9CPer-hop =
Operations=E2=80=9D?

=C2=A74.4, last =
paragraph: "an encryption key is derived=E2=80=9D: derived by what? =
(consider active voice.)

=C2=A74.5.2, last =
paragraph: "Endpoints are at liberty to change the E2E encryption key =
used at any
time. Endpoints MUST generate a new E2E =
encryption key whenever it
receives a new EKT Key.=E2=80=9D<=
br class=3D"">
To be consistent with the =E2=80=9CMUST" in =
the 2nd sentence, it seems like =E2=80=9Care at liberty to=E2=80=9D =
should be =E2=80=9CMAY=E2=80=9D.

=C2=A75: =
=E2=80=9CThe key requirements is...=E2=80=9D : plural disagreement.

=C2=A76.1, 2nd paragraph: "If not
making use of HBH authentication on the Media Distributor, =
such an
attack could only be detected in the receiving =
endpoints where the
forged packets would finally be =
dropped.=E2=80=9D

The sentence suggests =
that an attack might make use of HBH authentication. I don=E2=80=99t =
think that=E2=80=99s the intent.

=C2=A76.2.2:=
 Missing article before =E2=80=9CReplay=E2=80=9D

Appendix A:

-- "The time =
required to retain old keys (either EKT Keys or SRTP master
keys) is not specified, but they should be retained at least =
for the
period of time required to re-key the conference =
or handle latearriving
or out-of-order packets. A period =
of 60s should be
considered a generous retention period, =
but endpoints may keep old
keys on hand until the end of =
the conference.=E2=80=9D

That should be =
stated in the main body.

-- "Or more =
detailed explanation of each of the keys follows.=E2=80=9D

Sentence fragment.

Appendix B:

It really seems like =
the packet format should go in the main body (if it=E2=80=99s needed in =
this document at all.)

Also, is there =
really anything called a PERC packet? That would be" SRTP with double", =
or something like that, right?








= --Apple-Mail=_0FC5F770-A645-443E-9D76-64D9C55F717B-- --Apple-Mail=_E4C4C341-1410-4CDC-89E6-B5C559454CC9 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlw9HDYACgkQgFZKbJXz 1A2XCw//e+A5MOrUvJpcY/TkSRU9CfSTD8CbK2Ub3OFsXoNsyBTVGFN0+C2XDgUj gBYahD90txqeuBmj15ofpjJspEfPHTyX0GCcJkhaR2bWKRNRB7D/UsWpQyp9GLKY b6Z3BMFANrvl8ohQKyptcE0WXVoZBLBhzfzRJLHnLI/YcGiXyWyh9lC2cy0Wcrs2 WWJfDtkkYjEMByoeqGTog/QtkxTctFSVhHdyARN8PwRmL4vJAVj374qO7c4wc5/O q6xfszLrRbmu/j+Tzw2PPuWw5fimhXh5xKsq1pYEKl2jChR1r0TMxOeUaM2obH4J kQ5smWraFT0luyd21L8nH9XftHUxW6C3WsQ5GfY8FKyF4rIdMmJQwkFYnZgBhq/L 4xwQkfrEdx1vV8hLa2Hh2SgWGZp0iAYyxiY9xtyP4btZhwKCOb8T9KqcN375F4Gn v6Wt0UbLEbl6L6qSkg0Mz3D/uEHtwzGcJ08uuemSS4x/tBNVeMC/dXEUsh67LP1n 839yky5WeEtqhXd6rfzYXtHIy9dXZeP+iQQNV8WYOeQJMD5G4NFcWEqdHnPW7nYS KgaNAy14mYJ9xGqtjCIIVwKU1/LyQAOxxyOPxwePZdpIZ3kTN6xAtcGmDCECXFa1 dS7OBLyDuK/flxrnWjpKYOm8msZ45rwDFpK0Ycz0+BnoB2DZGos= =URwa -----END PGP SIGNATURE----- --Apple-Mail=_E4C4C341-1410-4CDC-89E6-B5C559454CC9-- From nobody Wed Jan 23 10:51: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 EF2A313102B; Wed, 23 Jan 2019 10:51:21 -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.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <154826948191.7542.12732292886038443439@ietfa.amsl.com> Date: Wed, 23 Jan 2019 10:51:21 -0800 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-08.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, 23 Jan 2019 18:51:26 -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-08.txt Pages : 24 Date : 2019-01-23 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framework-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-08 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 Wed Jan 30 16:29: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 2365F130ED6; Wed, 30 Jan 2019 16:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 DefmTjjO7W3H; Wed, 30 Jan 2019 16:29:28 -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 9BC75130EBF; Wed, 30 Jan 2019 16:29:28 -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 x0V0TN8h053750 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Jan 2019 18:29:27 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548894567; bh=14BvB/tVyQl1R09hG4RxcBa/UbFYPhXpo5jkfXQ4MeE=; h=From:Subject:Date:References:To:In-Reply-To; b=vBoU54r3WJVFbpAq1Qa9wZDHIW/7+nXTZk5Nko0pXExBSfthF7ukk0jMLRHBOfya2 anL35wbe6YqEV1fLWIKJrKA9eQTDCgj7oPqcxqS3OiGMKWK3HCaAbZpXdXiWOHorKR Y7bc96vyj3L531BJAtuf6ACfXl8CUzn0RY6vnVqI= 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 Content-Type: multipart/signed; boundary="Apple-Mail=_E8F43F43-2016-429E-AE83-C8C1D7FA62BF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 30 Jan 2019 18:29:20 -0600 References: <154826948191.7542.12732292886038443439@ietfa.amsl.com> To: perc@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org In-Reply-To: <154826948191.7542.12732292886038443439@ietfa.amsl.com> Message-Id: <3A1F17C6-6849-4354-8CE7-FC69C49D77EF@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-private-media-framework-08.txt 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, 31 Jan 2019 00:29:30 -0000 --Apple-Mail=_E8F43F43-2016-429E-AE83-C8C1D7FA62BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This version is much better than 07. Thanks for the work on that. I = think it=E2=80=99s now ready for IETF Last Call. I will request that = shortly. I have a few new minor editorial comments that can be addressed along = with any IETF LC feedback. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 - (Nit) =C2=A71, 2nd paragraph: The new text addresses my concern, but = it added a comma splice. I suggest making the text starting with "this = draft aims=E2=80=A6=E2=80=9D into its own sentence. - Previous Comment: >=20 > =C2=A73.1.2, last paragraph: "In any deployment scenario where the = call processing function is > considered trusted, the call processing function MUST ensure the > integrity of received messages before forwarding to other entities.=E2=80= =9D >=20 > Please describe why that is important in a PERC environment. The text was removed. I assume the authors decided it was not specific = to PERC? - (Nit) =C2=A74.5.2, 3rd paragraph: The change resolves my concern, but I have one editorial suggestion: OLD: When a Key Distributor decides to re-key a conference, it transmits a = new EKTKey message [ I-D.ietf-perc-srtp-ekt-diet to each of the conference participants = containing the new EKT Key. NEW: When a Key Distributor decides to re-key a conference, it transmits a = new EKTKey message containing the new EKT Key [I-D.ietf-perc-srtp-ekt-diet] to each of the = conference participants. - (Nit): New =C2=A76.1: "While the number key types is very small=E2=80=9D= s:/=E2=80=9Cnumber key types=E2=80=9D/=E2=80=9Cnumber of key types" > On Jan 23, 2019, at 12:51 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > 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-08.txt > Pages : 24 > Date : 2019-01-23 >=20 > 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). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08 > = https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framew= ork-08 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-private-media-framewor= k-08 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_E8F43F43-2016-429E-AE83-C8C1D7FA62BF 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxSQWAACgkQgFZKbJXz 1A2T8RAAuwjk56Ii7ELp42G+3jpc6Dq0o8wdSZjXXOHQFUgJcYLApJEk0sjW2D8g M2cBJSiikU8R5tloqRvOm1twGbup5pBXnIIXin/MlX3apV62t3MgRUo/PA+8WTfD LQWqKGw6PheiQUxJHHBkEtse4j3AQmB/5he9vT6cMidbXa3ApAxSAesgPQzL6EAS gZXyzey6YOeClqgswq+7QShLyMuouynYM1CV9gK3xCWNjzllOgsq01vmHB5Ry7ud bc+JB0k/rYrtNk0/zzrK4RQD2XJ4tz64hcXSmdLKHxOPG+R0BN/YmQBYy7km07ah v8+xDlizJ+EhKdkM+UMOaftlsL5LUsxf5Hva09aW3Ga58L+jKVBGB+jNUsYvPgFv icBYiGOWY3mKrC8kktS3joZsfNwVth/6y6/RD0GHuE9Q0nrBIOFRSIYeysE5uRiu TFbpjfRQVvpQyqtppCDqHDsWkMe4YdBC2QjgIOoGdkEe3lks5/SQCMDXvYBLDI+i Ai9xFPW+EZkpPBBIeVGhDfbQe95Bu2uSBfXHGt8NyOYHnAevmSocfgaFaspx+xWC IE0J3qYT+0Ll+8HfUDoLXXz/gj8wDYjSw8C7p05SspROjDO7o02XBwS0l9IIPha4 THMF+COM2Y0DQlY7n/h2X39WiXlNrG/4SyLEhQcN3lVgUHw19oU= =1MDg -----END PGP SIGNATURE----- --Apple-Mail=_E8F43F43-2016-429E-AE83-C8C1D7FA62BF-- From nobody Wed Jan 30 16:44:36 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 57A62126CC7; Wed, 30 Jan 2019 16:44:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk CC: ben@nostrum.com, Nils Ohlmeier , perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org, nohlmeier@mozilla.com, perc-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> Date: Wed, 30 Jan 2019 16:44:29 -0800 Archived-At: Subject: [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 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 00:44:29 -0000 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. From nobody Wed Jan 30 17:41:12 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 42475124D68; Wed, 30 Jan 2019 17:41:11 -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, 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 O_u7iEyQ0bdT; Wed, 30 Jan 2019 17:41:08 -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 3DEC3126CC7; Wed, 30 Jan 2019 17:41:07 -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=1548898865; bh=vYFrJ2sFkhefrOiAOrb9UKj5my60azkTLB0NQaB/PvI=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=qvzG1y5cJVU+bUCcEHwNyKPutAb+pPfQuSZbOJ5uzzEWeil1XG71G31pCqVM9wByi KJD0HdbZrgdv3DyhlcuoHU2tyv9TvmCEGlooODo84wPzll0h63azYH14rdr/xA0CuS rPaVp6CJrWDI8AVUAZeQ97Z5KSEucVIrumBThQRw= From: "Paul E. Jones" To: "Ben Campbell" , perc@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org Date: Thu, 31 Jan 2019 01:41:03 +0000 Message-Id: In-Reply-To: <3A1F17C6-6849-4354-8CE7-FC69C49D77EF@nostrum.com> References: <154826948191.7542.12732292886038443439@ietfa.amsl.com> <3A1F17C6-6849-4354-8CE7-FC69C49D77EF@nostrum.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34208.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB64DBFE57-2ECB-4BD9-92F3-0C537A7162D0" Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-private-media-framework-08.txt 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, 31 Jan 2019 01:41:11 -0000 --------=_MB64DBFE57-2ECB-4BD9-92F3-0C537A7162D0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks! I'll keep this message in my inbox and make changes as requested=20 when creating the next version. For the "The text was removed. I assume the authors decided it was not=20 specific to PERC?" question: I got agreement to remove it. PERC is intended to (and does) provide=20 end-to-end authentication, and the procedures spell out what=20 intermediaries (trusted or otherwise) are supposed to do HBH. This text=20 seemed to suggest there is something special in this case when there=20 isn't. It seemed to add no value, clearly caused confusion, and we could=20 not figure out why it was there in the first place. Paul ------ Original Message ------ From: "Ben Campbell" To: perc@ietf.org; draft-ietf-perc-private-media-framework.all@ietf.org Sent: 1/30/2019 7:29:20 PM Subject: Re: [Perc] I-D Action:=20 draft-ietf-perc-private-media-framework-08.txt >Hi, > >This version is much better than 07. Thanks for the work on that. I think= it=E2=80=99s now ready for IETF Last Call. I will request that shortly. > >I have a few new minor editorial comments that can be addressed along with = any IETF LC feedback. > >Thanks! > >Ben. > >=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > >- (Nit) =C2=A71, 2nd paragraph: The new text addresses my concern, but it = added a comma splice. I suggest making the text starting with "this draft= aims=E2=80=A6=E2=80=9D into its own sentence. > > >- Previous Comment: > >> >> =C2=A73.1.2, last paragraph: "In any deployment scenario where the call = processing function is >> considered trusted, the call processing function MUST ensure the >> integrity of received messages before forwarding to other entities.=E2= =80=9D >> >> Please describe why that is important in a PERC environment. > >The text was removed. I assume the authors decided it was not specific to= PERC? > > >- (Nit) =C2=A74.5.2, 3rd paragraph: > > The change resolves my concern, but I have one editorial suggestion: > >OLD: >When a Key Distributor decides to re-key a conference, it transmits a new= EKTKey message [ >I-D.ietf-perc-srtp-ekt-diet to each of the conference participants contai= ning the new EKT Key. >NEW: >When a Key Distributor decides to re-key a conference, it transmits a new= EKTKey message >containing the new EKT Key [I-D.ietf-perc-srtp-ekt-diet] to each of the co= nference participants. > >- (Nit): New =C2=A76.1: "While the number key types is very small=E2=80=9D >s:/=E2=80=9Cnumber key types=E2=80=9D/=E2=80=9Cnumber of key types" > > > >> On Jan 23, 2019, at 12:51 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >> This draft is a work item of the Privacy Enhanced RTP Conferencing WG= of the IETF. >> >> Title : A Solution Framework for Private Media in Priv= acy Enhanced RTP Conferencing >> Authors : Paul E. Jones >> David Benham >> Christian Groves >> Filename : draft-ietf-perc-private-media-framework-08.txt >> Pages : 24 >> Date : 2019-01-23 >> >> 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-framewor= k/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-08 >> https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-fra= mework-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-perc-private-media-frame= work-08 >> >> >> Please note that it may take a couple of minutes from the time of submi= ssion >> 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/ >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc > --------=_MB64DBFE57-2ECB-4BD9-92F3-0C537A7162D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks! I'll keep this message in my inbox and make change= s as requested when creating the next version.

F= or the "The text was removed. I assume the authors decided it was not speci= fic to PERC?" question:

I got agreement to remov= e it. PERC is intended to (and does) provide end-to-end authentication, and = the procedures spell out what intermediaries (trusted or otherwise) are su= pposed to do HBH. This text seemed to suggest there is something special in = this case when there isn't. It seemed to add no value, clearly caused con= fusion, and we could not figure out why it was there in the first place.

Paul

------ Original Message ------
From: "Ben Campbell" <ben@nostrum.com>
To: perc@ietf.org; draft-ietf-perc-private-media-framework.all@ietf.or= g
Sent: 1/30/2019 7:29:20 PM
Subject: Re: [Perc] I-D Action: draft-ietf-perc-private-media-framewor= k-08.txt

Hi,
=C2=A0
This version is much better than 07. Thanks for t= he work on that. I think it=E2=80=99s now ready for IETF Last Call. I will= request that shortly.
=C2=A0
I have a few new minor editorial comments that ca= n be addressed along with any IETF LC feedback.
=C2=A0
Thanks!
=C2=A0
Ben.
=C2=A0
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94
=C2=A0
- (Nit) =C2=A71, 2nd paragraph: The new text add= resses my concern, but it added a comma splice. I suggest making the text s= tarting with "this draft aims=E2=80=A6=E2=80=9D into its own sentence.
=C2=A0
=C2=A0
- Previous Comment:
=C2=A0
=C2=A0
=C2=A73.1.2, last paragraph: "In any deployment= scenario where the call processing function is
considered trusted, the call processing function = MUST ensure the
integrity of received messages before forwarding = to other entities.=E2=80=9D
=C2=A0
Please describe why that is important in a PERC= environment.
=C2=A0
The text was removed. I assume the authors decide= d it was not specific to PERC?
=C2=A0
=C2=A0
- (Nit) =C2=A74.5.2, 3rd paragraph:
=C2=A0
The change resolves my concern, but I have one e= ditorial suggestion:
=C2=A0
OLD:
When a Key Distributor decides to re-key a confer= ence, it transmits a new EKTKey message [
I-D.ietf-perc-srtp-ekt-diet to each of the confe= rence participants containing the new EKT Key.
NEW:
When a Key Distributor decides to re-key a confer= ence, it transmits a new EKTKey message
containing the new EKT Key [I-D.ietf-perc-srtp-ek= t-diet] to each of the conference participants.
=C2=A0
- (Nit): New =C2=A76.1: "While the number key typ= es is very small=E2=80=9D
s:/=E2=80=9Cnumber key types=E2=80=9D/=E2=80=9Cnu= mber of key types"
=C2=A0
=C2=A0
=C2=A0
On Jan 23, 2019, at 12:51 PM, internet-drafts@ie= tf.org wrote:
=C2=A0
=C2=A0
A New Internet-Draft is available from the on-li= ne Internet-Drafts directories.
This draft is a work item of the Privacy Enhance= d RTP Conferencing WG of the IETF.
=C2=A0
Title : A Solution Framework fo= r Private Media in Privacy Enhanced RTP Conferencing
Authors : Paul E. Jones
David Benham
Christian Groves
Filename : draft-ietf-perc-private-media= -framework-08.txt
Pages : 24
Date : 2019-01-23
=C2=A0
Abstract:
This document describes a solution framework f= or ensuring that media
confidentiality and integrity are maintained e= nd-to-end within the
context of a switched conferencing environment = where media
distributors are not trusted with the end-to-e= nd media encryption
keys. The solution aims to build upon existin= g security mechanisms
defined for the real-time transport protocol (= RTP).
=C2=A0
=C2=A0
The IETF datatracker status page for this draft= is:
https://datatracker.ietf.org/doc/draft-ietf-perc= -private-media-framework/
=C2=A0
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-priv= ate-media-framework-08
https://datatracker.ietf.org/doc/html/draft-ietf= -perc-private-media-framework-08
=C2=A0
A diff from the previous version is available at= :
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p= erc-private-media-framework-08
=C2=A0
=C2=A0
Please note that it may take a couple of minutes = from the time of submission
until the htmlized version and diff are availabl= e at tools.ietf.org.
=C2=A0
Internet-Drafts are also available by anonymous= FTP at:
ftp://ftp.ietf.org/internet-drafts/
=C2=A0
_______________________________________________<= /div>
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
=C2=A0
--------=_MB64DBFE57-2ECB-4BD9-92F3-0C537A7162D0-- From nobody Thu Jan 31 19:51: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 BF95C131200; Thu, 31 Jan 2019 19:51:30 -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 jdnZA15eDxam; Thu, 31 Jan 2019 19:51:27 -0800 (PST) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (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 60F8B1311F8; Thu, 31 Jan 2019 19:51:27 -0800 (PST) Received: by mail-vs1-xe43.google.com with SMTP id y27so3407646vsi.1; Thu, 31 Jan 2019 19:51:27 -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=GgCUKH8NYe8o+jPx3/+TqiWv1Fz4g7PX4aUFxWtutG8=; b=RCncQk5KAK6kd+yxKzKKtE2q3+LkVpdpcTgSU7vN/q/gDTUGYng1YD/31W9A3R2aWw OfmF1/TJIdpvGY3y4dKb81+oxeRPKRFB8GS6uLj/u9eNaZgIRl+bPU9Gmbs4H3OmfvnJ uYx1vJmfpsGoS78+Z8lEhGLluynsPGFpXWjWsQ9166InxUe670Jw+tdFUqiJjJnCFy6H SXu73/Yvx/bx/uYY8V+QJK31eOJqzV34HklL73W7Z7R3mwB3VoBzGXa3EPk8LbHxpWp3 Hw5FHkSkvRt5RnYfXcjxT470bIv/wMrfJsi7d8/ayIwwhpMVRNOSDM2j6aJP7qpzx9ZG LWzg== 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=GgCUKH8NYe8o+jPx3/+TqiWv1Fz4g7PX4aUFxWtutG8=; b=RM3dG/SD6sONIxFUIGSmDLmP+IzFyqv+TmPuIimmbXRy6Liqpb8O5cz2C+BLYNcknA /mdvvlaOlxmMzpfWoHqu6IOl3xLZQsyTPCAvf8dDUWDmjcSKFXiqJBgiXZCEW4QjUFdt 95MnHHgogo/BXuP2+CFBjZ+3hYjYCHerSsEJdEYPPLZBDcXk2s+epgnxKwBRUGkVWMgL qeBVWbvu31cv0kkZo/xQtqmAP2tq7ErMhNQwD5XI7hSM516xoX1vCmn1qOqgnsde7wHC LpjaLUbDMCyIWmQZ+CvVSUJWHbVhTBoGMfA5OBAyUGBNc7yKFFbZuz8jzEsgdqD8x0wF y2fg== X-Gm-Message-State: AHQUAuZCAFovgs/344T7YXzVdhAUsgvThHIw1nrz3RA4pZGvFm1i6Bu5 iwhbpVjiQWC+VQggQL0OkASJI8P3AujDUqx24flja1/J X-Google-Smtp-Source: AHgI3IYRQldQDzBoPeMHmJrVTIF99twnQ5Fg385tFs9EvCRACCGp5kep87cfWKh4Cu7iyke+kM66qrGZQwslX5IjmX0= X-Received: by 2002:a67:f31a:: with SMTP id p26mr2803031vsf.113.1548993085648; Thu, 31 Jan 2019 19:51:25 -0800 (PST) MIME-Version: 1.0 References: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> In-Reply-To: <154889546931.10496.2408974719921724953.idtracker@ietfa.amsl.com> From: Bernard Aboba Date: Thu, 31 Jan 2019 22:51:13 -0500 Message-ID: To: ietf@ietf.org Cc: perc@ietf.org, Emil Ivov , Emad Omara , Alexandre GOUAILLARD , The IESG Content-Type: multipart/alternative; boundary="000000000000a134a60580cd0e4a" 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 03:51:31 -0000 --000000000000a134a60580cd0e4a Content-Type: text/plain; charset="UTF-8" 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. 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. 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 > --000000000000a134a60580cd0e4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My review of=C2=A0draft-= ietf-perc-private-media-framework-08, found below, represents my personal o= pinion.=C2=A0

In reading this document= , I was disappointed to find that it did not address some key issues that h= ave been encountered by implementers. I therefore feel that 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 Endpo=
int: 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 a=
pplications. 

=

In these situatio=
ns, an "endpoint" may represent a unitary native application, or =
potentially an application written in
Javascript or WASM running on a browser platform.  In s=
uch 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 pr=
ovider of the MDD or key management server, etc.  In such situations, the d=
efinition of
"=
;trusted endpoint" provided in this document becomes difficult to appl=
y. 

This point has been underli=
ned by a recent IESG note sent to the W3C WEBRTC WG which has been attempti=
ng 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 na=
ture of a "trusted endpoint", but was disappointed that few of th=
e points made by the IESG
were expounded upon in the document.  Since the IETF generally requ=
ires documents to stand on their own without the 
need for IESG interpretation, this appears =
to represent a serious inadequacy in the current framework document. 


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

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

   Media Distributor (MD): An RTP midd=
lebox 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 cons=
traints
   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.<=
/span> 

The Selective Forw=
arding Middlebox is described in RFC 7667 Section 3.7 as follows:
   Another m=
ethod 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 an=
d RTCP packets.  Yet my reading of the framework document is that such rewr=
iting
could be pro=
blematic, since Section 4.3 of the framework document notes that the SSRC
is utilized to iden=
tify which E2E keys are to be used to decrypt a given RTP media flow:
=

4.3.  E2E Keys and Endpoint Operat=
ions


   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, i=
t 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
implicat=
ions are for existing implementations.=20

On Wed, Jan 30, 2019 at 7:45 PM The IESG &l= t;iesg-secretary@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
--000000000000a134a60580cd0e4a--