From nobody Fri Mar 1 07:38: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 5300F12F295 for ; Fri, 1 Mar 2019 07:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns0emFcgb45f for ; Fri, 1 Mar 2019 07:38:14 -0800 (PST) Received: from smtp69.iad3b.emailsrvr.com (smtp69.iad3b.emailsrvr.com [146.20.161.69]) (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 E9ACD124C04 for ; Fri, 1 Mar 2019 07:38:13 -0800 (PST) Received: from smtp17.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id C926CA0370; Fri, 1 Mar 2019 10:38:12 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 24CA9A0384; Fri, 1 Mar 2019 10:38:12 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 01 Mar 2019 10:38:12 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_FCFDDC63-DDDC-4621-9713-532DE771A5E8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Cullen Jennings In-Reply-To: Date: Fri, 1 Mar 2019 08:38:10 -0700 Cc: Sergio Garcia Murillo , "perc@ietf.org" Message-Id: References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> To: Alexandre GOUAILLARD X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 15:38:16 -0000 --Apple-Mail=_FCFDDC63-DDDC-4621-9713-532DE771A5E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s a very reasonable request to ask for more info here but = given that huge amounts of WG meeting were devoted to this, I am certain = not going to try and explain the whole splicing attack. However to get to the heart of why the MID is different than the SSRC in = the splicing attack, the key thing with the splicing attack is the = attacker gets the receiver to use a valid, but not really the correct, = SRTP crypto context. As outlined in = https://tools.ietf.org/html/rfc3711#section-3.2 = , the crypto context = looked up from dest IP:port and SSRC. So changing the SSRC allows the = attacker in the splicing attack to switch to a crypto context of the = attackers choosing (and one the attacker has keys for). Changing the = other things such as the MID does not allow this.=20 > On Feb 24, 2019, at 1:01 AM, Alexandre GOUAILLARD = wrote: >=20 > Cullen, >=20 > Would you mind to give more detail as to why you think it's different? = =46rom where we stand, both approaches end-up deceiving the receiver = into believing some media is coming from one source while it's not. With = that definition of "effect", both the src splicing attack and Sergio = proposed attack have the same effect. > Agreed, PERC addresses the case where it is due to SSRC manipulation, = but if it does not address the other ways to achieve the same effect, it = still fail at protecting the receiver, at the perceived huge cost of = removing the capacity to support other important use cases cited before. >=20 > Do you have an implementation of PERC, as promised at IETF'99, for us = and others to test against? >=20 > Beyond the difference, do you think that the scenario sergio proposed: > - is a real problem ? > - should be addressed ? >=20 > Sergio, > feel free to prepare a working demo to make your point. If I = understand correctly, what you propose can be done today already quite = easily. >=20 >=20 >=20 >=20 >=20 > On Sun, Feb 24, 2019 at 10:11 AM Cullen Jennings > wrote: >=20 >=20 >> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo = > wrote: >>=20 >> In the media framework it is stated the following regarding SSRC = splicing attacks: >>=20 >> The splicing attack is an attack where a Media Distributor = receiving >> multiple media sources splices one media stream into the other. = If >> the Media Distributor is able to change the SSRC without the = receiver >> having any method for verifying the original source ID, then the >> Media Distributor could first deliver stream A and then later = forward >> stream B under the same SSRC as stream A was previously using. By >> not allowing the Media Distributor to change the SSRC, PERC = mitigates >> this attack. >> However, if BUNDLE and MID are used, and there is no ssrc signaling = done in SDP, the following RTP demuxing rules from BUNDLE spec applies: >>=20 >> If the packet has a MID, and the packet's extended sequence number >> is greater than that of the last MID update, as discussed in >> [RFC7941], Section=C2=A04.2.6 = , update the MID = associated with the RTP >> stream to match the MID carried in the RTP packet, then update the >> mapping tables to include an entry that maps the SSRC of that RTP >> stream to the "m=3D" section for that MID. >> Given that MID is by definition HBH as it must match the negotiated = SDP O/A, then the MD could arbitrarily change the MID for an RTP packet = and associate it with whatever transceiver it wishes, effectively having = the same effect than the SSRC splicing attack (at least in perc double = where all participants share the same inner e2e key and there). >>=20 >>=20 >=20 > No, it would not have the same effect at all.=20 >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = >=20 >=20 > --=20 > Alex. Gouaillard, PhD, PhD, MBA > = --------------------------------------------------------------------------= ---------- > President - CoSMo Software Consulting, Singapore > = --------------------------------------------------------------------------= ---------- > sg.linkedin.com/agouaillard >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_FCFDDC63-DDDC-4621-9713-532DE771A5E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

It=E2=80=99s a very reasonable request = to ask for more info here but given that huge amounts of WG meeting were = devoted to this, I am certain not going to try and explain the whole = splicing attack.

However to get to the heart of why the MID is different than = the SSRC in the splicing attack,  the key thing with the splicing = attack is the attacker gets the receiver to use a valid, but not really = the correct, SRTP crypto context. As outlined in https://tools.ietf.org/html/rfc3711#section-3.2 , = the crypto context looked up from dest IP:port and SSRC. So changing the = SSRC allows the attacker in the splicing attack to switch to a crypto = context of the attackers choosing (and one the attacker has keys for). = Changing the other things such as the MID does not allow this. 

On Feb 24, 2019, at 1:01 AM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:

Cullen,

Would you mind to give more detail as to why you think it's = different? =46rom where we stand, both approaches end-up deceiving the receiver into believing some = media is coming from one source while it's not. With that = definition of "effect", both the src splicing attack and Sergio proposed = attack have the same effect.
Agreed, PERC addresses = the case where it is due to SSRC manipulation, but if it does not = address the other ways to achieve the same effect, it still fail at = protecting the receiver, at the perceived huge cost of removing the = capacity to support other important use cases cited before.

Do you have an = implementation of PERC, as promised at IETF'99, for us and others to = test against?

Beyond the difference, do you think that the scenario sergio = proposed:
- is a real problem ?
- should be addressed ?

Sergio,
feel free = to prepare a working demo to make your point. If I understand correctly, = what you propose can be done today already quite easily.





On Sun, Feb 24, 2019 at 10:11 AM Cullen = Jennings <fluffy@iii.ca> wrote:

On Feb 21, 2019, at 11:02 AM, Sergio Garcia = Murillo <sergio.garcia.murillo@gmail.com> = wrote:

In the = media framework it is stated the following regarding SSRC splicing = attacks:

   The splicing attack is an attack where a Media =
Distributor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.

However, = if BUNDLE and MID are used, and there is no ssrc signaling done in SDP, = the following RTP demuxing rules from BUNDLE spec applies:

   If the packet has a MID, and the packet's =
extended sequence number
   is greater than that of the last MID update, as discussed in
   [RFC7941], Section 4.2.6, update =
the MID associated with the RTP
   stream to match the MID carried in the RTP packet, then update the
   mapping tables to include an entry that maps the SSRC of that RTP
   stream to the "m=3D" section for that MID.

Given = that MID is by definition HBH as it must match the negotiated SDP O/A, = then the MD could arbitrarily change the MID for an RTP packet and = associate it with whatever transceiver it wishes, effectively having the = same effect than the SSRC splicing attack (at least in perc double where = all participants share the same inner e2e key and there).



No, it would not have the = same effect at all. 


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


--
Alex. Gouaillard, PhD, PhD, MBA
---------------------------------------------------------------= ---------------------
President - CoSMo Software = Consulting, Singapore
---------------------------------------------------------------= ---------------------

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

= --Apple-Mail=_FCFDDC63-DDDC-4621-9713-532DE771A5E8-- From nobody Fri Mar 1 08:18: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 436F712F1AC for ; Fri, 1 Mar 2019 08:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEKLIRW9uuZV for ; Fri, 1 Mar 2019 08:18:37 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625D7124C04 for ; Fri, 1 Mar 2019 08:18:37 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id a62so13113779wmh.4 for ; Fri, 01 Mar 2019 08:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=C5r5wzEOIOttGL+qKZ2jgBc+Tvrt4UBCqyFuNMc2Y0g=; b=seRQSLZeUwXG+JVaH0pvPXSU3z5l4DM4megZYApvwFz2+wr6eReowuhvH0Ge8BcJ6y 2T2TeRwVwiAsByq+5yeLX5vZfqp8ILTGmp6yrcm8KwOaRK0R4BQg050cjmstRRVLzg2j VoowtXl7ztSj2Tgc0Rton4DBDks2upyMD+YmdrSfZ0d2Ct/iSMc/2IW9pMP0fBFyXJ2L 7vRHc8c+nVvvUxp3m+RCE2/DHKaWvTjs4fS0ajRi9L8mvt0tC66yQT86BUyLJj2JwgUu 1Sux1qLiZzBcsnbhB0ig7FuKgCLhuoCZoo8jvM1lf+630uLGDICEVT+0WS+LUzjGYPej g3UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=C5r5wzEOIOttGL+qKZ2jgBc+Tvrt4UBCqyFuNMc2Y0g=; b=bGPVxsHkuuJs9RnKsh1z9ALMyD0RRAFOFCU0JQ+qYx0WVFEZOvptF5cacBrspCy0UF EaihzwkbB6FMfwGz+Hi3Zsf0OOcRV+wBa8Cj9YbI8qpAbvi0meiGJgrs4IPSAnbBlzR9 OjpEMUS4VAgNJbT6RsPF/aHwIwKO7qGFng8FKshVn85LXQFgo23fFu0qXVjFa/ddKG1W und/weh/Feyz/HDgnm+AKflrn/bEewP0qzIO1VZTLYUro2R3FkqsHT4TfFn/nPAFyrbc ZIjDaR/C3k/gzRX5i56uScW91z20PI/TC2MdQTZC2j4ESnl7b8XPhUxdmpX6PhJEVKDV U/7w== X-Gm-Message-State: AHQUAubGgpGWNEFU1CcFQXDUsNWNjfsuKcP/n9vmrx7ykv09qZzUqgrS PtBIvDwYjAB/e77kw1ou5194vm0J X-Google-Smtp-Source: APXvYqx6JjapdXTCDUgtcVkaXOqheVzLVPtxINR/TlvWAPVSzEunpABwipAJ28BRPzt+9DMyuIZLHg== X-Received: by 2002:a7b:c777:: with SMTP id x23mr3825071wmk.71.1551457115496; Fri, 01 Mar 2019 08:18:35 -0800 (PST) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id h9sm49906879wrv.11.2019.03.01.08.18.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 08:18:34 -0800 (PST) To: Cullen Jennings , Alexandre GOUAILLARD Cc: "perc@ietf.org" References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> From: Sergio Garcia Murillo Message-ID: <23404598-2ded-8584-3bea-f8160a59160c@gmail.com> Date: Fri, 1 Mar 2019 17:23:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D60722BB95D34DD490F6AC7D" Content-Language: en-US Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 16:18:40 -0000 This is a multi-part message in MIME format. --------------D60722BB95D34DD490F6AC7D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 01/03/2019 16:38, Cullen Jennings wrote: > However to get to the heart of why the MID is different than the SSRC > in the splicing attack,  the key thing with the splicing attack is the > attacker gets the receiver to use a valid, but not really the correct, > SRTP crypto context. As outlined in > https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context > looked up from dest IP:port and SSRC. So changing the SSRC allows the > attacker in the splicing attack to switch to a crypto context of the > attackers choosing (and one the attacker has keys for). Changing the > other things such as the MID does not allow this. You are describing how ssrc splicing works, not what are its effects, or why it is an issue. I think I have found the origin of the ssrc rewriting issue and the splicing attack for perc in here: https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt 3.9. SSRC The SSRC identifies the source of the RTP packet. As each SSRC has its own RTP sequence number space as well as timestamp sequence, collisions shall be avoided. For the PERC usage it is also important that a receiving endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias). The important security related issue is that unless the originating RTP stream can be identified the MDD could create one outgoing stream that selects packets from either of them. This may be challenging due to replay protection, but not impossible depending on how the sequence number and timestamps align. To avoid having multiple identifers for the RTP packet stream, the design team has proposed that the SSRC shall be unique and the original value preserved to the receiving endpoint. Even if the originating endpoints have unique SSRCs, it is not clear if the same requirement will be extended to the MDD, and then especially media switching RTP mixers that have their own SSRCs. Thus translation of SSRC as a method for dealing with SSRC collisions may need to be dealt with. The original SSRC needs to be authenticated end-to-end to prevent the splicing attack described above. So the main issue here is that  "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc. Best regards Sergio --------------D60722BB95D34DD490F6AC7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 01/03/2019 16:38, Cullen Jennings wrote:
However to get to the heart of why the MID is different than the SSRC in the splicing attack,  the key thing with the splicing attack is the attacker gets the receiver to use a valid, but not really the correct, SRTP crypto context. As outlined in https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context looked up from dest IP:port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choosing (and one the attacker has keys for). Changing the other things such as the MID does not allow this. 


You are describing how ssrc splicing works, not what are its effects, or why it is an issue. I think I have found the origin of the ssrc rewriting issue and the splicing attack for perc in here:

https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt
3.9.  SSRC

   The SSRC identifies the source of the RTP packet.  As each SSRC has
   its own RTP sequence number space as well as timestamp sequence,
   collisions shall be avoided.  For the PERC usage it is also important
   that a receiving endpoint can separate two different originating
   sources and to map the SSRC to a human readable name (or alias).  The
   important security related issue is that unless the originating RTP
   stream can be identified the MDD could create one outgoing stream
   that selects packets from either of them.  This may be challenging
   due to replay protection, but not impossible depending on how the
   sequence number and timestamps align.  To avoid having multiple
   identifers for the RTP packet stream, the design team has proposed
   that the SSRC shall be unique and the original value preserved to the
   receiving endpoint.

   Even if the originating endpoints have unique SSRCs, it is not clear
   if the same requirement will be extended to the MDD, and then
   especially media switching RTP mixers that have their own SSRCs.
   Thus translation of SSRC as a method for dealing with SSRC collisions
   may need to be dealt with.

   The original SSRC needs to be authenticated end-to-end to prevent the
   splicing attack described above.

So the main issue here is that  "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc.


Best regards

Sergio

--------------D60722BB95D34DD490F6AC7D-- From nobody Fri Mar 1 09:19:49 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 ADEB8128CE4; Fri, 1 Mar 2019 09:19:47 -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 m_rrj4O5QUYE; Fri, 1 Mar 2019 09:19:44 -0800 (PST) Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) (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 A01B912008A; Fri, 1 Mar 2019 09:19:43 -0800 (PST) Received: by mail-ua1-x943.google.com with SMTP id u1so22446452uae.12; Fri, 01 Mar 2019 09:19:43 -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=AU7+hv/7+52M64QvplAZ+7nNQnBYoL0DehljUD5qaqU=; b=hB1vA6GvsVE0ZWNNXRl5wCJRhxgesYFGMShnGHJUhBsi2Ibek6iwJ5auSoOE82mpnv Wy9hYhCt2PjkbTZqY/ftZiCUve8UiSUTmGfFhYSMUqDIg27c6EemyeHlJj9SwaLjJdrE 76b03z7RO+MVMWOFcL77u+pZIo2fyq+sP6BHI4wsBCNxhq4xOwPvKHhIMSZdBNCh4SNt D/uH/ImpZ8oLSguqHOrwHB8XvvtDGhxCuEedABMqyi8Pv+QiShwKBqr5ywGQ7m5jpUxT K/KCSVGKWDK5gtawdUG/hgbte1k3c2Zzf0e3nnAw5vVLG1ysXr05gn5doVJfbsUkEZsk 35jQ== 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=AU7+hv/7+52M64QvplAZ+7nNQnBYoL0DehljUD5qaqU=; b=E/GFKt0KC5wjTFUEK9f+Mub/eM3IXUE187Qt+zfiQuwqNt6d6RCyu3MiC9DRn5WcU8 APNsmkmqwb61w5fJQwZP/YtNmB9Myb9QOvu+/q9yPIatqXLjWlaRdn08j0ge0gx9JyX7 wJMPFw92a3AZ5PP1WWnqA1T5k2K7vawmn2bhVQc6hY3doxJnQtGTWUTFtnRM40H5Lbv7 HNSbpMDv17qfa5Vuu2LIZb5ypy+q6A7VePxx1Np3Il4Y2LD3atTuB4Ke0eCCcw+CxCSd 0BWRHNk1/ZGQWUCT8eOpx9P/jo4HE51a5CA4OhbikFjBh0MQKEn7Fx5g6gUgHy6IGor3 AqFg== X-Gm-Message-State: APjAAAWyOC5kUtemYz+MJ0UCXfV6TtBVv6cB2jmNdgywZGSsQlfW+/of af/jpmRiAGpVPHpC1aSpzr7Ln3q+McBam1R+TA4= X-Google-Smtp-Source: APXvYqxjr8oyh9V8Lxt1G1eKI/KRq+u2T6aeKesfZotXtOkl6vV00OYnQ6buZLGMsfb6J1IFNpfDMS8rMskIHW8x4JM= X-Received: by 2002:a67:f41a:: with SMTP id p26mr3229378vsn.140.1551460781598; Fri, 01 Mar 2019 09:19:41 -0800 (PST) MIME-Version: 1.0 References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> <23404598-2ded-8584-3bea-f8160a59160c@gmail.com> In-Reply-To: <23404598-2ded-8584-3bea-f8160a59160c@gmail.com> From: Bernard Aboba Date: Fri, 1 Mar 2019 09:19:31 -0800 Message-ID: To: Sergio Garcia Murillo , Emil Ivov Cc: Cullen Jennings , Alexandre GOUAILLARD , "perc@ietf.org" , IETF discussion list Content-Type: multipart/alternative; boundary="000000000000c52f7105830b9cc7" Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 17:19:48 -0000 --000000000000c52f7105830b9cc7 Content-Type: text/plain; charset="UTF-8" Sergio said: "So the main issue here is that "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc." [BA] Let me attempt to unpack this. There are two issues here, which relate to: 1. Effects of changing the RTP header SSRC 2. Effects of manipulating the original" SSRC associated with the e2e keys. Taking each in turn: 1. Changing the RTP header SSRC affects the routing of audio/video seen by the user but does not affect the integrity of media, which is protected by the e2e keys. By changing the RTP header SSRC it is possible to "splice" the media or cause the a/v rendered in audio/video tags to switch between users (e.g. dominant speaker protection). As we have discussed this is very common and causes few problems today, so it really can't be thought of as an "attack". 2. I believe this is the aspect Cullen is referring to, which provides an attacker with the ability to fool an endpoint into accepting as authentic a manipulated payload. This can be used to create a "deep fakes" so it is a genuine attack. Addressing this doesn't require outlawing the modification of the RTP header SSRC. If the original SSRC is included in the payload in cleartext and integrity protected along with the rest of the payload, then the payload crypto-context is unaffected by modifications to the SSRC included in the RTP header. The endpoint determines the appropriate keys for integrity protection and payload decryption from the payload SSRC, not the RTP header SSRC. Of course, for this to work, conference participants cannot be allowed to masquerade as each other. That is, if multiple conference endpoints possess the e2e keys used to encrypt and integrity protect payload data, then they can source "deep fake" media that appears to originate from another party. As you have pointed out, this is a fundamental problem that the PERC framework does not address. However, it can be addressed if trust is rooted in hardware (e.g. the TPM) and that e2e keys are not accessible to the endpoints (either Javascript or the browser). AFAICT, PERC key management doesn't meet this requirement, but some content protection schemes claim to do so. On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 01/03/2019 16:38, Cullen Jennings wrote: > > However to get to the heart of why the MID is different than the SSRC in > the splicing attack, the key thing with the splicing attack is the > attacker gets the receiver to use a valid, but not really the correct, SRTP > crypto context. As outlined in > https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context > looked up from dest IP:port and SSRC. So changing the SSRC allows the > attacker in the splicing attack to switch to a crypto context of the > attackers choosing (and one the attacker has keys for). Changing the other > things such as the MID does not allow this. > > > You are describing how ssrc splicing works, not what are its effects, or > why it is an issue. I think I have found the origin of the ssrc rewriting > issue and the splicing attack for perc in here: > > https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt > > 3.9. SSRC > > The SSRC identifies the source of the RTP packet. As each SSRC has > its own RTP sequence number space as well as timestamp sequence, > collisions shall be avoided. For the PERC usage it is also important > that a receiving endpoint can separate two different originating > sources and to map the SSRC to a human readable name (or alias). The > important security related issue is that unless the originating RTP > stream can be identified the MDD could create one outgoing stream > that selects packets from either of them. This may be challenging > due to replay protection, but not impossible depending on how the > sequence number and timestamps align. To avoid having multiple > identifers for the RTP packet stream, the design team has proposed > that the SSRC shall be unique and the original value preserved to the > receiving endpoint. > > Even if the originating endpoints have unique SSRCs, it is not clear > if the same requirement will be extended to the MDD, and then > especially media switching RTP mixers that have their own SSRCs. > Thus translation of SSRC as a method for dealing with SSRC collisions > may need to be dealt with. > > The original SSRC needs to be authenticated end-to-end to prevent the > splicing attack described above. > > So the main issue here is that "endpoint can separate two different > originating sources and to map the SSRC to a human readable name (or > alias)". By modifying the MIDs the MD is able to do exactly that, and have > the same effect than splicing attack without having to rewrite the ssrcs, > that is, the endpoint will not be able to differentiate rtp packets coming > from two different sources as the MID is used for routing and not the ssrc. > > > Best regards > > Sergio > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --000000000000c52f7105830b9cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"So the main is= sue here is that=C2=A0 "endpoint can separate two different originatin= g sources and to map the SSRC to a human readable name (or alias)". By= modifying the MIDs the MD is able to do exactly that, and have the same ef= fect than splicing attack without having to rewrite the ssrcs, that is, the= endpoint will not be able to differentiate rtp packets coming from two dif= ferent sources as the MID is used for routing and not the ssrc."
=

[BA] Let me attempt to unpack this. There are two issue= s here, which relate to:

1. Effects of changing th= e RTP header SSRC

2. Effects of manipulating the o= riginal" SSRC associated with the e2e keys.=C2=A0=C2=A0

=
Taking each in turn:=C2=A0

1. Changing = the RTP header SSRC affects the routing of audio/video seen by the user but= does not affect the integrity of media, which is protected by the e2e keys= . By changing the RTP header SSRC it is possible to "splice" the = media or cause the a/v rendered in audio/video tags to switch between users= (e.g. dominant speaker protection).=C2=A0 As we have discussed this is ver= y common and causes few problems today, so it really can't be thought o= f as an "attack".=C2=A0

2. I believe thi= s is the aspect Cullen is referring to, which provides an attacker with the= ability to fool an endpoint into accepting as authentic a manipulated payl= oad.=C2=A0 This can be used to create a "deep fakes" so it is a g= enuine attack.=C2=A0

Addressing this doesn't r= equire outlawing the modification of the RTP header SSRC.=C2=A0 If the orig= inal SSRC is included in the payload in cleartext and integrity protected a= long with the rest of the payload, then the payload crypto-context is unaff= ected by modifications to the SSRC included in the RTP header.=C2=A0 The en= dpoint determines the appropriate keys for integrity protection and payload= decryption from the payload SSRC, not the RTP header SSRC.=C2=A0

Of course, for this to work, conference participants cannot= be allowed to masquerade as each other.=C2=A0 That is, if multiple confere= nce endpoints possess the e2e keys used to encrypt and integrity protect pa= yload data, then they can source "deep fake" media that appears t= o originate from another party.=C2=A0 As you have pointed out, this is a fu= ndamental problem that the PERC framework does not address.=C2=A0

However, it can be addressed if trust is rooted in hardware= (e.g. the TPM) and that e2e keys are not accessible to the endpoints (eith= er Javascript or the browser).=C2=A0 AFAICT, PERC key management doesn'= t meet this requirement, but some content protection schemes claim to do so= .=C2=A0

On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.c= om> wrote:
On 01/03/2019= 16:38, Cullen Jennings wrote:
However to get to the heart of why the MID is different than the SSRC in the splicing attack, =C2=A0the key thing with the splicing attack is the attacker gets the receiver to use a valid, but not really the correct, SRTP crypto context. As outlined in=C2=A0https://tools.ie= tf.org/html/rfc3711#section-3.2=C2=A0, the crypto context looked up from dest IP:port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choosing (and one the attacker has keys for). Changing the other things such as the MID does not allow this.=C2=A0


You are describing how ssrc splicing works, not what are its effects, or why it is an issue. I think I have found the origin of the ssrc rewriting issue and the splicing attack for perc in here: https://www.ietf.org/archive/id/draft-westerlund-p= erc-rtp-field-considerations-00.txt

3.=
9.  SSRC

   The SSRC identifies the source of the RTP packet.  As each SSRC has
   its own RTP sequence number space as well as timestamp sequence,
   collisions shall be avoided.  For the PERC usage it is also important
   that a receiving endpoint can separate two different originating
   sources and to map the SSRC to a human readable name (or alias).  The
   important security related issue is that unless the originating RTP
   stream can be identified the MDD could create one outgoing stream
   that selects packets from either of them.  This may be challenging
   due to replay protection, but not impossible depending on how the
   sequence number and timestamps align.  To avoid having multiple
   identifers for the RTP packet stream, the design team has proposed
   that the SSRC shall be unique and the original value preserved to the
   receiving endpoint.

   Even if the originating endpoints have unique SSRCs, it is not clear
   if the same requirement will be extended to the MDD, and then
   especially media switching RTP mixers that have their own SSRCs.
   Thus translation of SSRC as a method for dealing with SSRC collisions
   may need to be dealt with.

   The original SSRC needs to be authenticated end-to-end to prevent the
   splicing attack described above.

So the main issue here is that=C2=A0 "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able = to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc.


Best regards

Sergio

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--000000000000c52f7105830b9cc7-- From nobody Sat Mar 2 23:15:52 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 C8E2812008F for ; Sat, 2 Mar 2019 23:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21JoRVjBZFZQ for ; Sat, 2 Mar 2019 23:15:48 -0800 (PST) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 1FD80126D00 for ; Sat, 2 Mar 2019 23:15:48 -0800 (PST) Received: by mail-vk1-xa34.google.com with SMTP id v131so454485vkd.3 for ; Sat, 02 Mar 2019 23:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FuHFNJS4GOUAW4jwp+WJkW+91E4hxKtZ4bWFX+IOkKc=; b=Z0fGbuBqwfOgm3SRv4syW5chho+1nzaTHXklbpTH18u0cSFo6xJJ7RgXtUPKWvZbvq 9/NjyubkskHl0Gjde9y6cgCf/fN+ih4v0o1Io+8va86LQRcAQcqrmXXzjSSoPbEQMtca QbZ/3Lt3fwLe7491xxpy1Ir+F4iAwGWmFrJ30OBLdZygfuij+8g+ON5OYbDy3Tv2dPFW APuaerjXosrGpte3eST+riObWPs+a+IIVAzs8S2O2FWsovjOrtxez/rfjlrNTRofkWjZ vAy3TDwgunSfWuoZPwJAhq8OeMyUu2dP4KIm3gVo+AoNIx7BXnOYvUTc7lD/4NXk37FJ MvtQ== 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=FuHFNJS4GOUAW4jwp+WJkW+91E4hxKtZ4bWFX+IOkKc=; b=tHMdngI8IJr422Q7+yg8WTTeEcT0AC1vpBgP0Jhbmu/Z717aNd/kWS3y0/QlNQGbB6 HZPyy2KANMOqCsfQfKeMqTyU5ukl7Q/ZvLIZz7y/+1SENVeoQ71ajVYtSvRMvZ5EgjON 6B9qCo79m+j9LvNTco6rrowW4k0PXYjndkb00HF4pdDkG8LEaHiPqJmjN0Mj/3TS0ktI 9R54HUU01Xa+WlG5zu0VdNILV1MzxyMMFiV0nH9gcnsLOfdOiAO/NbX1b/6Wrjzk6RjI nhV7YSXLLTc2WmANu81dDisF4a5cQJCtVq98kGcr5tQM+wLCW2NNdEHQUjU4uxdN0o55 AfNw== X-Gm-Message-State: APjAAAXfYhtxOVeZYWVcApRtENg8e0m4TtwJIw2fvaNgXBYdbC3qdg4v G2Mn410+F7zxwCCY9tgRiGPzJTvidjpIM70vpbhUNQ== X-Google-Smtp-Source: APXvYqxuq84THbogYeryBrHw9lEHVQ0XCYOqybWmozyi9TZRRL1AvyIc7dq33NufTgITlyYKryAyLRvwgGoi+x97mAA= X-Received: by 2002:a1f:381:: with SMTP id f1mr7176401vki.29.1551597346516; Sat, 02 Mar 2019 23:15:46 -0800 (PST) MIME-Version: 1.0 References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> In-Reply-To: From: Emil Ivov Date: Sun, 3 Mar 2019 07:15:35 +0000 Message-ID: To: Cullen Jennings Cc: Alexandre GOUAILLARD , Sergio Garcia Murillo , "perc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ac8ab005832b6827" Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 07:15:51 -0000 --000000000000ac8ab005832b6827 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri 1 Mar 2019 at 15:38, Cullen Jennings wrote: > > It=E2=80=99s a very reasonable request to ask for more info here but give= n that > huge amounts of WG meeting were devoted to this, I am certain not going t= o > try and explain the whole splicing attack. > Throughout the considerable WG time devoted to this so called attack, you have never really bothered to present anything but handwaiving about it. This is beyond ridiculous. As Bernard points out, any actual attempt to think of splicing here results in schemes that are as easy to thwart as adding a simple comparison with the SSRC in the OHB. Emil > However to get to the heart of why the MID is different than the SSRC in > the splicing attack, the key thing with the splicing attack is the > attacker gets the receiver to use a valid, but not really the correct, SR= TP > crypto context. As outlined in > https://tools.ietf.org/html/rfc3711#section-3.2 , the crypto context > looked up from dest IP:port and SSRC. So changing the SSRC allows the > attacker in the splicing attack to switch to a crypto context of the > attackers choosing (and one the attacker has keys for). Changing the othe= r > things such as the MID does not allow this. > > > On Feb 24, 2019, at 1:01 AM, Alexandre GOUAILLARD > wrote: > > Cullen, > > Would you mind to give more detail as to why you think it's different? > From where we stand, both approaches end-up deceiving the receiver into > believing some media is coming from one source while it's not. With that > definition of "effect", both the src splicing attack and Sergio proposed > attack have the same effect. > Agreed, PERC addresses the case where it is due to SSRC manipulation, but > if it does not address the other ways to achieve the same effect, it stil= l > fail at protecting the receiver, at the perceived huge cost of removing t= he > capacity to support other important use cases cited before. > > Do you have an implementation of PERC, as promised at IETF'99, for us and > others to test against? > > Beyond the difference, do you think that the scenario sergio proposed: > - is a real problem ? > - should be addressed ? > > Sergio, > feel free to prepare a working demo to make your point. If I understand > correctly, what you propose can be done today already quite easily. > > > > > > On Sun, Feb 24, 2019 at 10:11 AM Cullen Jennings wrote: > >> >> >> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >> In the media framework it is stated the following regarding SSRC splicin= g >> attacks: >> >> The splicing attack is an attack where a Media Distributor receiving >> multiple media sources splices one media stream into the other. If >> the Media Distributor is able to change the SSRC without the receiver >> having any method for verifying the original source ID, then the >> Media Distributor could first deliver stream A and then later forward >> stream B under the same SSRC as stream A was previously using. By >> not allowing the Media Distributor to change the SSRC, PERC mitigates >> this attack. >> >> However, if BUNDLE and MID are used, and there is no ssrc signaling done >> in SDP, the following RTP demuxing rules from BUNDLE spec applies: >> >> If the packet has a MID, and the packet's extended sequence number >> is greater than that of the last MID update, as discussed in >> [RFC7941], Section 4.2.6 , update the MID associated with the RTP >> stream to match the MID carried in the RTP packet, then update the >> mapping tables to include an entry that maps the SSRC of that RTP >> stream to the "m=3D" section for that MID. >> >> Given that MID is by definition HBH as it must match the negotiated SDP >> O/A, then the MD could arbitrarily change the MID for an RTP packet and >> associate it with whatever transceiver it wishes, effectively having the >> same effect than the SSRC splicing attack (at least in perc double where >> all participants share the same inner e2e key and there). >> >> >> No, it would not have the same effect at all. >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > -------------------------------------------------------------------------= ----------- > President - CoSMo Software Consulting, Singapore > > -------------------------------------------------------------------------= ----------- > sg.linkedin.com/agouaillard > > - > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --=20 sent from my mobile --000000000000ac8ab005832b6827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri 1 Mar 2019 at 15:38, Cullen Jennings <fluffy@iii.ca> wrote:

It=E2=80=99s a very reasonable request to ask for more= info here but given that huge amounts of WG meeting were devoted to this, = I am certain not going to try and explain the whole splicing attack.
<= /blockquote>

Throughout the co= nsiderable WG time devoted to this so called attack, you have never really = bothered to present anything but handwaiving about it. This is beyond ridic= ulous.

As Bernard points= out, any actual attempt to think of splicing here results in schemes that = are as easy to thwart =C2=A0as adding a simple comparison with the SSRC in = the OHB.

Emil



However to get to the heart of why the MID is different th= an the SSRC in the splicing attack, =C2=A0the key thing with the splicing a= ttack is the attacker gets the receiver to use a valid, but not really the = correct, SRTP crypto context. As outlined in=C2=A0https://tools.ietf.org= /html/rfc3711#section-3.2=C2=A0, the crypto context looked up from dest= IP:port and SSRC. So changing the SSRC allows the attacker in the splicing= attack to switch to a crypto context of the attackers choosing (and one th= e attacker has keys for). Changing the other things such as the MID does no= t allow this.=C2=A0


On Fe= b 24, 2019, at 1:01 AM, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:
=
Cullen,

Would you mind to give more detail as t= o why you think it's different? From where we stand, both approaches en= d-up deceiving the receiver into believing some med= ia is coming from one source while it's not. With that definitio= n of "effect", both the src splicing attack and Sergio proposed a= ttack have the same effect.
Agreed, PERC addresses the case where= it is due to SSRC manipulation, but if it does not address the other ways = to achieve the same effect, it still fail at protecting the receiver, at th= e perceived huge cost of removing the capacity to support other important u= se cases cited before.

Do you have an implementati= on of PERC, as promised at IETF'99, for us and others to test against?<= /div>

Beyond the difference, do you think that the scena= rio sergio proposed:
- is a real problem ?
- should be = addressed ?

Sergio,
feel free to prepare= a working demo to make your point. If I understand correctly, what you pro= pose can be done today already quite easily.


<= /div>



On Sun, Feb 24, 2019 at 10:11 AM Cullen = Jennings <fluffy@iii.= ca> wrote:


On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo <sergio.garcia.murillo@= gmail.com> wrote:

In the media framework it is stated the followin= g regarding SSRC splicing attacks:

   The splicing attack =
is an attack where a Media Distributor receiving
   multiple media sources splices one media stream into the other.  If
   the Media Distributor is able to change the SSRC without the receiver
   having any method for verifying the original source ID, then the
   Media Distributor could first deliver stream A and then later forward
   stream B under the same SSRC as stream A was previously using.  By
   not allowing the Media Distributor to change the SSRC, PERC mitigates
   this attack.

H= owever, if BUNDLE and MID are used, and there is no ssrc signaling done in = SDP, the following RTP demuxing rules from BUNDLE spec applies:

If the packet has a MID, and the packet's extended seque= nce number is greater than that of the last MID update, as discussed in [RFC7941], Section=C2=A04.2.6, update the MID associated with t= he RTP stream to match the MID carried in the RTP packet, then update the mapping tables to include an entry that maps the SSRC of that RTP stream to the "m=3D" section for that MID.

Given that MID i= s by definition HBH as it must match the negotiated SDP O/A, then the MD co= uld arbitrarily change the MID for an RTP packet and associate it with what= ever transceiver it wishes, effectively having the same effect than the SSR= C splicing attack (at least in perc double where all participants share the= same inner e2e key and there).



No, it would not have the same effect at all.=C2=A0
<= br>

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


--
Alex. Gouaillard, PhD, PhD, M= BA
--------------------------------------------------------------------= ----------------
President - CoSMo Software Consulting, Singapore=
----------------------------------------------------------------= --------------------

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

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--
sent from my mobile
--000000000000ac8ab005832b6827-- From nobody Sun Mar 3 18:26:08 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613F130EBB for ; Sun, 3 Mar 2019 18:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc4eYuCP7UoC for ; Sun, 3 Mar 2019 18:26:05 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 0AB3A130EAA for ; Sun, 3 Mar 2019 18:26:05 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id w18so5179652itj.4 for ; Sun, 03 Mar 2019 18:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aiktdnO/obOWoSQYyns423doK82NzdW4jazU1IKQcv4=; b=L7iE8B29MfAcu7z8VFIqqf85YMrUf54sdkIym9NYD/P0w7K7XzQrR2IYFFvJ46JPSm RFpV4Rx//W7Z9FZdk4qJpMmW3Awg3VxTchyBvD960nzXSF/MNKuke4lWMkFxB2nr4UIi 0e7vhuci5scfzm0u4K7kvbAGYfNEzwFkybbHO0zRkthuZU0pEhJABT5GhWl2n9fuxdGH Ykc7RaJ0wmTDpYJNJVFDCQUV4a5tEUd1s8AM/rxjpuxZG1wuYZnViFXBZTbkAWRuS8PJ F7CpljrTb/AXBhszVtcxLbZ+hffghVM5sSrxzzkS3jywDsNiHmbuCNpfOfRAnxSucf2s +Yng== 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=aiktdnO/obOWoSQYyns423doK82NzdW4jazU1IKQcv4=; b=mQ88m4pMGsRNaRcOZAd18r4P+7AYy3jOa/YpiI8Wk8MAP6j1hnsgukPVUtKivM+9a2 uXYpvvVE4YWTw8eM36Yqn+48AnIe32q4yegb1DLShX/OQQ8iJhESXHzdSyh/3wPFCje7 8tOuKqsq1j+HiPaBS53yvAb4VND79P9SDdWXFZiv+6zHzoNm4Pg2J1ptzI5vx5Kgnjah etxh2W+2j3bDz2X7oaSTUuyyUcehn+Q+E5dWcBd7RfFiOb9AaQKhpRU0lhll0ajr/VRW /giQ9on75Avs6O12Vi9aXIq00klt51SV9Nm7t0N6vgMoB6BLLv3aCFYLuaXSzI1to455 cfEQ== X-Gm-Message-State: AHQUAuYEnqh3GBeRGR/jEkWAbAjscIMvjt+DSpw3j6kruG5I751Rqc1u kgU15QUrNoWcN9VCLXq1Ihy2gosp+42bRETLNJrapQ== X-Google-Smtp-Source: APXvYqy2mvpyXcDyxLavT+NEHitV+kFO44kF0TbXV1c9DyjuNXss4D7fkQnLmW3DcSFXFA4Ez6RgDRbQlUPlF+jGKmI= X-Received: by 2002:a24:6588:: with SMTP id u130mr9362017itb.136.1551666363843; Sun, 03 Mar 2019 18:26:03 -0800 (PST) MIME-Version: 1.0 References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> In-Reply-To: From: Justin Uberti Date: Sun, 3 Mar 2019 18:25:52 -0800 Message-ID: To: Emil Ivov Cc: Cullen Jennings , Alexandre GOUAILLARD , Sergio Garcia Murillo , "perc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006d9ec505833b7ae5" Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 02:26:07 -0000 --0000000000006d9ec505833b7ae5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 2, 2019 at 11:15 PM Emil Ivov wrote: > > > On Fri 1 Mar 2019 at 15:38, Cullen Jennings wrote: > >> >> It=E2=80=99s a very reasonable request to ask for more info here but giv= en that >> huge amounts of WG meeting were devoted to this, I am certain not going = to >> try and explain the whole splicing attack. >> > > Throughout the considerable WG time devoted to this so called attack, you > have never really bothered to present anything but handwaiving about it. > This is beyond ridiculous. > > As Bernard points out, any actual attempt to think of splicing here > results in schemes that are as easy to thwart as adding a simple > comparison with the SSRC in the OHB. > I have to agree with Emil and Bernard - since the middlebox is only mutating the outer SSRC, it can't control the SRTP context used for the inner decryption (and if it did mutate the inner SSRC, this would be immediately detectable). Perhaps I'm missing something - since it sounds like this particular concern was discussed at length in previous IETF meetings, could you send along a link to a prior presentation that lays out the problem? --0000000000006d9ec505833b7ae5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 2, 2019 at 11:15 PM Emil = Ivov <emcho@jitsi.org> wrote:<= br>

<= div>
On= Fri 1 Mar 2019 at 15:38, Cullen Jennings <fluffy@iii.ca> wrote:

Throughout the consid= erable WG time devoted to this so called attack, you have never really both= ered to present anything but handwaiving about it. This is beyond ridiculou= s.

As Bernard points out= , any actual attempt to think of splicing here results in schemes that are = as easy to thwart =C2=A0as adding a simple comparison with the SSRC in the = OHB.
=C2=A0
I have to agree wi= th Emil and Bernard - since the middlebox is only mutating the outer SSRC, = it can't control the SRTP context used for the inner decryption (and if= it did mutate the inner SSRC, this would be immediately detectable).
=

Perhaps I'm missing something - since it sounds lik= e this particular concern was discussed at length in previous IETF meetings= , could you send along a link to a prior presentation that lays out the pro= blem?
--0000000000006d9ec505833b7ae5-- From nobody Mon Mar 4 00:37:08 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B08130FF5 for ; Mon, 4 Mar 2019 00:37:07 -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 oCcf-o_8O2YJ for ; Mon, 4 Mar 2019 00:37:05 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 A537D127AC2 for ; Mon, 4 Mar 2019 00:37:04 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id c55so3533094edb.0 for ; Mon, 04 Mar 2019 00:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=uFpzRFk8Pb+lOkQYpMnV7tj0YH9JdwWFNXsbcN5waL4=; b=nI/FTT+n0ffYANBw3OVvbwqza66gP5zgZSCpiFKTmA8/vDKRZbAG7EG3FTt1JWNj5W Ea/tsjpaGWMKzpdmfL19ffRIW+/nHYLuYXk6y/HRwup02LSKD6B8MbJngIzEOLq1Fb0d ZkEeua7dQVoBB2eobWApZbXpj8DykvEKsfOy8MEk+pH//nVH93yEyV6bUFtY6I5G57pf NvfrFdbPUx4JzYVMnbL5DbgdoqfW2nmvOrg8w0VASq4lusxQhfq8rcwu/DsWzWStm4jc iW0drGsXnIoY0fgj0ow9iQRo6ShaenlLVGOgtLNy9rmS3eixnLwp+Gx+GYvS9RyfLWZz ny5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=uFpzRFk8Pb+lOkQYpMnV7tj0YH9JdwWFNXsbcN5waL4=; b=FAnrRgIS++6uQrHWgE2KLPT+MjwQU+TKnTwqtv9lwuO7H8sncCGnZtQDMUMib0tSCc guK6vjjE+m9yz93V5tipCfGASTlysUlUxhEh/thjuo+sn9teOSxQ3syoPB8zHOET4A35 1IfjHdpZCv1VNGZmAMc4IlS2jMNl85AT+rcSMY/cRJ+MTkA0GIzLSaL6kafehJd3ozMg yYScRoySCiF2MRCgWDrZsBplRF4Lndk2rkKmg+Daj0bIyDaA6/07K7TE0jABo5dy4Mz9 P5U1xXV3M0I6t/fIPqIK3i2giE/g7fWe3vXry/DFPi+Ep3jgyPbAZ/h4elFIVmkoKf6j kqPw== X-Gm-Message-State: APjAAAUDuuOogt+KAIDimCoGbNVqKMQ+JKMihTN8g+ygTlgk7LXkmUgw 4QEsrtGyhUqI2ioYfsWwGLlg3/pS X-Google-Smtp-Source: APXvYqwGvGxK4sQ2l9BlqdFk4u7r07mL8VzRcgTyQwy+Expba92hnnVM/Zytpg+GthZZqfmFvdgpNg== X-Received: by 2002:a17:906:70d6:: with SMTP id g22mr11997954ejk.215.1551688622839; Mon, 04 Mar 2019 00:37:02 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id m10sm1902991edd.2.2019.03.04.00.37.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 00:37:01 -0800 (PST) To: Emil Ivov , Cullen Jennings Cc: Alexandre GOUAILLARD , "perc@ietf.org" References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> From: Sergio Garcia Murillo Message-ID: Date: Mon, 4 Mar 2019 09:42:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E300C774C1118441DB32D3C" Content-Language: en-US Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 08:37:07 -0000 This is a multi-part message in MIME format. --------------8E300C774C1118441DB32D3C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 03/03/2019 8:15, Emil Ivov wrote: > > On Fri 1 Mar 2019 at 15:38, Cullen Jennings > wrote: > > > It’s a very reasonable request to ask for more info here but given > that huge amounts of WG meeting were devoted to this, I am certain > not going to try and explain the whole splicing attack. > > > Throughout the considerable WG time devoted to this so called attack, > you have never really bothered to present anything but handwaiving > about it. This is beyond ridiculous. > > As Bernard points out, any actual attempt to think of splicing here > results in schemes that are as easy to thwart  as adding a simple > comparison with the SSRC in the OHB. For one of our clients that required per packet identity assurance,  we have solved it by including the participant id in the inner encrypted payload that is transported end to end, instead of relying in spurious ssrc to participant mappings. Best regards Sergio --------------8E300C774C1118441DB32D3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 03/03/2019 8:15, Emil Ivov wrote:

On Fri 1 Mar 2019 at 15:38, Cullen Jennings <fluffy@iii.ca> wrote:

It’s a very reasonable request to ask for more info here but given that huge amounts of WG meeting were devoted to this, I am certain not going to try and explain the whole splicing attack.

Throughout the considerable WG time devoted to this so called attack, you have never really bothered to present anything but handwaiving about it. This is beyond ridiculous.

As Bernard points out, any actual attempt to think of splicing here results in schemes that are as easy to thwart  as adding a simple comparison with the SSRC in the OHB.


For one of our clients that required per packet identity assurance,  we have solved it by including the participant id in the inner encrypted payload that is transported end to end, instead of relying in spurious ssrc to participant mappings.

Best regards

Sergio

--------------8E300C774C1118441DB32D3C-- From nobody Mon Mar 4 00:43:50 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444E013101B for ; Mon, 4 Mar 2019 00:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 bjbrTJ-Smhic for ; Mon, 4 Mar 2019 00:43:47 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 94B59130EC7 for ; Mon, 4 Mar 2019 00:43:47 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id m35so3521292ede.10 for ; Mon, 04 Mar 2019 00:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=OPrbnTfk5820xN+9/zJ0ff3XkILjev6EkOL/CmXm2J0=; b=iA6LcDNJX2Stv0ukMBqgHp8vvGE0su4P+e8fi8UPdvhpuk5y4x2iehYpxHo4sPRtvz SBFbK5qVACJmPpLkXkKEX7LOYQTwslN0FLlKqE3rk5qUK6fuUcbFD1UDrL0kEazHtJXT k5OLkgEVskSBtIOQQ/zyrN4NNqE0abcJ+F47wYwUXC0TjR+i27YnsKN1+ZC7ZwBdzzvv Aih2+etW833buEMsD6LWp3t/OdZfAqDVJ69VY2nQBKiXWgDDIFtUt6DtipfId+Nhu/JS wux88DFc2umEdl4+L8GZpZfClx1uDPQS2rAd/Em+jvaILpLCh8Nxp497pHheBvWzbCDv 8ugA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=OPrbnTfk5820xN+9/zJ0ff3XkILjev6EkOL/CmXm2J0=; b=GoqT3wkAY8ACjD7YXc80XioPK6K53KJTyDkZoUisgjGSkHhJDa9/lvbe27YfrTOGxd yWgFrN+U2YEXrQlLt29cApGhN5cVdOx8c3SOjHTKGXkz0GCuFuxRPe1SadXggdZES4PG Ige3Y9JD4+jnNMDp8Z8KzOqAECdyftsK0UAf8YLb7DoI8qM9/M7qwh0Y2ltczPnVfnKV FgJatiO25BK1lajDGcaAwam3tNQNJZ7e/ZBWjCAemoD4inTaixASY8xcW4CkzqsnoPQT die46fMIuW3QQUgYzwQ5WHEmidHvJlOFQ9c467Cac/lJKmjuDUgnSzMu5v/IKiQz7aTm w9PQ== X-Gm-Message-State: APjAAAVxpIQ0QQJhsY5WX5Ba5XiNQE77Uipi+hCjisjU1LEZDHfHKzQL M8xGaVbVkRum5AFEOVU1TY8x81kE X-Google-Smtp-Source: APXvYqw3UNa6g9BYQT8Wu0QlYH4+8kfk+u5ZDXSvFkg6gN1pIASukqnSyRbNkI81cG2jO/KaKgwosg== X-Received: by 2002:a50:f5b5:: with SMTP id u50mr14886389edm.238.1551689025909; Mon, 04 Mar 2019 00:43:45 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id q11sm1053911ejb.39.2019.03.04.00.43.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 00:43:45 -0800 (PST) To: Justin Uberti , Emil Ivov Cc: Cullen Jennings , Alexandre GOUAILLARD , "perc@ietf.org" References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> From: Sergio Garcia Murillo Message-ID: <55828a39-847f-ea95-cdbd-265390f7c533@gmail.com> Date: Mon, 4 Mar 2019 09:48:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4E2EBC146911B1FBA53AA182" Content-Language: en-US Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 08:43:49 -0000 This is a multi-part message in MIME format. --------------4E2EBC146911B1FBA53AA182 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 04/03/2019 3:25, Justin Uberti wrote: > > > On Fri 1 Mar 2019 at 15:38, Cullen Jennings > wrote: > > > It’s a very reasonable request to ask for more info here but > given that huge amounts of WG meeting were devoted to this, I > am certain not going to try and explain the whole splicing attack. > > > Throughout the considerable WG time devoted to this so called > attack, you have never really bothered to present anything but > handwaiving about it. This is beyond ridiculous. > > As Bernard points out, any actual attempt to think of splicing > here results in schemes that are as easy to thwart  as adding a > simple comparison with the SSRC in the OHB. > > I have to agree with Emil and Bernard - since the middlebox is only > mutating the outer SSRC, it can't control the SRTP context used for > the inner decryption (and if it did mutate the inner SSRC, this would > be immediately detectable). Moreover, in PERC there is no mechanism to correlate the ssrc to an specific participant or how to coordinate the information between the peers in the conference. So, in WebRTC context, that must be implemented by the js application, which we agreed was not a trusted party. Even if we defined a protocol for doing that which is implemented natively on browsers, the best we will be able to do is to add an identity attribute to the media stream tracks. But then again, the UI is implemented by the app js, which will be responsible of putting the correct participant label on top of the correct label. And even if we trust the application, there are browser extensions than can modify the html content and easily switch the content of the participant labels text. Best regards Sergio --------------4E2EBC146911B1FBA53AA182 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 04/03/2019 3:25, Justin Uberti wrote:

On Fri 1 Mar 2019 at 15:38, Cullen Jennings <fluffy@iii.ca> wrote:

It’s a very reasonable request to ask for more info here but given that huge amounts of WG meeting were devoted to this, I am certain not going to try and explain the whole splicing attack.

Throughout the considerable WG time devoted to this so called attack, you have never really bothered to present anything but handwaiving about it. This is beyond ridiculous.

As Bernard points out, any actual attempt to think of splicing here results in schemes that are as easy to thwart  as adding a simple comparison with the SSRC in the OHB.
 
I have to agree with Emil and Bernard - since the middlebox is only mutating the outer SSRC, it can't control the SRTP context used for the inner decryption (and if it did mutate the inner SSRC, this would be immediately detectable).

Moreover, in PERC there is no mechanism to correlate the ssrc to an specific participant or how to coordinate the information between the peers in the conference. So, in WebRTC context, that must be implemented by the js application, which we agreed was not a trusted party.

Even if we defined a protocol for doing that which is implemented natively on browsers, the best we will be able to do is to add an identity attribute to the media stream tracks. But then again, the UI is implemented by the app js, which will be responsible of putting the correct participant label on top of the correct label. And even if we trust the application, there are browser extensions than can modify the html content and easily switch the content of the participant labels text.


Best regards

Sergio


--------------4E2EBC146911B1FBA53AA182-- From nobody Mon Mar 4 04:46:24 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BA512D4E6 for ; Mon, 4 Mar 2019 04:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=MNgB8tMm; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VeK+yHkg 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 Hm3JuTpmDJKO for ; Mon, 4 Mar 2019 04:46:13 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 0073113101B for ; Mon, 4 Mar 2019 04:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551703570; x=1554295570; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9+rl6zAem0ZL7DSTnmnIz2Ne4Dfh/Owe3AoxdcCKExk=; b=MNgB8tMmI+DEPUgPbHioGjDcgEzABll2Hi3o6em3TDPPeE63LcyPZxKQ6omK3SQR gTY+1cz4QhztZzz0aSlPRBBq6BEvMhETUPvdv7u8jMIiK/PmtkRxGN+ByWm5BJk0 grt9fV2JJW9quWFNYKROAf49vgfaj0Y8w/yEfZkh9gk=; X-AuditID: c1b4fb25-209009e000005ff7-b8-5c7d1e110708 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.72.24567.11E1D7C5; Mon, 4 Mar 2019 13:46:10 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESBMB504.ericsson.se (153.88.183.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 4 Mar 2019 13:46:09 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 4 Mar 2019 13:46:09 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 4 Mar 2019 13:46:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9+rl6zAem0ZL7DSTnmnIz2Ne4Dfh/Owe3AoxdcCKExk=; b=VeK+yHkgPi/qhIv11Dj/4zgzyRF9+X/to5fBS1BYq2BxCH2MH3qJd2x33Dt1K43yQBlpINkOFATpUc4HMnvLauGb1ATnL/U3rUBLUM5cyfSPEFXQ+PanBu+pgrW9652SSwFVNv17a/453x4ndqQia5lTXca8MP1C/4DlrgS9vxE= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2699.eurprd07.prod.outlook.com (10.168.187.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.9; Mon, 4 Mar 2019 12:46:07 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::4cb:751a:9e20:ca78]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::4cb:751a:9e20:ca78%3]) with mapi id 15.20.1686.016; Mon, 4 Mar 2019 12:46:07 +0000 From: Magnus Westerlund To: Bernard Aboba , Sergio Garcia Murillo , Emil Ivov CC: Alexandre GOUAILLARD , "perc@ietf.org" , Cullen Jennings , IETF discussion list Thread-Topic: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) Thread-Index: AQHUyg8CPDk5QGuykE63buKWmNoGiQ== Date: Mon, 4 Mar 2019 12:46:07 +0000 Message-ID: References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca> <23404598-2ded-8584-3bea-f8160a59160c@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cd0ca768-5076-404a-cd2f-08d6a09f5f0f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2699; x-ms-traffictypediagnostic: HE1PR0701MB2699: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; HE1PR0701MB2699; 23:zoA/JBGz3AX29vzqOyW1M9siokrm3k7N4ojLXn/?= =?us-ascii?Q?OfsPIbOys2cXghT21W34h6ddUr+/Ljxpjt2ejx4zooCxnGY8raFybuCHgtDe?= =?us-ascii?Q?3k85UjuDsjZ65P+4BUgvz3aL5ljlsqOREv8jiju2DBher3lzSlO3sBOrmswy?= =?us-ascii?Q?JRB79GCy3XqvDjHkGLZcYn7wJ8owtm7XjUUHaLJQ8e9GaVj6IsJP4LyuUZxK?= =?us-ascii?Q?zP/tsgS6EVCW4AVQUBrDPn7ZdJ5UfcBxryu2Qb3Sjqs1UDtajmM3BAdavuHf?= =?us-ascii?Q?yqAJe132GtfxVG0/C6zIpVHVR999NWmr2KNQ34rCiU+MD9TXpF+x+1ttnVaC?= =?us-ascii?Q?6ukJU46zAfyoxfa/smd+PGy1FC3D9cVNgmJn1aUA56o8KM/BdTP0HAjcuTOu?= =?us-ascii?Q?CJQe1zVwfhnCKJ8LJL4SrfU51cw5/EI/rLX3u9B0Vk8vyJJu8x9yYRhtfU8F?= =?us-ascii?Q?ojJhbHyiqtujGUUCAzCD5w4AVwjs5XC5u3DA4cJvBwxef/21nPGAayGfPhUP?= =?us-ascii?Q?uatszozO6v85OFR9Gu5uB5fVScCc4dFx0NdRXSWyQPHkt/0FtqRC3yBhAFGh?= =?us-ascii?Q?RrP8dj6tGA4QaRUAeiVY3XAFw1A74lUF/Fo2Vut586oLn8I7ioQ0SOrA18+Z?= =?us-ascii?Q?aNQax4oP1TxCY1SKhy31/lMdzh1UBBcaPntwCPJ9ZrBLSIx5XjXIe/zjf8xz?= =?us-ascii?Q?AP9SnovpXnwaW1axCKsMyvAW22sY4ciZnrEGHYEbMfGhJ4YQRftOjzvk5qg4?= =?us-ascii?Q?CHkC3T+JDsk6C5hL4eiRY4LAf2UFAk+ePiYL14ROhg3jpE8YcXNFLZzAJvZk?= =?us-ascii?Q?STyiSibyMwVQjhScyFUHPW6pbVJYZZc+oLhS5DYkqPTD3o3w1DdhEQ34cyGo?= =?us-ascii?Q?Bd7yepHq2K57Pp2S7rtFaeHDf5he+D0LSB1CoAJJUjngA8WYY6saynl/wGGc?= =?us-ascii?Q?/14KLCWfH7QQz5O4mqSG0hcZk42TNEq6Ri2kheNoJgfUklypWKJB5tNQsX/v?= =?us-ascii?Q?DUUVl9qKBjcSDdGAHvGSeg/llnL9p0yowljMlmRXDeAo6d8k5oqur6SPQieA?= =?us-ascii?Q?W6/zhv5KztGhUazmgQ542GM/sOl3ULgietLKxnYp9j4zhiR11BL4zjROPpXj?= =?us-ascii?Q?GuqUacsn+ociL3j9A4qpudwrx/zJFRb+6NERZMKRvn26ZlsvbrUdSCEtPcEF?= =?us-ascii?Q?VFQieq1iKRB5rVJx5P+WUTaAqqsZ3QmsJboJpQJ300nIDIVZKAES0AjzUbUs?= =?us-ascii?Q?wmzf+06iQ/yv0SthPBV+JO5hiMPo321LNLDhGvTtmXKBeWLDjXbvzSS93nuk?= =?us-ascii?Q?CbC+vT3Iex+UiMP0i/TVRJ0Q8EAOwEKGsAmswgStuMbpDZe+v7P3baiMHb+h?= =?us-ascii?Q?8qwLaT//rUVClLDlIlBoGR4D4KWQd89rgDBXGsreRxaQeIiZsMYEKczcN6GK?= =?us-ascii?Q?cYXKVvOP9ZA=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(376002)(366004)(39860400002)(189003)(199004)(74316002)(5660300002)(478600001)(25786009)(6306002)(236005)(9686003)(54896002)(186003)(97736004)(14454004)(6436002)(486006)(5070765005)(52536013)(7736002)(68736007)(2906002)(105586002)(93886005)(446003)(8936002)(6246003)(55016002)(53936002)(44832011)(476003)(106356001)(966005)(66066001)(606006)(81166006)(229853002)(14444005)(86362001)(316002)(256004)(71190400001)(71200400001)(8676002)(66574012)(7696005)(6116002)(102836004)(110136005)(26005)(6346003)(99286004)(3846002)(81156014)(33656002)(53546011)(54906003)(4326008)(76176011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2699; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LaXPqDi62uEmFyS0QcEPB+6TYEjODgviZpnNL2JoQqVaoGMR0EWfcAWDJsBpgZLN74cuRMjYydFIrywGmXbTNzY5uZ1YWR9OoT3FBR2/5slgsdswnr1zttvYnPDvNHYbltfna0g2hjNvO10rFn1cTwE4kvhbetMHi1CUGu5qYUiyoEPGiLbUNYLp2SeMP1TZ4NWeloTTf6Y1sWMOIm0hZpwopTvk3cHulxHHnGzX64a/zJ+ZyFyIaEXig8SCmqh3g8nAslh8zhEw7JoptOUaj+FqxS73gdOtonB+9cxCSOPZbtl/9ffxS7qzWZalJXKy4BuQP10mm6k0gVDdsmKaJdRt/xR+xvwmQcYYheD/vS8Hxa6zBwp7+JnA2Wp/7pjwXqRk0jX+WAJ53QspDQqmYH1YeM+jSCWGeo1Om9qHlDA= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25220CDDC31C312C0266486895710HE1PR0701MB2522_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cd0ca768-5076-404a-cd2f-08d6a09f5f0f X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2019 12:46:07.3238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2699 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Se0hTcRTmd+/ddh3OrkvxYCoyW/Tw0ZsZESUE84+ihELM0pkXFZ/cqWUW qNFLsYZY4qtNHWpTU8vy0UNTC0tr5VDzMSN0kmn4CPORafPeCf73ne/7zu985/AjcbGe50hG xMTTTIwiSsIXErn+9QkeYpdrgbvvfkayobQCvqzm9Souq2xUEbLp6gUkG6tVE7KKohwkM63U 40cF8sY8o0Cu1S5icoN+BslXJ0+fIgKEh0PpqIhEmvE6EiwMrx3s5cXpC9DlX3PeKWg1FaUj KxKo/TA22CxIR0JSTLUjMDY95HPFHAJVi4FYc7HFI42UE0owqFC9Yl0EpcIh43e3pSUHg6mb SxhXjCDomP+Br/XzKRn0L6SyLjvqOoLFqnesC6cKEJQWVbNZNlNB8OmDicV2VDBk6NrNHaQZ e8L4EhuEoLZC4U8jbw2LzJbM7D6cm2bEQPVnhp2GKGf4Nj/MNuCUAwyMqjFuVwq0L/U4h+1h fGSFt/Y+UK6QaQjgaGfoVmdYTnMCTH0ZbGigBhFkT/TwOMEdsjpMFuwIzU8fIs6UtQk6U3QC TogF9fdnlmFOsPhl2PKqhg/j+Qx3VhrKqm4gFfLI25CVw7FwX5OJ8thFbeF97ijB8e6geTHL 5/Au8+0m8HXc1TKCbeQ1SKBD9kpaGRIdtnefJ81EXFQqY2M8Y+j4J8j8zd7U/ZU2IMPksVZE kUhiLXJdvhoo5ikSlUnRrQhIXGInwqbNlChUkXSFZmKDmIQoWtmKtpCExEG0LLYNFFNhing6 kqbjaGZdxUgrxxTElN9OEJgOuZWH4VOFalNxg87vuK+fzi2kLCG8rdLV33Dha7anl35I0O3b OlHyNq3HW2qTLH1gdb5IGzky1vX4Tq8P7qEbqDt5LuCSceH5ZLOLzbxT5mT+7PZ7ejT38cA/ 7GDWmR1auXVTcT8KbJsW3vIhE6u3JUvOdnYt1XSUSghluGLPTpxRKv4DrWwdlGIDAAA= Archived-At: Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 12:46:18 -0000 --_000_HE1PR0701MB25220CDDC31C312C0266486895710HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Regarding the splicing attack there are at least one aspect I don't think h= ave come up yet in this discussion and which relates to the SSRC and the MD= . Bernard is correct that what is important is that the source SSRC that is p= ointing to the e2e key context are unique and not collidable to prevent ena= bling a splicing attack. If the MD translate them that is not an issue as l= ong as the source SSRC is determinable and verifiable through the e2e integ= rity mechanisms. What has been less discussed is that non-malicious MD can actually prevent = attacks by tracking which original SSRC is coming from where. That way an a= ttacker trying to introduce a splice or an replay of an source SSRC can be = blocked before it gets circulated to other MDs or endpoints. Thus help miti= gating this attack. For me it at least this is one of the reasons why it is good to keep the or= iginal SSRC easily accessible. This combined with the set of changes anyway= needed to support PERC it looked like keeping the SSRC static was the simp= lest solution from my perspective. The discussion of the Splicing attack original was in the context of the fi= eld manipulations that could be allowed. I think the basics is in this pres= entation: https://www.ietf.org/proceedings/94/slides/slides-94-perc-2.pdf There are also some requirements John Mattsson presented from Ericsson's pe= rspective on these issues at the same meeting (IETF 94): Slide 6 of https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf This is only to provide my perspective from the time I was involved in the = WG. I did disengage fairly soon after this meeting so I lack the full persp= ective on the WG operations and what is documented in the draft now. Cheers Magnus On 2019-03-01 18:20, Bernard Aboba wrote: Sergio said: "So the main issue here is that "endpoint can separate two different origi= nating sources and to map the SSRC to a human readable name (or alias)". By= modifying the MIDs the MD is able to do exactly that, and have the same ef= fect than splicing attack without having to rewrite the ssrcs, that is, the= endpoint will not be able to differentiate rtp packets coming from two dif= ferent sources as the MID is used for routing and not the ssrc." [BA] Let me attempt to unpack this. There are two issues here, which relate= to: 1. Effects of changing the RTP header SSRC 2. Effects of manipulating the original" SSRC associated with the e2e keys. Taking each in turn: 1. Changing the RTP header SSRC affects the routing of audio/video seen by = the user but does not affect the integrity of media, which is protected by = the e2e keys.. By changing the RTP header SSRC it is possible to "splice" t= he media or cause the a/v rendered in audio/video tags to switch between us= ers (e.g. dominant speaker protection). As we have discussed this is very = common and causes few problems today, so it really can't be thought of as a= n "attack". 2. I believe this is the aspect Cullen is referring to, which provides an a= ttacker with the ability to fool an endpoint into accepting as authentic a = manipulated payload. This can be used to create a "deep fakes" so it is a = genuine attack. Addressing this doesn't require outlawing the modification of the RTP heade= r SSRC. If the original SSRC is included in the payload in cleartext and i= ntegrity protected along with the rest of the payload, then the payload cry= pto-context is unaffected by modifications to the SSRC included in the RTP = header. The endpoint determines the appropriate keys for integrity protect= ion and payload decryption from the payload SSRC, not the RTP header SSRC. Of course, for this to work, conference participants cannot be allowed to m= asquerade as each other. That is, if multiple conference endpoints possess= the e2e keys used to encrypt and integrity protect payload data, then they= can source "deep fake" media that appears to originate from another party.= As you have pointed out, this is a fundamental problem that the PERC fram= ework does not address. However, it can be addressed if trust is rooted in hardware (e.g. the TPM) = and that e2e keys are not accessible to the endpoints (either Javascript or= the browser). AFAICT, PERC key management doesn't meet this requirement, = but some content protection schemes claim to do so.. On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo > wrote: On 01/03/2019 16:38, Cullen Jennings wrote: However to get to the heart of why the MID is different than the SSRC in th= e splicing attack, the key thing with the splicing attack is the attacker = gets the receiver to use a valid, but not really the correct, SRTP crypto c= ontext. As outlined in https://tools.ietf.org/html/rfc3711#section-3.2 , th= e crypto context looked up from dest IP:port and SSRC. So changing the SSRC= allows the attacker in the splicing attack to switch to a crypto context o= f the attackers choosing (and one the attacker has keys for). Changing the = other things such as the MID does not allow this. You are describing how ssrc splicing works, not what are its effects, or wh= y it is an issue. I think I have found the origin of the ssrc rewriting iss= ue and the splicing attack for perc in here: https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerati= ons-00.txt 3.9. SSRC The SSRC identifies the source of the RTP packet. As each SSRC has its own RTP sequence number space as well as timestamp sequence, collisions shall be avoided. For the PERC usage it is also important that a receiving endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias). The important security related issue is that unless the originating RTP stream can be identified the MDD could create one outgoing stream that selects packets from either of them. This may be challenging due to replay protection, but not impossible depending on how the sequence number and timestamps align. To avoid having multiple identifers for the RTP packet stream, the design team has proposed that the SSRC shall be unique and the original value preserved to the receiving endpoint. Even if the originating endpoints have unique SSRCs, it is not clear if the same requirement will be extended to the MDD, and then especially media switching RTP mixers that have their own SSRCs. Thus translation of SSRC as a method for dealing with SSRC collisions may need to be dealt with. The original SSRC needs to be authenticated end-to-end to prevent the splicing attack described above. So the main issue here is that "endpoint can separate two different origin= ating sources and to map the SSRC to a human readable name (or alias)". By = modifying the MIDs the MD is able to do exactly that, and have the same eff= ect than splicing attack without having to rewrite the ssrcs, that is, the = endpoint will not be able to differentiate rtp packets coming from two diff= erent sources as the MID is used for routing and not the ssrc. Best regards Sergio _______________________________________________ Perc mailing list Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB25220CDDC31C312C0266486895710HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

Regarding the splicing attack there are at l= east one aspect I don't think have come up yet in this discussion and which= relates to the SSRC and the MD.

Bernard is correct that what is important is= that the source SSRC that is pointing to the e2e key context are unique an= d not collidable to prevent enabling a splicing attack. If the MD translate= them that is not an issue as long as the source SSRC is determinable and verifiable through the e2e integrit= y mechanisms.

What has been less discussed is that non-mal= icious MD can actually prevent attacks by tracking which original SSRC is c= oming from where. That way an attacker trying to introduce a splice or an r= eplay of an source SSRC can be blocked before it gets circulated to other MDs or endpoints. Thus help mitigating = this attack.

For me it at least this is one of the reason= s why it is good to keep the original SSRC easily accessible. This combined= with the set of changes anyway needed to support PERC it looked like keepi= ng the SSRC static was the simplest solution from my perspective. 

The discussion of the Splicing attack origin= al was in the context of the field manipulations that could be allowed. I t= hink the basics is in this presentation:

There are also some requirements John Mattss= on presented from Ericsson's perspective on these issues at the same meetin= g (IETF 94): Slide 6 of

This is only to provide my perspective from = the time I was involved in the WG. I did disengage fairly soon after this m= eeting so I lack the full perspective on the WG operations and what is docu= mented in the draft now.

Cheers

Magnus


On 2019-03-01 18:20, Bernard Aboba wrote:
Sergio said: 

"So the main issue here is that  "endpoint can separate= two different originating sources and to map the SSRC to a human readable = name (or alias)". By modifying the MIDs the MD is able to do exactly t= hat, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to dif= ferentiate rtp packets coming from two different sources as the MID is used= for routing and not the ssrc."

[BA] Let me attempt to unpack this. There are two issues here, which r= elate to:

1. Effects of changing the RTP header SSRC

2. Effects of manipulating the original" SSRC associated with the= e2e keys.  

Taking each in turn: 

1. Changing the RTP header SSRC affects the routing of audio/video see= n by the user but does not affect the integrity of media, which is protecte= d by the e2e keys.. By changing the RTP header SSRC it is possible to "= ;splice" the media or cause the a/v rendered in audio/video tags to switch between users (e.g. dominant speaker protect= ion).  As we have discussed this is very common and causes few problem= s today, so it really can't be thought of as an "attack". 

2. I believe this is the aspect Cullen is referring to, which provides= an attacker with the ability to fool an endpoint into accepting as authent= ic a manipulated payload.  This can be used to create a "deep fak= es" so it is a genuine attack. 

Addressing this doesn't require outlawing the modification of the RTP = header SSRC.  If the original SSRC is included in the payload in clear= text and integrity protected along with the rest of the payload, then the p= ayload crypto-context is unaffected by modifications to the SSRC included in the RTP header.  The endpoint d= etermines the appropriate keys for integrity protection and payload decrypt= ion from the payload SSRC, not the RTP header SSRC. 

Of course, for this to work, conference participants cannot be allowed= to masquerade as each other.  That is, if multiple conference endpoin= ts possess the e2e keys used to encrypt and integrity protect payload data,= then they can source "deep fake" media that appears to originate from another party.  As you have pointed ou= t, this is a fundamental problem that the PERC framework does not address.&= nbsp;

However, it can be addressed if trust is rooted in hardware (e.g. the = TPM) and that e2e keys are not accessible to the endpoints (either Javascri= pt or the browser).  AFAICT, PERC key management doesn't meet this req= uirement, but some content protection schemes claim to do so.. 

On Fri, Mar 1, 2019 at 8:18 AM Sergio= Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 01/03/2019 16:= 38, Cullen Jennings wrote:
However to get to the heart of why the MID is dif= ferent than the SSRC in the splicing attack,  the key thing with the s= plicing attack is the attacker gets the receiver to use a valid, but not re= ally the correct, SRTP crypto context. As outlined in https://tools.ietf.org/htm= l/rfc3711#section-3.2 , the crypto context looked up from dest IP:= port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choo= sing (and one the attacker has keys for). Changing the other things such as= the MID does not allow this. 


You are describing how ssrc splicing works, not what are its effects, or= why it is an issue. I think I have found the origin of the ssrc rewriting = issue and the splicing attack for perc in here:

https://www.ietf.org/arch= ive/id/draft-westerlund-perc-rtp-field-considerations-00.txt
3.9.  =
SSRC=0A=
=0A=
   The SSRC identifies the source of the RTP packet.  As each SSRC has=0A=
   its own RTP sequence number space as well as timestamp sequence,=0A=
   collisions shall be avoided.  For the PERC usage it is also important=0A=
   that a receiving endpoint can separate two different originating=0A=
   sources and to map the SSRC to a human readable name (or alias).  The=0A=
   important security related issue is that unless the originating RTP=0A=
   stream can be identified the MDD could create one outgoing stream=0A=
   that selects packets from either of them.  This may be challenging=0A=
   due to replay protection, but not impossible depending on how the=0A=
   sequence number and timestamps align.  To avoid having multiple=0A=
   identifers for the RTP packet stream, the design team has proposed=0A=
   that the SSRC shall be unique and the original value preserved to the=0A=
   receiving endpoint.=0A=
=0A=
   Even if the originating endpoints have unique SSRCs, it is not clear=0A=
   if the same requirement will be extended to the MDD, and then=0A=
   especially media switching RTP mixers that have their own SSRCs.=0A=
   Thus translation of SSRC as a method for dealing with SSRC collisions=0A=
   may need to be dealt with.=0A=
=0A=
   The original SSRC needs to be authenticated end-to-end to prevent the=0A=
   splicing attack described above.

So the main issue here is that  "endpoint can separate two dif= ferent originating sources and to map the SSRC to a human readable name (or= alias)". By modifying the MIDs the MD is able to do exactly that, and= have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to dif= ferentiate rtp packets coming from two different sources as the MID is used= for routing and not the ssrc.


Best regards

Sergio

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


-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB25220CDDC31C312C0266486895710HE1PR0701MB2522_--


From nobody Mon Mar  4 04:59:13 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BDC130F32; Mon,  4 Mar 2019 04:59:04 -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 mnkS4mGP1jRt; Mon,  4 Mar 2019 04:59:01 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 DAE0F130FFB; Mon,  4 Mar 2019 04:59:00 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id x7so4500713wmj.0; Mon, 04 Mar 2019 04:59:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=E+KFYOnNLl6tWYUrfgyUEOKYRmwBNp2+pM7WkvcOAkU=; b=DSBvGWBPC+sb4Us3oxL5GUlcwSnPbFoZR7E+e4aGJlD6Csy5p6nu2zK7ldPA4JTr7C rNhVoN/DKzwS9hvY4ujfp4YJEwvQDgrb2/88Dj9UhwivhOmOLVdwbVkYFLFfcmMEc0zq drOMZEs+O2w1I4ZoD7YpySKI3QK3oTAS5O2Tk9uesaXTCLXxcfYPn3eKQnzFz3hQFjGn vSZmxuQcHVWgvnIb64WLrcUdgTTQzqDFFLo0IVjXDs90TeP838bgtTa8MOVaal9enTtJ wz0rTf2rWlR31uP2TOofgd0GyVRAjwNeGQ4CcGusE5hi3k8isGsLeQjXibLtWqkOBdil aSOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=E+KFYOnNLl6tWYUrfgyUEOKYRmwBNp2+pM7WkvcOAkU=; b=jkBWuv6lgCBn58pafkhNEZDvIUw2jkY2RJVkgmmALU3nWKpyJBFJmKkpU9dGXupDuR UnAuaSUZUyseBBftA3CB2QzZKtJPzW02ElNvhf7stglFRo9DiAkbEEK84hkPcvZxAnGi rT38N9J7i4CXC+VgE4hxABMPbJCh1+H0pIsuIXDcj4D3f73IB0GpLQBTDo4QzqRR9gUt XzZrNO2qvy12aP/M1UWCHJ17qF7gwrq9Ik3HJlikMK6zGlZ/hc9mTKYrEX/rKNtDQZOv gI1uH+fBZn/iAW1Tn9RfzjsacekBTCIQ9ZJ1197rp793ggKjJ73AfAnmKVEZ0hfHjvKu 3SIg==
X-Gm-Message-State: AHQUAuaKfk78e4h8RAyVO3UEwalWR52h9eSTCj66AKuNniSnYMjO4Bjb GfMDvLVlPTAf9vht8zApmBG478sP
X-Google-Smtp-Source: APXvYqwaV9Vy29sF1IDLsD+VFwkZ7lcyntt0PATBYJsBErFiXBXCLBayBBVockN/sb9i8XrvxO2hNg==
X-Received: by 2002:a7b:cf3a:: with SMTP id m26mr11319430wmg.144.1551704339049;  Mon, 04 Mar 2019 04:58:59 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id y20sm5614036wmi.34.2019.03.04.04.58.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 04:58:58 -0800 (PST)
To: Magnus Westerlund , Bernard Aboba , Emil Ivov 
Cc: Alexandre GOUAILLARD , "perc@ietf.org" , Cullen Jennings , IETF discussion list 
References: <91eeccf6-d09e-2542-3d63-18f09ee073ed@gmail.com> <36AD90F5-8441-4B61-A01A-76A15D55442E@iii.ca>   <23404598-2ded-8584-3bea-f8160a59160c@gmail.com>  
From: Sergio Garcia Murillo 
Message-ID: <693da134-cbb6-b1ec-ce0f-63a9d1936a43@gmail.com>
Date: Mon, 4 Mar 2019 14:03:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------416A070AD0CE59806999B948"
Content-Language: en-US
Archived-At: 
Subject: Re: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Mar 2019 12:59:05 -0000

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

Hi Magnus,

Thanks for the insights which matches what I understood from the 
splicing attack.

While I acknowledge that being able to track the origin of the rtp 
packet media is a good (and even a must have) functionality:

  * There is no mechanism in PERC to coordinate/map ssrc values to
    origins/participants between the endpoints.
  * In WebRTC, for that information to be of any value, the js app must
    be trusted to do something mean full with it.

FWIW, PERC-Lite carried the original ssrc in the inner payload, and as 
said before in a previous email, we have improved it for a customer to 
carry the participant id in the encrypted payload instead of the ssrc 
value (much more useful).

Best regards
Sergio

On 04/03/2019 13:46, Magnus Westerlund wrote:
> Hi,
>
> Regarding the splicing attack there are at least one aspect I don't 
> think have come up yet in this discussion and which relates to the 
> SSRC and the MD.
>
> Bernard is correct that what is important is that the source SSRC that 
> is pointing to the e2e key context are unique and not collidable to 
> prevent enabling a splicing attack. If the MD translate them that is 
> not an issue as long as the source SSRC is determinable and verifiable 
> through the e2e integrity mechanisms.
>
> What has been less discussed is that non-malicious MD can actually 
> prevent attacks by tracking which original SSRC is coming from where. 
> That way an attacker trying to introduce a splice or an replay of an 
> source SSRC can be blocked before it gets circulated to other MDs or 
> endpoints. Thus help mitigating this attack.
>
> For me it at least this is one of the reasons why it is good to keep 
> the original SSRC easily accessible. This combined with the set of 
> changes anyway needed to support PERC it looked like keeping the SSRC 
> static was the simplest solution from my perspective.
>
> The discussion of the Splicing attack original was in the context of 
> the field manipulations that could be allowed. I think the basics is 
> in this presentation:
> https://www.ietf.org/proceedings/94/slides/slides-94-perc-2.pdf
>
> There are also some requirements John Mattsson presented from 
> Ericsson's perspective on these issues at the same meeting (IETF 94): 
> Slide 6 of
> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf
>
> This is only to provide my perspective from the time I was involved in 
> the WG. I did disengage fairly soon after this meeting so I lack the 
> full perspective on the WG operations and what is documented in the 
> draft now.
>
> Cheers
>
> Magnus
>
>
> On 2019-03-01 18:20, Bernard Aboba wrote:
>> Sergio said:
>>
>> "So the main issue here is that "endpoint can separate two different 
>> originating sources and to map the SSRC to a human readable name (or 
>> alias)". By modifying the MIDs the MD is able to do exactly that, and 
>> have the same effect than splicing attack without having to rewrite 
>> the ssrcs, that is, the endpoint will not be able to differentiate 
>> rtp packets coming from two different sources as the MID is used for 
>> routing and not the ssrc."
>>
>> [BA] Let me attempt to unpack this. There are two issues here, which 
>> relate to:
>>
>> 1. Effects of changing the RTP header SSRC
>>
>> 2. Effects of manipulating the original" SSRC associated with the e2e 
>> keys.
>>
>> Taking each in turn:
>>
>> 1. Changing the RTP header SSRC affects the routing of audio/video 
>> seen by the user but does not affect the integrity of media, which is 
>> protected by the e2e keys.. By changing the RTP header SSRC it is 
>> possible to "splice" the media or cause the a/v rendered in 
>> audio/video tags to switch between users (e.g. dominant speaker 
>> protection). As we have discussed this is very common and causes few 
>> problems today, so it really can't be thought of as an "attack".
>>
>> 2. I believe this is the aspect Cullen is referring to, which 
>> provides an attacker with the ability to fool an endpoint into 
>> accepting as authentic a manipulated payload. This can be used to 
>> create a "deep fakes" so it is a genuine attack.
>>
>> Addressing this doesn't require outlawing the modification of the RTP 
>> header SSRC. If the original SSRC is included in the payload in 
>> cleartext and integrity protected along with the rest of the payload, 
>> then the payload crypto-context is unaffected by modifications to the 
>> SSRC included in the RTP header. The endpoint determines the 
>> appropriate keys for integrity protection and payload decryption from 
>> the payload SSRC, not the RTP header SSRC.
>>
>> Of course, for this to work, conference participants cannot be 
>> allowed to masquerade as each other. That is, if multiple conference 
>> endpoints possess the e2e keys used to encrypt and integrity protect 
>> payload data, then they can source "deep fake" media that appears to 
>> originate from another party. As you have pointed out, this is a 
>> fundamental problem that the PERC framework does not address.
>>
>> However, it can be addressed if trust is rooted in hardware (e.g. the 
>> TPM) and that e2e keys are not accessible to the endpoints (either 
>> Javascript or the browser). AFAICT, PERC key management doesn't meet 
>> this requirement, but some content protection schemes claim to do so..
>>
>> On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo 
>> > > wrote:
>>
>>     On 01/03/2019 16:38, Cullen Jennings wrote:
>>>     However to get to the heart of why the MID is different than the
>>>     SSRC in the splicing attack, the key thing with the splicing
>>>     attack is the attacker gets the receiver to use a valid, but not
>>>     really the correct, SRTP crypto context. As outlined in
>>>     https://tools.ietf.org/html/rfc3711#section-3.2, the crypto
>>>     context looked up from dest IP:port and SSRC. So changing the
>>>     SSRC allows the attacker in the splicing attack to switch to a
>>>     crypto context of the attackers choosing (and one the attacker
>>>     has keys for). Changing the other things such as the MID does
>>>     not allow this. 
>>
>>
>>     You are describing how ssrc splicing works, not what are its
>>     effects, or why it is an issue. I think I have found the origin
>>     of the ssrc rewriting issue and the splicing attack for perc in here:
>>
>>     https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt
>>
>>
>>     3.9.  SSRC
>>
>>         The SSRC identifies the source of the RTP packet.  As each SSRC has
>>         its own RTP sequence number space as well as timestamp sequence,
>>         collisions shall be avoided.  For the PERC usage it is also important
>>         that a receiving endpoint can separate two different originating
>>         sources and to map the SSRC to a human readable name (or alias).  The
>>         important security related issue is that unless the originating RTP
>>         stream can be identified the MDD could create one outgoing stream
>>         that selects packets from either of them.  This may be challenging
>>         due to replay protection, but not impossible depending on how the
>>         sequence number and timestamps align.  To avoid having multiple
>>         identifers for the RTP packet stream, the design team has proposed
>>         that the SSRC shall be unique and the original value preserved to the
>>         receiving endpoint.
>>
>>         Even if the originating endpoints have unique SSRCs, it is not clear
>>         if the same requirement will be extended to the MDD, and then
>>         especially media switching RTP mixers that have their own SSRCs.
>>         Thus translation of SSRC as a method for dealing with SSRC collisions
>>         may need to be dealt with.
>>
>>         The original SSRC needs to be authenticated end-to-end to prevent the
>>         splicing attack described above.
>>
>>     So the main issue here is that "endpoint can separate two
>>     different originating sources and to map the SSRC to a human
>>     readable name (or alias)". By modifying the MIDs the MD is able
>>     to do exactly that, and have the same effect than splicing attack
>>     without having to rewrite the ssrcs, that is, the endpoint will
>>     not be able to differentiate rtp packets coming from two
>>     different sources as the MID is used for routing and not the ssrc.
>>
>>
>>     Best regards
>>
>>     Sergio
>>
>>     _______________________________________________
>>     Perc mailing list
>>     Perc@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/perc
>>
>
> -- 
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------



--------------416A070AD0CE59806999B948
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Magnus,

Thanks for the insights which matches what I understood from the splicing attack.

While I acknowledge that being able to track the origin of the rtp packet media is a good (and even a must have) functionality:
  • There is no mechanism in PERC to coordinate/map ssrc values to origins/participants between the endpoints.
  • In WebRTC, for that information to be of any value, the js app must be trusted to do something mean full with it.
FWIW, PERC-Lite carried the original ssrc in the inner payload, and as said before in a previous email, we have improved it for a customer to carry the participant id in the encrypted payload instead of the ssrc value (much more useful).

Best regards
Sergio

On 04/03/2019 13:46, Magnus Westerlund wrote:
Hi,

Regarding the splicing attack there are at least one aspect I don't think have come up yet in this discussion and which relates to the SSRC and the MD.

Bernard is correct that what is important is that the source SSRC that is pointing to the e2e key context are unique and not collidable to prevent enabling a splicing attack. If the MD translate them that is not an issue as long as the source SSRC is determinable and verifiable through the e2e integrity mechanisms.

What has been less discussed is that non-malicious MD can actually prevent attacks by tracking which original SSRC is coming from where. That way an attacker trying to introduce a splice or an replay of an source SSRC can be blocked before it gets circulated to other MDs or endpoints. Thus help mitigating this attack.

For me it at least this is one of the reasons why it is good to keep the original SSRC easily accessible. This combined with the set of changes anyway needed to support PERC it looked like keeping the SSRC static was the simplest solution from my perspective.

The discussion of the Splicing attack original was in the context of the field manipulations that could be allowed. I think the basics is in this presentation:

There are also some requirements John Mattsson presented from Ericsson's perspective on these issues at the same meeting (IETF 94): Slide 6 of

This is only to provide my perspective from the time I was involved in the WG. I did disengage fairly soon after this meeting so I lack the full perspective on the WG operations and what is documented in the draft now.

Cheers

Magnus


On 2019-03-01 18:20, Bernard Aboba wrote:
Sergio said:

"So the main issue here is that "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc."

[BA] Let me attempt to unpack this. There are two issues here, which relate to:

1. Effects of changing the RTP header SSRC

2. Effects of manipulating the original" SSRC associated with the e2e keys.

Taking each in turn:

1. Changing the RTP header SSRC affects the routing of audio/video seen by the user but does not affect the integrity of media, which is protected by the e2e keys.. By changing the RTP header SSRC it is possible to "splice" the media or cause the a/v rendered in audio/video tags to switch between users (e.g. dominant speaker protection). As we have discussed this is very common and causes few problems today, so it really can't be thought of as an "attack".

2. I believe this is the aspect Cullen is referring to, which provides an attacker with the ability to fool an endpoint into accepting as authentic a manipulated payload. This can be used to create a "deep fakes" so it is a genuine attack.

Addressing this doesn't require outlawing the modification of the RTP header SSRC. If the original SSRC is included in the payload in cleartext and integrity protected along with the rest of the payload, then the payload crypto-context is unaffected by modifications to the SSRC included in the RTP header. The endpoint determines the appropriate keys for integrity protection and payload decryption from the payload SSRC, not the RTP header SSRC.

Of course, for this to work, conference participants cannot be allowed to masquerade as each other. That is, if multiple conference endpoints possess the e2e keys used to encrypt and integrity protect payload data, then they can source "deep fake" media that appears to originate from another party. As you have pointed out, this is a fundamental problem that the PERC framework does not address.

However, it can be addressed if trust is rooted in hardware (e.g. the TPM) and that e2e keys are not accessible to the endpoints (either Javascript or the browser). AFAICT, PERC key management doesn't meet this requirement, but some content protection schemes claim to do so..

On Fri, Mar 1, 2019 at 8:18 AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 01/03/2019 16:38, Cullen Jennings wrote:
However to get to the heart of why the MID is different than the SSRC in the splicing attack, the key thing with the splicing attack is the attacker gets the receiver to use a valid, but not really the correct, SRTP crypto context. As outlined inhttps://tools.ietf.org/html/rfc3711#section-3.2, the crypto context looked up from dest IP:port and SSRC. So changing the SSRC allows the attacker in the splicing attack to switch to a crypto context of the attackers choosing (and one the attacker has keys for). Changing the other things such as the MID does not allow this.


You are describing how ssrc splicing works, not what are its effects, or why it is an issue. I think I have found the origin of the ssrc rewriting issue and the splicing attack for perc in here:

https://www.ietf.org/archive/id/draft-westerlund-perc-rtp-field-considerations-00.txt
3.9.  SSRC

   The SSRC identifies the source of the RTP packet.  As each SSRC has
   its own RTP sequence number space as well as timestamp sequence,
   collisions shall be avoided.  For the PERC usage it is also important
   that a receiving endpoint can separate two different originating
   sources and to map the SSRC to a human readable name (or alias).  The
   important security related issue is that unless the originating RTP
   stream can be identified the MDD could create one outgoing stream
   that selects packets from either of them.  This may be challenging
   due to replay protection, but not impossible depending on how the
   sequence number and timestamps align.  To avoid having multiple
   identifers for the RTP packet stream, the design team has proposed
   that the SSRC shall be unique and the original value preserved to the
   receiving endpoint.

   Even if the originating endpoints have unique SSRCs, it is not clear
   if the same requirement will be extended to the MDD, and then
   especially media switching RTP mixers that have their own SSRCs.
   Thus translation of SSRC as a method for dealing with SSRC collisions
   may need to be dealt with.

   The original SSRC needs to be authenticated end-to-end to prevent the
   splicing attack described above.

So the main issue here is that "endpoint can separate two different originating sources and to map the SSRC to a human readable name (or alias)". By modifying the MIDs the MD is able to do exactly that, and have the same effect than splicing attack without having to rewrite the ssrcs, that is, the endpoint will not be able to differentiate rtp packets coming from two different sources as the MID is used for routing and not the ssrc.


Best regards

Sergio

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


-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------416A070AD0CE59806999B948-- From nobody Mon Mar 4 13:33:45 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 5EE911310D4; Mon, 4 Mar 2019 13:33:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155173521133.5237.13570820791941689806@ietfa.amsl.com> Date: Mon, 04 Mar 2019 13:33:31 -0800 Archived-At: Subject: [Perc] Genart telechat review of draft-ietf-perc-private-media-framework-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:33:32 -0000 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-perc-private-media-framework-?? Reviewer: Linda Dunbar Review Date: 2019-03-04 IETF LC End Date: 2019-02-13 IESG Telechat date: Not scheduled for a telechat Summary: This is my second time reviewing this draft. The authors have addressed all my comments from the last review cycle. Major issues: None Minor issues: None Nits/editorial comments: None