From nobody Sat Apr 1 09:06:12 2017 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 5BC38126E3A for ; Sat, 1 Apr 2017 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il2APusFmyXG for ; Sat, 1 Apr 2017 09:06:08 -0700 (PDT) Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.125]) (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 4359B1294FC for ; Sat, 1 Apr 2017 09:06:08 -0700 (PDT) Received: from smtp16.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 79DE25D1B; Sat, 1 Apr 2017 12:06:07 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9036E5CF5; Sat, 1 Apr 2017 12:06:06 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn4-1944.cisco.com ([UNAVAILABLE]. [173.38.117.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sat, 01 Apr 2017 12:06:07 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_816442FB-C764-4B71-809F-BBAF1013A85A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Sat, 1 Apr 2017 11:06:10 -0500 Cc: Sergio Garcia Murillo , Paul Jones , Bernard Aboba Message-Id: References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> To: perc@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 16:06:10 -0000 --Apple-Mail=_816442FB-C764-4B71-809F-BBAF1013A85A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A bunch of us had a long conversation about this yesterday and came up = with 3 or 4 reasonable approaches to this. It's complicated to = understand the pro and con of each one as there is some sort of counter = intuitive results about how they handle DDOS.=20 I'll write these up such that everyone can properly consider them all. = What I think would really help now is to outline what problems people = are trying to solve and how important they are.=20 Some things I know we want to work are: RTX FlexFEC I get the feeling that for most folks FEC is far more important than = RTX. Can people give me an idea of other things that need to work that = might be impacted by this as well as well as what things are nice to = have, vs important, vs critical to have in the first version. Thanks, Cullen=20 > On Mar 30, 2017, at 9:08 PM, Bernard Aboba = wrote: >=20 > This would be my preferred option as well, particularly because it = would allow the FEC and RTX packets to be authenticated. >=20 > On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo = > wrote: > On 31/03/2017 0:43, Paul E. Jones wrote: >=20 > RTX is a problem, because we want the middlebox to act on packets. = But since the RTX data is inserted before encryption and since the = middlebox does not have the E2E key, it's a problem. FEC presents = similar challenges. A possible solution is to do one pass of = encryption, then RTX, then the second. That was proposed at the meeting = yesterday. >=20 >=20 > This would be my preferred option too, which would mean that FEC = (well, Flex FEC better) and RTX are also HBH. >=20 > Best regards > Sergio >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_816442FB-C764-4B71-809F-BBAF1013A85A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

A bunch = of us had a long conversation about this yesterday and came up with 3 or = 4 reasonable approaches to this. It's complicated to understand the pro = and con of each one as there is some sort of counter intuitive results = about how they handle DDOS. 

I'll write these up such that everyone = can properly consider them all. What I think would really help now is to = outline what problems people are trying to solve and how important they = are. 

Some = things I know we want to work are:

RTX
FlexFEC

I get the feeling that for most folks FEC is far more = important than RTX. Can people give me an idea of other things that need = to work that might be impacted by this as well as well as what things = are nice to have, vs important, vs critical to have in the first = version.

Thanks,= Cullen 




On Mar 30, 2017, at 9:08 PM, Bernard Aboba = <bernard.aboba@gmail.com> wrote:

This would be my preferred option as well, particularly = because it would allow the FEC and RTX packets to be = authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia = Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 31/03/2017 0:43, = Paul E. Jones wrote:

RTX is a problem, because we want the middlebox to act on packets.  = But since the RTX data is inserted before encryption and since the = middlebox does not have the E2E key, it's a problem. FEC presents = similar challenges.  A possible solution is to do one pass of = encryption, then RTX, then the second.  That was proposed at the = meeting yesterday.


This would be my preferred option too, which would mean that FEC (well, = Flex FEC better) and RTX are also HBH.

Best regards
Sergio


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

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

= --Apple-Mail=_816442FB-C764-4B71-809F-BBAF1013A85A-- From nobody Sat Apr 1 09:13:23 2017 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 6600D124BE8 for ; Sat, 1 Apr 2017 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GXQzUc_dA0K for ; Sat, 1 Apr 2017 09:13:20 -0700 (PDT) Received: from smtp141.dfw.emailsrvr.com (smtp141.dfw.emailsrvr.com [67.192.241.141]) (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 5496C126E3A for ; Sat, 1 Apr 2017 09:13:19 -0700 (PDT) Received: from smtp30.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp30.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9D6A9E0263; Sat, 1 Apr 2017 12:13:18 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp30.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3B38FE0204; Sat, 1 Apr 2017 12:13:18 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 01 Apr 2017 12:13:18 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Sat, 1 Apr 2017 10:13:16 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <68A3E1FA-73B1-4E6F-9F9C-B7DC2E4389F9@iii.ca> References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 16:13:22 -0000 > On Mar 30, 2017, at 4:57 PM, Sergio Garcia Murillo = wrote: >=20 >=20 >=20 >> Even if we split the two-pass encryption step fully into two pieces, = that's not creating a tunnel or a new media type. It's just how the = crypto transforms are applied. Devices who receive the media are going = to know and understand this, because it will be negotiated in SDP.=20 >=20 > That is my key question, how it will be signaled? For what you are talking about, it is not really negotiated in SDP, it = is negotiated in the DTLS when it negotiates which transform to use for = SRTP. =46rom the endpoint (not the Media Distributor) point of view, = this is very much like a normal DTLS-SRTP call. It used a transform = called double... don't think of double as somehow changing the = application to work totally differently, think of it as a pretty normal = black box encryption that has the odd property that when if you only = know half the key, you can only decrypt/encrypt part of the packet. = Yes, inside it is is implemented with two encryption (thus the name = double) but think of it as a normal SRTP transform. When we change what = SRTP transform is in use, that is not visible in the SDP - it only = happens at DTLS level.=20 Hope that helps - glad to get on phone and talk to you about how I'm = implementing this if that helps.=20 >=20 > Best regards > Sergio >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Sat Apr 1 09:16:16 2017 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 025FC12946D for ; Sat, 1 Apr 2017 09:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht-bOM9Awx51 for ; Sat, 1 Apr 2017 09:16:13 -0700 (PDT) Received: from smtp141.dfw.emailsrvr.com (smtp141.dfw.emailsrvr.com [67.192.241.141]) (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 7AB45129468 for ; Sat, 1 Apr 2017 09:16:13 -0700 (PDT) Received: from smtp26.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id AA1DFA00C4; Sat, 1 Apr 2017 12:16:12 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 082BCA01B4; Sat, 1 Apr 2017 12:16:11 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 01 Apr 2017 12:16:12 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <262EFF2C-767F-46F8-B952-9D80579DD450@mozilla.com> Date: Sat, 1 Apr 2017 10:16:10 -0600 Cc: Paul Jones , Sergio Garcia Murillo , perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1061EA3E-0508-4C29-A854-00DAA50CA465@iii.ca> References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com> <262EFF2C-767F-46F8-B952-9D80579DD450@mozilla.com> To: Nils Ohlmeier X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 16:16:15 -0000 > To me it sounds like we should as the next step look at all header = extensions to analyze and write down if they are HBH or E2E. And if they = are E2E if they need to be protected against modification by the MD. >=20 Totally agree - the good news is we have done that and had multiple WG = calls on that.=20 From nobody Sat Apr 1 09:18:49 2017 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 5D09F126C26 for ; Sat, 1 Apr 2017 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viIzCbxXC9k9 for ; Sat, 1 Apr 2017 09:18:47 -0700 (PDT) Received: from smtp157.dfw.emailsrvr.com (smtp157.dfw.emailsrvr.com [67.192.241.157]) (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 EB5D4124BE8 for ; Sat, 1 Apr 2017 09:18:46 -0700 (PDT) Received: from smtp12.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 7612140112; Sat, 1 Apr 2017 12:18:46 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0B347400A0; Sat, 1 Apr 2017 12:18:45 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 01 Apr 2017 12:18:46 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> Date: Sat, 1 Apr 2017 10:18:44 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 16:18:48 -0000 > On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo = wrote: >=20 > My concerns is that there are scenarios in which this is not possible: > =E2=80=A2 Sender and receiver may not support same set of header = extensions > =E2=80=A2 Sender and receiver may have negotiated a different id = for same header extension > In any of the previous scenarios, the receiver will not be able to = parse the packet correctly, and at best case scenario, it will ignore = the header extension. >=20 Which header extensions are in use is negotiated in the SDP. The = conferencing software need to ensure that it only negotiates header = extensions such that any device receiving them can process them.=20= From nobody Sat Apr 1 09:20:39 2017 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 93280126C26 for ; Sat, 1 Apr 2017 09:20:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7hryD2H3XXRb for ; Sat, 1 Apr 2017 09:20:33 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91182124BE8 for ; Sat, 1 Apr 2017 09:20:33 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id w11so123004312wrc.3 for ; Sat, 01 Apr 2017 09:20:33 -0700 (PDT) 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; bh=NcrFZi0BUoSkevea/wlpwOwsowY8HRyFYy2Y5+kPpAE=; b=eBuWCx+odqkJGU5MKKR/ep3TSrbkaB6YIGZVF77oacdt+J6ACKjGFd5YdUisjjiRMa Omi/QGlYk2WCNB6hJki6xdp507CAyDVwtF/29XAbXUWZrgULlLnxn4E/hGa+HXzCZhl7 /WnlBtTOdBjx+3FFjEjUB8Ttki+uXXvT0Tup7i/Bl6qsHHAKfJi5Pty8E/GHspz9nn+j NeLTUPT6qzUMKTvLEAJTbDyFtJpY+QXwGpoHrL5YuDKpMr5U/4nmUU9So5qcf9hnCKNv atfJRdYKwti2ohDRgB3GYiirA9fV3PMGh6Oe1MC04AXjtSykdBG0HxUJXBAYxuGYy3OO IA7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NcrFZi0BUoSkevea/wlpwOwsowY8HRyFYy2Y5+kPpAE=; b=I6DEMt2KGPjPSEly4GwedirCeTxmtQ1F6MYf5OVSVurEGAc4O1/zcHPqWHoHNNs83L OosaQsGF2fMvuMU9J91AFiEIJI4JrxXm9fw9IyzxMKGZxujh7wtBm95v1AbJ033Fji1W U4KGFDIDwdy3w2B5w+tWFbsd7HnbEZ/5XQyS5wp9yog4M+xb4b5NdaKcBgwEwChmQdVN TE9CzicH9HiKZN4WSrYw8I6c9+1A1oLMIeZJAka4TFcHpcJejuj64AOd599kaBNlK7dy MBZrlpJrYmddqAyMy5v0dtQnTmU6EcR9T+aKQVGUdgOzVsG1jmbd/E5M93UBKRS3aau/ Z0hQ== X-Gm-Message-State: AFeK/H0Fo5BMPytIIyD1jIueyFHwwmETdB5/fpY92Pf5PjQbKatQ5zCfJNV+jnlNzekUsg== X-Received: by 10.223.135.113 with SMTP id 46mr8472908wrz.95.1491063631692; Sat, 01 Apr 2017 09:20:31 -0700 (PDT) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com. [74.125.82.51]) by smtp.gmail.com with ESMTPSA id 127sm7221573wmt.20.2017.04.01.09.20.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 09:20:31 -0700 (PDT) Received: by mail-wm0-f51.google.com with SMTP id y22so18119225wmh.0 for ; Sat, 01 Apr 2017 09:20:31 -0700 (PDT) X-Received: by 10.28.1.209 with SMTP id 200mr2860678wmb.74.1491063631203; Sat, 01 Apr 2017 09:20:31 -0700 (PDT) MIME-Version: 1.0 References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> In-Reply-To: <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> From: Emil Ivov Date: Sat, 01 Apr 2017 16:20:19 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Paul E. Jones" , Sergio Garcia Murillo , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113c843213757b054c1d4ead Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 16:20:37 -0000 --001a113c843213757b054c1d4ead Content-Type: text/plain; charset=UTF-8 On Thu, 30 Mar 2017 at 18:07, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 31/03/2017 0:43, Paul E. Jones wrote: > > > > RTX is a problem, because we want the middlebox to act on packets. > > But since the RTX data is inserted before encryption and since the > > middlebox does not have the E2E key, it's a problem. FEC presents > > similar challenges. A possible solution is to do one pass of > > encryption, then RTX, then the second. That was proposed at the > > meeting yesterday. > > > > > This would be my preferred option too, which would mean that FEC (well, > Flex FEC better) and RTX are also HBH. A bunch of is had a long conversation over lunch the other day and agreed that this is the way we should do it. +1 Emil > > > Best regards > Sergio > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > -- sent from my mobile --001a113c843213757b054c1d4ead Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, 30 Mar 2017 at 18:07, Serg= io Garcia Murillo <se= rgio.garcia.murillo@gmail.com> wrote:
On 31/03/2017 0:43, Paul E. Jones wrote:
>
> RTX is a problem, because we want the middlebox to act on packets.
> But since the RTX data is inserted before encryption and since the
> middlebox does not have the E2E key, it's a problem. FEC presents<= br class=3D"gmail_msg"> > similar challenges.=C2=A0 A possible solution is to do one pass of
> encryption, then RTX, then the second.=C2=A0 That was proposed at the<= br class=3D"gmail_msg"> > meeting yesterday.
>
>
This would be my preferred option too, which would mean that FEC (well,
Flex FEC better) and RTX are also HBH.

A bu= nch of is had a long conversation over lunch the other day and agreed that = this is the way we should do it.

+1

=
Emil


Best regards
Sergio


_______________________________________________
Perc mailing list
Perc= @ietf.org
https://www.ietf.org/mailman/listinfo/= perc
--
sent from my mobile
--001a113c843213757b054c1d4ead-- From nobody Sat Apr 1 12:34:29 2017 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 74199128D19 for ; Sat, 1 Apr 2017 12:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-tV6GR2mRsG for ; Sat, 1 Apr 2017 12:34:25 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 568E4128CD5 for ; Sat, 1 Apr 2017 12:34:25 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id w43so125322462wrb.0 for ; Sat, 01 Apr 2017 12:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=T3ibKogIbpL9nsYqdgbquwp21hrUh9QW6JsEZ7i90lc=; b=hd9cZxCkXWeFpMbD7wY+EwepzVWrgnInmkvCkmE/eMinyPkDOUhvF6+a4oBMDptRmO xMeBRoDQSYPY7r70h4XevMnQZs6fH5ExzlAOMgDTh+3JTfb/gY0Byc5241gv8st7qYo1 8XDjhK8tamjM6L9lmqJhdwRKHv9/q3is1c3FXyA6ih2JU/qbqiCQlDL8RkSzypAy01d8 kyU7n5ev9aQnPB1wZQcWluXg0xTnfjpItEpE1bha299VfZM2kiuC5ZaNeaTF79zLxnEt 243PRZ5PI2xkv3/ZP2l/tcScqpr7OxWuHDWrAyf1TtEVHQMzQbGMR/bWUzKBmkbfFi8v kPaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=T3ibKogIbpL9nsYqdgbquwp21hrUh9QW6JsEZ7i90lc=; b=eFUN3VwUnFVimyDWsjGN4aLWfbSbHyxnRM3v27AoaJfRZnQ+RXeYeSAsXnkLIB39l2 bB0ioiRhJqM9kY2shJAve7PWhcGrdU7+UqAaiZ/o13fNK2B6ztn5sQdxI4KHFGH0qZmC sQfkA+WccWOtqICq1/YeZR6tNJbLzks6wm6PHb3BKgso5iqx0j16z+W61VUpAfhnSQCj U1PqR4BjKaNV3/iJ54ga9u1S8nrRrt66LEg+wr6cA1XtfqmYz3WLACcUKYhipIJZiP1S qVkwrEgvU1edjca1OQfE8vP7tLeao9aggtDDmSkdcm5N7gET+hiKEzfGKOLW52dLTEk3 hpGQ== X-Gm-Message-State: AFeK/H2iTXPNmS6ryKzF5F9Q5bxBq52PtJT3Aw3TaOtEUHNDLR3o7Tbmk8lGK9nG+jbG/Q== X-Received: by 10.223.151.140 with SMTP id s12mr8625500wrb.58.1491075263696; Sat, 01 Apr 2017 12:34:23 -0700 (PDT) Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id w93sm11623836wrb.3.2017.04.01.12.34.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 12:34:22 -0700 (PDT) To: Cullen Jennings References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Sat, 1 Apr 2017 21:34:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> Content-Type: multipart/alternative; boundary="------------D0A68EF66EF7E0D8C55EFD9C" Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 19:34:27 -0000 This is a multi-part message in MIME format. --------------D0A68EF66EF7E0D8C55EFD9C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 01/04/2017 18:18, Cullen Jennings wrote: >> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo wrote: >> >> My concerns is that there are scenarios in which this is not possible: >> • Sender and receiver may not support same set of header extensions >> • Sender and receiver may have negotiated a different id for same header extension >> In any of the previous scenarios, the receiver will not be able to parse the packet correctly, and at best case scenario, it will ignore the header extension. > Which header extensions are in use is negotiated in the SDP. The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them. I don't think it is even viable to implement that: * Extensions ids are set by the offerer, so even if a new participant has same set of extensions than the conference, it may use different ids. This will require the SFU to renegotiate afterwards to set the ids to the "common ones" (not sure if it is even possible) * With current approach, there are extensions that ar HBH and ones that are E2E, but the usage intention is only known by the sender, so in the SDP the SFU will not be able to know which are meant to be HBH and which ones are E2E, so it will have to restrict them even if they are meant to be used HBH (like transport-wide-cc) * What would happen when a new participant joins and it does not support an extension of common set? Will the SFU have to renegotiate will all the participants to remove it or send it to the participant anyway? If the later, what is the meaning of having a common set of extensions anyway? Really, I don't see any use case for E2E extensions and the implementation seems horrible to me. Best regards Sergio --------------D0A68EF66EF7E0D8C55EFD9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 01/04/2017 18:18, Cullen Jennings wrote:
On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

My concerns is that there are scenarios in which this is not possible:
	• Sender and receiver may not support same set of header extensions
	• Sender and receiver may have negotiated a different id for same header extension
In any of the previous scenarios, the receiver will not be able to parse the packet correctly, and at best case scenario, it will ignore the header extension.
Which header extensions are in use is negotiated in the SDP.  The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them. 

I don't think it is even viable to implement that:

  • Extensions ids are set by the offerer, so even if a new participant has same set of extensions than the conference, it may use different ids. This will require the SFU to renegotiate afterwards to set the ids to the "common ones" (not sure if it is even possible)
  • With current approach, there are extensions that ar HBH and ones that are E2E, but the usage intention is only known by the sender, so in the SDP the SFU will not be able to know which are meant to be HBH and which ones are E2E, so it will have to restrict them even if they are meant to be used HBH (like transport-wide-cc)
  • What would happen when a new participant joins and it does not support an extension of common set? Will the SFU have to renegotiate will all the participants to remove it or send it to the participant anyway? If the later, what is the meaning of having a common set of extensions anyway?

Really, I don't see any use case for E2E extensions and the implementation seems horrible to me.

Best regards

Sergio

--------------D0A68EF66EF7E0D8C55EFD9C-- From nobody Sat Apr 1 12:50:07 2017 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 1C1D8129410 for ; Sat, 1 Apr 2017 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 194wXT-kfNgw for ; Sat, 1 Apr 2017 12:50:02 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 C3E0A128C84 for ; Sat, 1 Apr 2017 12:50:00 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id y22so20044134wmh.0 for ; Sat, 01 Apr 2017 12:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Qmv9cqiUc5fdBfzQsf2FGz2NeQdRhLI2bXljoQo5SfI=; b=bx888HAGB1zZ5A+KU+j5zhz48IkP3v3RsH94zj+fsdtHxzCXFNIn3+S+3W34EwW65e jIopPabPzMya9klykqSh3O0HNcaHBeNAvV+d+3IGmtO/7ioGYxTgN7lHSoTf6x7I/i0P oa25NbOq1rGlSCpM4vH1oUub9j07lZuEa9plwCRg/Eax/IP0zbd5zxGT9rHCN9jAKl4W TsJR+pFIP/5Jf14bnUlpjBPDXjpQ/TGSjhQUEuwaTW9W7gkW7dy352Zv4F6bC/pdxFNW //NSacWkBY0tv0txGMQrWx0IGUZRYJWEgpcfo8NlB4YqhAEgIr6R4vvBkQPzEWdm1iHJ FEfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Qmv9cqiUc5fdBfzQsf2FGz2NeQdRhLI2bXljoQo5SfI=; b=LHFH+wt/hRzC5evcUMdhfLX06RZjmmb6c600ErlyOF4sMBpZsVxOFQ6c0AtM8apbNL Mv0xcKVoq9myovGxEZLjzTUJDtpvWNOHWyE91WWpDthRp809LjkyAkUSmGJZyyR0EXvR SRiTthtMhfOL936948P1k1+mpRuouKCvqHst76agslB44KVlPzYVyhfuRXAeAMl0A95x UDefnacqE68kGDkHQ1GZZ6HkHyCG7AT4MoapztSYITUiayAV+0hw6Lbzbh3at7Nbd1mQ MPnL+e4n706xOs5W71HAucnmr+H0QSY3xBYQsHzYyIYNXMsUNSwSxCM5QlO+AbFPaCkp EERw== X-Gm-Message-State: AFeK/H1AEOSV+caqUzDtLkM5WbQWBXmQnNMzdReOXalmRwe+os5gmmEWDwozdB7bw+Xfbw== X-Received: by 10.28.92.212 with SMTP id q203mr3294440wmb.73.1491076199274; Sat, 01 Apr 2017 12:49:59 -0700 (PDT) Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id o196sm7793966wmg.12.2017.04.01.12.49.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 12:49:58 -0700 (PDT) To: Cullen Jennings References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Sat, 1 Apr 2017 21:50:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------129307181F4B490274027E5E" Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 19:50:05 -0000 This is a multi-part message in MIME format. --------------129307181F4B490274027E5E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 01/04/2017 21:34, Sergio Garcia Murillo wrote: > On 01/04/2017 18:18, Cullen Jennings wrote: >>> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo wrote: >>> >>> My concerns is that there are scenarios in which this is not possible: >>> • Sender and receiver may not support same set of header extensions >>> • Sender and receiver may have negotiated a different id for same header extension >>> In any of the previous scenarios, the receiver will not be able to parse the packet correctly, and at best case scenario, it will ignore the header extension. >> Which header extensions are in use is negotiated in the SDP. The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them. > > I don't think it is even viable to implement that: > > * Extensions ids are set by the offerer, so even if a new > participant has same set of extensions than the conference, it may > use different ids. This will require the SFU to renegotiate > afterwards to set the ids to the "common ones" (not sure if it is > even possible) > * With current approach, there are extensions that ar HBH and ones > that are E2E, but the usage intention is only known by the sender, > so in the SDP the SFU will not be able to know which are meant to > be HBH and which ones are E2E, so it will have to restrict them > even if they are meant to be used HBH (like transport-wide-cc) > * What would happen when a new participant joins and it does not > support an extension of common set? Will the SFU have to > renegotiate will all the participants to remove it or send it to > the participant anyway? If the later, what is the meaning of > having a common set of extensions anyway? > > Really, I don't see any use case for E2E extensions and the > implementation seems horrible to me. > Another issue, what happens when the sender wants to use a HBH header extension? currently the only differentiation between the HBH extensions and the E2E extensions are based on their relative position to the OHB header, which AFAIK is only set by the MD. So all extensions sent from the sender are E2E, which doesn't make sense at all. What happens if the sender needs to use a HBH extension, as the transport-wide-cc ones, and then the MD needs to set them also in order to make GCC work correctly? The packet sent from the MD to the receiver will have a duplicated set of extension values for the same id, one before the OHB, which is useless, and another one after the OHB which is the one meant to be used. Best regards Sergio --------------129307181F4B490274027E5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 01/04/2017 21:34, Sergio Garcia Murillo wrote:
On 01/04/2017 18:18, Cullen Jennings wrote:
On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

My concerns is that there are scenarios in which this is not possible:
	• Sender and receiver may not support same set of header extensions
	• Sender and receiver may have negotiated a different id for same header extension
In any of the previous scenarios, the receiver will not be able to parse the packet correctly, and at best case scenario, it will ignore the header extension.
Which header extensions are in use is negotiated in the SDP.  The conferencing software need to ensure that it only negotiates header extensions such that any device receiving them can process them. 

I don't think it is even viable to implement that:

  • Extensions ids are set by the offerer, so even if a new participant has same set of extensions than the conference, it may use different ids. This will require the SFU to renegotiate afterwards to set the ids to the "common ones" (not sure if it is even possible)
  • With current approach, there are extensions that ar HBH and ones that are E2E, but the usage intention is only known by the sender, so in the SDP the SFU will not be able to know which are meant to be HBH and which ones are E2E, so it will have to restrict them even if they are meant to be used HBH (like transport-wide-cc)
  • What would happen when a new participant joins and it does not support an extension of common set? Will the SFU have to renegotiate will all the participants to remove it or send it to the participant anyway? If the later, what is the meaning of having a common set of extensions anyway?

Really, I don't see any use case for E2E extensions and the implementation seems horrible to me.


Another issue, what happens when the sender wants to use a HBH header extension? currently the only differentiation between the HBH extensions and the E2E extensions are based on their relative position to the OHB header, which AFAIK is only set by the MD.

So all extensions sent from the sender are E2E, which doesn't make sense at all. What happens if the sender needs to use a HBH extension, as the transport-wide-cc ones, and then the MD needs to set them also in order to make GCC work correctly?

The packet sent from the MD to the receiver will have a duplicated set of extension values for the same id, one before the OHB, which is useless, and another one after the OHB which is the one meant to be used.

Best regards
Sergio
--------------129307181F4B490274027E5E-- From nobody Sat Apr 1 12:56:46 2017 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 335CB129329 for ; Sat, 1 Apr 2017 12:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 e0dLqwEWQPYY for ; Sat, 1 Apr 2017 12:56:43 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 3C0DD126B71 for ; Sat, 1 Apr 2017 12:56:43 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id y22so20100886wmh.0 for ; Sat, 01 Apr 2017 12:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dWdHXQIJSSL8xd8WSf4DzVBww6YS1oKBewygI2IPHdQ=; b=QEd+u6RwbXiUWxeyGR9VpKY1a/cGUTx7sSgaJVG1FPqBHkNqGRs3+Eg8P/HcyqyHk+ I84VxXrn1cQp/Da1ERduMWfnHO7zeAaiN9eW4QGZKtroZEpqlRzBC7Sbbzw7tRcJGXO1 W6XRm2/DDzQv2f9N1110PWHnxLksPvzKd1GBtKilHGY9D0ATsoejQih+/kcmc9jDfI+7 IOqCzL97+q48za8MYCnykdLJOb696/9g3NoTCQdWxCR1X+etwEHMPIsI07bsbgX5/nrZ 2fKSgb2bpLmKrRbIkdUFAEIedqCbtQBgrEiI/ilLeRnsAOOXovDvLcTzEbqO29baC79/ EQBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dWdHXQIJSSL8xd8WSf4DzVBww6YS1oKBewygI2IPHdQ=; b=KinbUDhI6DyNO6eE4uXvOvBktk2MTM/nIQS+hLzTKeyxLG0d+5JNqex4hx2KTvTBvv 2vAn3KxRBU2BYSkVh+6aOm00s2PNooGLK1YRUEiofsPmIxGt7d7A5hfaGjSn31llksX4 Ei8DEw6/BveDdYqfXBy29BzncYxr1k6iDqm8qBXGhqLH5Dko2wQqnt9GwJALqFk3Ro/b PFUplS7FUIQjCjAlRufD0VVzR/KEwuZxzgSQq8czX75wGXv/WO7qPhw1rSAdTGKsrUdy OcFEeIXUFTL+p2I6u+YriKuTOvO4GCExeAVUw17m7XYimYDDlpA9iQXD6/rJRl3GGgcK yVFA== X-Gm-Message-State: AFeK/H11vo8vADuUNxaQULg5eKshHEeQGzxP7Lv/48as2la11efn8kF6 qh+nMjVaAc7i20hoBUM= X-Received: by 10.28.88.2 with SMTP id m2mr3521907wmb.12.1491076601576; Sat, 01 Apr 2017 12:56:41 -0700 (PDT) Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id h65sm11632241wrh.32.2017.04.01.12.56.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 12:56:40 -0700 (PDT) To: Cullen Jennings References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <68A3E1FA-73B1-4E6F-9F9C-B7DC2E4389F9@iii.ca> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <014b44e7-39b9-7456-a529-e5b9ccfa6134@gmail.com> Date: Sat, 1 Apr 2017 21:56:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <68A3E1FA-73B1-4E6F-9F9C-B7DC2E4389F9@iii.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 19:56:45 -0000 On 01/04/2017 18:13, Cullen Jennings wrote: > >> On Mar 30, 2017, at 4:57 PM, Sergio Garcia Murillo wrote: >> >>> Even if we split the two-pass encryption step fully into two pieces, that's not creating a tunnel or a new media type. It's just how the crypto transforms are applied. Devices who receive the media are going to know and understand this, because it will be negotiated in SDP. >> That is my key question, how it will be signaled? > For what you are talking about, it is not really negotiated in SDP, it is negotiated in the DTLS when it negotiates which transform to use for SRTP. From the endpoint (not the Media Distributor) point of view, this is very much like a normal DTLS-SRTP call. It used a transform called double... don't think of double as somehow changing the application to work totally differently, think of it as a pretty normal black box encryption that has the odd property that when if you only know half the key, you can only decrypt/encrypt part of the packet. Yes, inside it is is implemented with two encryption (thus the name double) but think of it as a normal SRTP transform. When we change what SRTP transform is in use, that is not visible in the SDP - it only happens at DTLS level. > > Hope that helps - glad to get on phone and talk to you about how I'm implementing this if that helps. > Thanks, appreciated. I have been already checking on how this could be implemented on libwertc and this are the required changes, the process would look like that. Inner crypto can only be applied after all the headers have been set, luckily in libwertc, headers on the packet can't be modified after the payload is set. So inner crypto has to be done after the payload is set, and before the packet is feed to the rtx and fec processing. That will allow the RTX and FEC code to work unmodified for perc. Then, packet processing will continue, and outer crypto aplied when DTLS/SRTP code kicks in. As you can see, changes required are minimal, but perc is not a "black box", but a two independent process. In fact, effectively, what you will be doing is not a double dtls encryption, but just encrypting the payload with a custom srtp crypto and then sending it via DTLS. So, in fact, not sure why we need to change the DTLS negotiation at all for double, seems an overkill and would make any implementation much more complex than required. Best regards Sergio From nobody Sat Apr 1 14:36:08 2017 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 EED27126C26 for ; Sat, 1 Apr 2017 14:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIRkegD1wnHF for ; Sat, 1 Apr 2017 14:36:02 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 4F64A124D6C for ; Sat, 1 Apr 2017 14:36:02 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id i5so18435373pfc.2 for ; Sat, 01 Apr 2017 14:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CwJv1+IPwz4Xm5EVipidB38460OeaydvswDXKBnjW0c=; b=Pyr5vUc2xDWt3gimButGt4Q/CAQ1XsJoBuzHmklS4VlBdVqTlubzL0PNRS5hHAI0sE ZvdNur44YENF8YieExK73T/w/yn/oACuluMs4d0aAykqbdEZyrAwjo9o/ycRxnS/tkSr cN9C7Vig7Ri5SFlvPr7OuTwfOdvlJ42RJIfT8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CwJv1+IPwz4Xm5EVipidB38460OeaydvswDXKBnjW0c=; b=fFQI74DDXk6XHUALOvkn8nhq3W1VcNdxfXmINWWjMyitXGSA2VPNw24iUkjyQhuddD bZts5Zki5PylccIAELDX0ir+MIRjIG3Yah1sitiPDDVTJ3ouC0WYs77YFfediF1O5RWG ZXnoDDwE1wrHYekBzrBd/00uRQVS7x5F2FG2a9/ab5MWsEibB85nu/uzw3EJ+ko+PhP0 vszZ852k3g19CHxFUWbcjVSVCcce0Skr1kRmrTw4NHI7o43pPhND4SQo0bF9NV/itA7b 54xXG1gLj/SfHphNgVCJs0nPoMXJ0Kd05nQFGsdxXL1KGChtL8U1HkUKNO8tQuRTqNAe LOdQ== X-Gm-Message-State: AFeK/H1CcBD74fyguMwdoOKXuXDhU4NW2pyqM4z9lLzo1Ea0iUqOcuZlN1mHu+TCNBame0PD X-Received: by 10.99.95.77 with SMTP id t74mr9765686pgb.203.1491082561548; Sat, 01 Apr 2017 14:36:01 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:4123:bd77:14ab:73d2? ([2601:647:4601:ec84:4123:bd77:14ab:73d2]) by smtp.gmail.com with ESMTPSA id t6sm17655397pgo.42.2017.04.01.14.35.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 14:36:00 -0700 (PDT) From: Nils Ohlmeier Message-Id: <325F4413-D469-444C-8E76-948EE7C6FB78@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_17BBA774-37B4-4430-B218-57995763C54F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 1 Apr 2017 14:35:57 -0700 In-Reply-To: Cc: Cullen Jennings , perc@ietf.org To: Sergio Garcia Murillo References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 21:36:06 -0000 --Apple-Mail=_17BBA774-37B4-4430-B218-57995763C54F Content-Type: multipart/alternative; boundary="Apple-Mail=_83125BE8-9359-47DC-A503-965DD647E842" --Apple-Mail=_83125BE8-9359-47DC-A503-965DD647E842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 1, 2017, at 12:50, Sergio Garcia Murillo = wrote: >=20 > On 01/04/2017 21:34, Sergio Garcia Murillo wrote: >> On 01/04/2017 18:18, Cullen Jennings wrote: >>>> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo = = wrote: >>>>=20 >>>> My concerns is that there are scenarios in which this is not = possible: >>>> =E2=80=A2 Sender and receiver may not support same set of header = extensions >>>> =E2=80=A2 Sender and receiver may have negotiated a different id = for same header extension >>>> In any of the previous scenarios, the receiver will not be able to = parse the packet correctly, and at best case scenario, it will ignore = the header extension. >>> Which header extensions are in use is negotiated in the SDP. The = conferencing software need to ensure that it only negotiates header = extensions such that any device receiving them can process them. >> I don't think it is even viable to implement that: >>=20 >> Extensions ids are set by the offerer, so even if a new participant = has same set of extensions than the conference, it may use different = ids. This will require the SFU to renegotiate afterwards to set the ids = to the "common ones" (not sure if it is even possible) >> With current approach, there are extensions that ar HBH and ones that = are E2E, but the usage intention is only known by the sender, so in the = SDP the SFU will not be able to know which are meant to be HBH and which = ones are E2E, so it will have to restrict them even if they are meant to = be used HBH (like transport-wide-cc) >> What would happen when a new participant joins and it does not = support an extension of common set? Will the SFU have to renegotiate = will all the participants to remove it or send it to the participant = anyway? If the later, what is the meaning of having a common set of = extensions anyway? >> Really, I don't see any use case for E2E extensions and the = implementation seems horrible to me. >=20 > Another issue, what happens when the sender wants to use a HBH header = extension? currently the only differentiation between the HBH extensions = and the E2E extensions are based on their relative position to the OHB = header, which AFAIK is only set by the MD. That is a concept which I mis-understood initially as well. The OHB can = also be set by the originating client. And yes using the OHB as the = marker between HBH and E2E header extensions is kind of ugly. Especially = as probably most software out there today has no concept of inserting = header extensions in a particular order. I tend to think that the originating client should always insert the OHB = just to make things easier. This way the originating client no longer = needs to differentiate if it needs to insert the OHB only if uses HBH = and E2E extension, it will always set the OHB for all double encrypted = streams. Thus you might also use the OHB as kind of marker to = differentiate double encrypted streams from single encrypted once. And the receiver part of the MD would also become less complex as it can = rely on the fact that an OHB needs to be present. > So all extensions sent from the sender are E2E, which doesn't make = sense at all. What happens if the sender needs to use a HBH extension, = as the transport-wide-cc ones, and then the MD needs to set them also in = order to make GCC work correctly? >=20 > The packet sent from the MD to the receiver will have a duplicated set = of extension values for the same id, one before the OHB, which is = useless, and another one after the OHB which is the one meant to be = used. Since transport-wide-cc applies to a transport only, I would assume that = transport-wide-cc is HBH only. So the originating client inserts it = after its OHB header extension. MD removes the transport-wide-cc, since = the transport to the receiver is a different transport. And the MD = inserts its own transport-wide-cc after the OHB again. Best Nils Ohlmeier --Apple-Mail=_83125BE8-9359-47DC-A503-965DD647E842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 1, 2017, at 12:50, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

=20 =20
On 01/04/2017 21:34, Sergio Garcia Murillo wrote:
On 01/04/2017 18:18, Cullen = Jennings wrote:
On Mar 30, 2017, at 9:16 AM, Sergio =
Garcia Murillo <sergio.garcia.murillo@=
gmail.com> wrote:

My concerns is that there are scenarios in which this is not possible:
	=E2=80=A2 Sender and receiver may not support same set of header =
extensions
	=E2=80=A2 Sender and receiver may have negotiated a different id =
for same header extension
In any of the previous scenarios, the receiver will not be able to parse =
the packet correctly, and at best case scenario, it will ignore the =
header extension.
Which header extensions are in use is =
negotiated in the SDP.  The conferencing software need to ensure that it =
only negotiates header extensions such that any device receiving them =
can process them. 

I don't think it is even viable to = implement that:

  • Extensions ids are set by the offerer, so even if = a new participant has same set of extensions than the conference, it may use different ids. This will require the SFU to renegotiate afterwards to set the ids to the "common ones" (not sure if it is even possible)
  • With current approach, there are extensions that = ar HBH and ones that are E2E, but the usage intention is only known by the sender, so in the SDP the SFU will not be able to know which are meant to be HBH and which ones are E2E, so it will have to restrict them even if they are meant to be used HBH (like transport-wide-cc)
  • What would happen when a new participant joins = and it does not support an extension of common set? Will the SFU have to renegotiate will all the participants to remove it or send it to the participant anyway? If the later, what is the meaning of having a common set of extensions anyway?

Really, I don't see any use case for E2E = extensions and the implementation seems horrible to me.


Another issue, what happens when the sender wants to use a HBH header extension? currently the only differentiation between the HBH extensions and the E2E extensions are based on their relative position to the OHB header, which AFAIK is only set by the MD.

That is a = concept which I mis-understood initially as well. The OHB can also be = set by the originating client. And yes using the OHB as the marker = between HBH and E2E header extensions is kind of ugly. Especially as = probably most software out there today has no concept of inserting = header extensions in a particular order.

I tend to think that the originating client should = always insert the OHB just to make things easier. This way the = originating client no longer needs to differentiate if it needs to = insert the OHB only if uses HBH and E2E extension, it will always set = the OHB for all double encrypted streams. Thus you might also use the = OHB as kind of marker to differentiate double encrypted streams from = single encrypted once.
And the receiver part of the MD would = also become less complex as it can rely on the fact that an OHB needs to = be present.

So all extensions sent from the sender are E2E, which doesn't make sense at all. What happens if the sender needs to use a HBH extension, as the transport-wide-cc ones, and then the MD needs to set them also in order to make GCC work correctly?

The packet sent from the MD to the receiver will have a duplicated set of extension values for the same id, one before the OHB, which is useless, and another one after the OHB which is the one meant to be used.

Since transport-wide-cc applies to a transport = only, I would assume that transport-wide-cc is HBH only. So the = originating client inserts it after its OHB header extension. MD removes = the transport-wide-cc, since the transport to the receiver is a = different transport. And the MD inserts its own transport-wide-cc after = the OHB again.

Best
  = Nils Ohlmeier


= --Apple-Mail=_83125BE8-9359-47DC-A503-965DD647E842-- --Apple-Mail=_17BBA774-37B4-4430-B218-57995763C54F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4B0+AAoJEJ3NnGfOORkkDsYP/2IKAVwJwNQtCrqUfuutetNP iMAO+rOlCSMzNPKMtfr0H8IDOr7w02wk6Sb4F6A/rlk01Bz2pBxdjl9qrrQdP2uM TVNMdz6gJ5m6Pyo4RfU7AQfDd6vEDRvEhxV41TnbXzOzYWmKotWSnm/YApvNe3ry m9dfBqtb+uFSoDKu0wSErBGhBqcFc72D5lWpFzk25OIBy8IQLFxajuVV4E845MrR vzWV2mKz7EiUnH8QK49UZ4Txi56gQav106kt+pK/BoNKF+XY0QfeVYdMrr8pSJ3K W4YUerFEOFZNZ4Z5dFmyeEWFOJEHRwQgQ4WggxgTQO9b3F4/grHJmp90YzMc2L8/ s+Xt3/6JpC2FX2GMRpdq4p9ht6ZdGQ/lsL3DTSPIgCSHeyL4KW0NKBSeHb1PHfhq ZpbwneNuW4PhFYg/OfP8o0RfkwmUFvHXfsYh3IyZJ9Hn3dHLirpEWRIHBcY+dZUD dfoSjZ0B6hpO9+Nwsi8tnaGgAKKq8eMwUuHm+EWRRwYlhupFhYZQbjxmq3QgI8zA +sUPSzOHzk40Qb2bEz2gRfR420iN97zMar2elqd6UhTLbcyarUlxiTnQHojd1Ty0 cYV/bky2cAQXIiRHjAE6TCN/meQOfw40YDdzgH4QNTfwOAqDtwrJbZpA7ZirzOb9 PpGzpGqfX51egGFuuT1v =mtRV -----END PGP SIGNATURE----- --Apple-Mail=_17BBA774-37B4-4430-B218-57995763C54F-- From nobody Sat Apr 1 15:09:48 2017 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 7FF4212947A for ; Sat, 1 Apr 2017 15:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 95-6iYoLeJ_U for ; Sat, 1 Apr 2017 15:09:45 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 D016C1292FD for ; Sat, 1 Apr 2017 15:09:44 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id o81so21157407wmb.1 for ; Sat, 01 Apr 2017 15:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=PC6dil3O9R6kLFF9X4vkgMm+K8HfQ/AoCetYHR63iLs=; b=gembpheTkkod5brtAsWLneC+kB6hK/Hdo2wTXj9dhVh5iY82+QjGnkfyVmPD4iwFPJ 8QybERA9dtkPnIugKwBD2sRQd2hAR2cRSphWRCFqccPzWZQUVNRFjkgIZdGYedMMtdCx 3dNtIYXM5JuTag5nGU2q7IzwC/rNbtNz1aoIzwyOKyJpiaW1j/kvqQK8peaStPX2LKCW AHBxOmlYgX6CGiJdLTfEkOTbQOyx6Rmu80j+Q6DHTmGjcNvUmbNM0/BZmkYfd4+23ViZ D+ROGLxgBsP1frV4OTZm2szuGgYtRREWvWbBHlwZTMIZS31ppQL/fnyZfouNaVN1CEOm TAZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PC6dil3O9R6kLFF9X4vkgMm+K8HfQ/AoCetYHR63iLs=; b=qhZmaglSDS+vYq9wE6Ojn4X71kYcqN2iWXB1XB3RmxygdkrDc2sqNWxL1GbjCzi6tL MdDutU9F5Bj6NHdU0MAK7c2ImFxZuwKp9lzftsLJZhYuvD/Db59d3uyeSc+KO7nkkM6T ujUar2r8+iRH8dLkx5gPX5wAB2HqmeSwoivjDAUK2lYVZH3za4XUljQMKLa8LarUfG+Y lghxs5VIiGaX0uR4GuVKKxUvXwZ2g5LGAmz3zQGMs9lp8h8NtmrDKkiznRqaVw6lPTng obsGod2R516lVZ+wxUnQQaZo1BE7aqaX7vKJXo0GvKg3BIWvgrC9XJne6qLGu6SZkb+Y NrHQ== X-Gm-Message-State: AFeK/H3kFVjkifMs+Y68NRWJju2zOyHqdNu4Y4SWdXKhqE9E/Jasi40HZ/y4q9Gw5IhH6w== X-Received: by 10.28.222.4 with SMTP id v4mr3563976wmg.75.1491084582928; Sat, 01 Apr 2017 15:09:42 -0700 (PDT) Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id w4sm8085295wmg.29.2017.04.01.15.09.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 15:09:41 -0700 (PDT) To: Nils Ohlmeier References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> <325F4413-D469-444C-8E76-948EE7C6FB78@mozilla.com> Cc: Cullen Jennings , perc@ietf.org From: Sergio Garcia Murillo Message-ID: <0ead8a3a-27c7-f885-07cd-40191cc73c19@gmail.com> Date: Sun, 2 Apr 2017 00:09:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <325F4413-D469-444C-8E76-948EE7C6FB78@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 22:09:46 -0000 On 01/04/2017 23:35, Nils Ohlmeier wrote: > I tend to think that the originating client should always insert the > OHB just to make things easier. This way the originating client no > longer needs to differentiate if it needs to insert the OHB only if > uses HBH and E2E extension, it will always set the OHB for all double > encrypted streams. Thus you might also use the OHB as kind of marker > to differentiate double encrypted streams from single encrypted once. > And the receiver part of the MD would also become less complex as it > can rely on the fact that an OHB needs to be present. If sender is going to send the OHB data required to decrypt the payload, i think it would be a better idea to include it on the payload (and remove the E2E extensions completely). That would make it trivial to implement double-ecryption on the MD (in fact, you will need to do nothing). That way, the payload could be used in other scenarios, for example, recordings or to broadcast the conference via mpeg-dash in conjunction with W3C media source extensions/encrypted media extensions by anyone knowing the inner key/salt. Best regards Sergio From nobody Sun Apr 2 17:46:18 2017 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 7D737129437 for ; Sun, 2 Apr 2017 17:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMfQpelEAdhd for ; Sun, 2 Apr 2017 17:46:14 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A761712940C for ; Sun, 2 Apr 2017 17:46:14 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id r45so100489197qte.3 for ; Sun, 02 Apr 2017 17:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Jd2DuOm/OwaAGH8qLugDSclPvlRxfoeeB0CxX9TKYlg=; b=i36JC7SN04Ip8oaEDmGEZhqenSzBEe151/qLFlOCyi2XyDuWFj/4ZaOEqGq7RE607E FK3tUjLbvLuYiqjVW/N6xSoXCc3/Rd97oWvWdh/3l9IMl7S0fPc/LcoAg0TIeAPrBVDg se1O9B0SUEzOfP5MDmyjRw9SEThq+4K6vBhJgzpqfL1QeNOjrAa/XJmUGtNyvsHzUmrw LUEfjvgStZON4pGRG9qDlFvC8b4chb1mH7oQeFbX28Yu07m+E7tkeQzqWRR/ePPMmB4i MYb2jUCLSm15Jt6Q3FYOSk1Jp1WZs+CMg6atmVpOw+Jf31Z9btNLHPQ09IsXNPoaQLQK k5Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jd2DuOm/OwaAGH8qLugDSclPvlRxfoeeB0CxX9TKYlg=; b=QIb7C4iTF5krfhSjD9DsKpwx7oevhCWHPR63Ckewf+eVlPIa5jXUx7Q1sVKti+IB1M Kt9trDlMuzcvsObqLPOEiHZTJISTu8G2lwpUkmUYZfmzzmKxSZ9kD4yecpDOoZGzgKey t8LfmQKGD1vFNg802Wlv0Oaf4CV+1kKqInLxR6AGUmF/5TIercZ076XTq2uQO+htj0L1 aJFmJ5l0WOUsgPIFEhAodADTfjouP8ktW0Xqh+S+bIncFnOOa3KbOZ4OJw0d8M1zIyDS 08uR74CZdarSKpLGEmladKeRrCgGqM/4vHiny2NXDisk9TyV3IWBmedo2oLIZU1rKgR2 JcQA== X-Gm-Message-State: AFeK/H0IByvBFx3cyd43dBzNM46XwZjDZLUbTm5RAxNx4ek9tGqr2CH0YNuBgGU9lG78cUaaGQxggaIgBxLRGA== X-Received: by 10.237.60.3 with SMTP id t3mr15588121qte.86.1491180373585; Sun, 02 Apr 2017 17:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.101 with HTTP; Sun, 2 Apr 2017 17:46:13 -0700 (PDT) From: Suhas Nandakumar Date: Sun, 2 Apr 2017 17:46:13 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0e61da76d52d054c387cae Archived-At: Subject: [Perc] Draft Meeting Minutes X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 00:46:16 -0000 --94eb2c0e61da76d52d054c387cae Content-Type: text/plain; charset=UTF-8 Hello All We have uploaded draft meeting minute here: https://www.ietf.org/proceedings/98/minutes/minutes-98-perc-00 Please let us know if there are any omissions. Thanks to Dan Burnett for the raw notes Cheers Suhas --94eb2c0e61da76d52d054c387cae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 We have uploaded draft= meeting minute here:=C2=A0


Pleas= e let us know if there are any omissions. Thanks to Dan Burnett for the raw= notes


Cheers
Suhas
=
--94eb2c0e61da76d52d054c387cae-- From nobody Sun Apr 2 17:48:31 2017 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 7CDB91267BB for ; Sat, 1 Apr 2017 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sip-communicator-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 qVu6VnncrUwK for ; Sat, 1 Apr 2017 14:39:51 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 8239A1200FC for ; Sat, 1 Apr 2017 14:39:51 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id o67so93281248oib.1 for ; Sat, 01 Apr 2017 14:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sip-communicator-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=goVAUaJJZWMuk6hkLa35u2MQhvGbDMqF77LVlzrqaBQ=; b=Xp2T9ndllHUhi6LseMuQv8EU7KV10C0k9/lPYts2y4Kc44QPpGc/sb5Ay5ZDno+GFT EEuyUGQfRByTG5vePBwz9Dezib4+fOH1BtctyfyPVGnPLUckGws8jCE6f584HpT9IIcs r+Ik++7xiZ9oktCS+WBWLrfa1Mup9jHJM59n3kXq6gJ9WG5hlAhSkxT/Rj9ImxfIgSAm PfkxP4iGb/pyzG/RhQ6dZKF21uWbXpqarg6TpIXnFpBnBrWNdSjBoj3MWizOXS2rs4k3 yaQTTRlmUQBOSnwvIpMJazzcPJuhrSR9lYqI2FI5d8GRJdWxaQ+hQ6b20gF9ANgqFtHt wJAg== 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=goVAUaJJZWMuk6hkLa35u2MQhvGbDMqF77LVlzrqaBQ=; b=HDRCdQEMKo0vKWWGKx1dJnIZFocfUsQ6JNeDhVrHGq/exMspvZY+KxM/NDC9z55gbc 4GPFRTU83kCK8vj4s+ZRVky/FxrSHLjB5glK5P3Q5FPd1lPs10JiLi7NpdSnOfKn6Fl9 OZxoh4yWCnzKhbvMbOUwNMIFn5KTTTuhEZEb4pbAtp4UqSgtFFt5eoJn9yghGYTwCJZX EVXg4X0KXubEsrBlPy35j7o0r7CinnnAWvQQp8MuNiYOraQCVIvPN6pt7wLOvUtADr9H o6spTlYRC2ixTmKCQSFoqFggney43mWtNccGpiK7WwjK0NF7wFV0l3/WZMNM62pe7l+K WflQ== X-Gm-Message-State: AFeK/H1aT9jhSY9vO/WuLahWV6VbI7GkHWxwhrMr6gc3qSP3/R9JfqZVlvllowmmAmapBvr+mlwQnNyfO9rx+g== X-Received: by 10.157.12.149 with SMTP id b21mr5077017otb.99.1491082790893; Sat, 01 Apr 2017 14:39:50 -0700 (PDT) MIME-Version: 1.0 References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> In-Reply-To: From: Boris Grozev Date: Sat, 01 Apr 2017 21:39:40 +0000 Message-ID: To: Cullen Jennings , Sergio Garcia Murillo Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a11402b3c150bfd054c21c438 Archived-At: X-Mailman-Approved-At: Sun, 02 Apr 2017 17:48:30 -0700 Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 21:39:54 -0000 --001a11402b3c150bfd054c21c438 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Apr 1, 2017 at 3:50 PM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 01/04/2017 21:34, Sergio Garcia Murillo wrote: > > On 01/04/2017 18:18, Cullen Jennings wrote: > > On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo wrote: > > My concerns is that there are scenarios in which this is not possible: > =E2=80=A2 Sender and receiver may not support same set of header extensi= ons > =E2=80=A2 Sender and receiver may have negotiated a different id for sam= e header extension > In any of the previous scenarios, the receiver will not be able to parse = the packet correctly, and at best case scenario, it will ignore the header = extension. > > Which header extensions are in use is negotiated in the SDP. The confere= ncing software need to ensure that it only negotiates header extensions suc= h that any device receiving them can process them. > > I don't think it is even viable to implement that: > > - Extensions ids are set by the offerer, so even if a new participant > has same set of extensions than the conference, it may use different i= ds. > This will require the SFU to renegotiate afterwards to set the ids to = the > "common ones" (not sure if it is even possible) > - With current approach, there are extensions that ar HBH and ones > that are E2E, but the usage intention is only known by the sender, so = in > the SDP the SFU will not be able to know which are meant to be HBH and > which ones are E2E, so it will have to restrict them even if they are = meant > to be used HBH (like transport-wide-cc) > - What would happen when a new participant joins and it does not > support an extension of common set? Will the SFU have to renegotiate w= ill > all the participants to remove it or send it to the participant anyway= ? If > the later, what is the meaning of having a common set of extensions an= yway? > > Really, I don't see any use case for E2E extensions and the implementatio= n > seems horrible to me. > > > Another issue, what happens when the sender wants to use a HBH header > extension? currently the only differentiation between the HBH extensions > and the E2E extensions are based on their relative position to the OHB > header, which AFAIK is only set by the MD. > > So all extensions sent from the sender are E2E, which doesn't make sense > at all. What happens if the sender needs to use a HBH extension, as the > transport-wide-cc ones, and then the MD needs to set them also in order t= o > make GCC work correctly? > My understanding is that in this case the sender would insert an OHB followed by a transport-cc extension. The MD would then be able to modify and/or remove the transport-cc extension. Boris > > The packet sent from the MD to the receiver will have a duplicated set of > extension values for the same id, one before the OHB, which is useless, a= nd > another one after the OHB which is the one meant to be used. > > Best regards > > Sergio > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a11402b3c150bfd054c21c438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Apr 1, 2017 at 3:50 PM Ser= gio Garcia Murillo <s= ergio.garcia.murillo@gmail.com> wrote:
On 01/04/= 2017 21:34, Sergio Garcia Murillo wrote:
=20
On 01/0= 4/2017 18:18, Cullen Jennings wrote:
On Mar 30, 2017, at 9:16 AM, Sergio Garc=
ia Murillo <ser=
gio.garcia.murillo@gmail.com> wrote:

My concerns is that there are scenarios in which this is not possible:
	=E2=80=A2 Sender and receiver may not support same set of header extension=
s
	=E2=80=A2 Sender and receiver may have negotiated a different id for same =
header extension
In any of the previous scenarios, the receiver will not be able to parse th=
e packet correctly, and at best case scenario, it will ignore the header ex=
tension.
Which header extensions are in use is nego=
tiated in the SDP.  The conferencing software need to ensure that it only n=
egotiates header extensions such that any device receiving them can process=
 them. 

I don't think it is even viable to impleme= nt that:

  • Extensions ids are set by the offerer, so e= ven if a new participant has same set of extensions than the conference, it may use different ids. This will require the SFU to renegotiate afterwards to set the ids to the "common ones&qu= ot; (not sure if it is even possible)
  • With current approach, there are extensions= that ar HBH and ones that are E2E, but the usage intention is only known by the sender, so in the SDP the SFU will not be able to know which are meant to be HBH and which ones are E2E, so it will have to restrict them even if they are meant to be used HBH (like transport-wide-cc)
  • What would happen when a new participant jo= ins and it does not support an extension of common set? Will the SFU have to renegotiate will all the participants to remove it or send it to the participant anyway? If the later, what is the meaning of having a common set of extensions anyway?

Really, I don't see any use case for E2E e= xtensions and the implementation seems horrible to me.


Another issue, what happens when the sender wants to use a HBH header extension? currently the only differentiation between the HBH extensions and the E2E extensions are based on their relative position to the OHB header, which AFAIK is only set by the MD.

So all extensions sent from the sender are E2E, which doesn't make sense at all. What happens if the sender needs to use a HBH extension, as the transport-wide-cc ones, and then the MD needs to set them also in order to make GCC work correctly?

My understanding is that in this case the sender would in= sert an OHB followed by a transport-cc extension. The MD would then be able= to modify and/or remove the transport-cc extension.

Boris


=


The packet sent from the MD to the receiver will have a duplicated set of extension values for the same id, one before the OHB, which is useless, and another one after the OHB which is the one meant to be used.

Best regards

Sergio
_______________________________________________
Perc mailing list
Perc= @ietf.org
https://www.ietf.org/mailman/listinfo/= perc
--001a11402b3c150bfd054c21c438-- From nobody Mon Apr 3 07:09:50 2017 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 F2F90124234 for ; Mon, 3 Apr 2017 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 ZHZA9PKILiYR for ; Mon, 3 Apr 2017 07:09:45 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4F1126CD8 for ; Mon, 3 Apr 2017 07:09:45 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id x137so74894493lff.3 for ; Mon, 03 Apr 2017 07:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=71EyvtOQR3ygrnEMCxOpO8Nlj1TpieV3V7haFg8mRS4=; b=f4NRh/r0fdeDAeXhnXtqriM4YnRkgxsdo0P6qFE8YPJOBL1pwtdzVq0RP0Gl9L6juw nFlkcUdmEVIso3JFEWnlHb42j4pcfqHktiZg5r0aeXV/Suxa4XJxWmLewWdAp2Jor8wy GGISAXIzDVvbUbA7xW6yrJ8rBB7zcypS9jYvcYmsgn3jklhUq5tIRxawsdvww4MYjtdO zMTCpc6zJd3awAwFGkOLwVEf8Fbka2U+kFGlN2EkVO10O6oQPEaez0ggYAFXrPeEpwkq +3ktNv1Njd8VX53Z/nbWU7/+l4TPTfGKt7kqMZPcH2AtUN58iz8lBGxkPwAWP0YVWjwS M6vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=71EyvtOQR3ygrnEMCxOpO8Nlj1TpieV3V7haFg8mRS4=; b=oSdROW429CywQAqcyFVw1uhhplTJa5+rGXU3SjJbn7K0XinWDJCMYePS1/w3dUl910 8zq0/J5lwUXoYJo/jSJZnQkrjTIePRcTZm2gAAeAfUgpYDI6KM5I5eaOKVt/XMi+O8DK 8L5eUgsmCKtjcIlLE9m9+eYM9MmwA76KtpCaVfzRBLy7KUfxXeiGn5kLybv9WZyrPdt2 7q/1cQkhbtpRQeZLKVhxF3VWQqrhA02M3HOuloPTr2PfZokBNoWjNXb53YVJsHXyKSdV cbX8fhV9VXNu2bd9ig6L9aIOiMcJNIvb9hxZUtkkFVwbPKUhpgLv7M55GXOfD3RzJp1q 0WPg== X-Gm-Message-State: AFeK/H0eESvudc5xk+JSn8SOKXy5BR7+/aQeePzcNzL0cQZP0WF8ea2l MwkjMtmotpfvWhtY X-Received: by 10.28.135.149 with SMTP id j143mr9756564wmd.19.1491228583295; Mon, 03 Apr 2017 07:09:43 -0700 (PDT) Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id k105sm18212244wrc.12.2017.04.03.07.09.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 07:09:42 -0700 (PDT) Received: by mail-wr0-f176.google.com with SMTP id w43so170698750wrb.0 for ; Mon, 03 Apr 2017 07:09:42 -0700 (PDT) X-Received: by 10.28.1.209 with SMTP id 200mr9860397wmb.74.1491228581824; Mon, 03 Apr 2017 07:09:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.6 with HTTP; Mon, 3 Apr 2017 07:09:21 -0700 (PDT) In-Reply-To: <1061EA3E-0508-4C29-A854-00DAA50CA465@iii.ca> References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com> <262EFF2C-767F-46F8-B952-9D80579DD450@mozilla.com> <1061EA3E-0508-4C29-A854-00DAA50CA465@iii.ca> From: Emil Ivov Date: Mon, 3 Apr 2017 09:09:21 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Nils Ohlmeier , Paul Jones , Sergio Garcia Murillo , perc@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:09:48 -0000 On Sat, Apr 1, 2017 at 11:16 AM, Cullen Jennings wrote: > >> To me it sounds like we should as the next step look at all header extensions to analyze and write down if they are HBH or E2E. And if they are E2E if they need to be protected against modification by the MD. >> > > Totally agree - the good news is we have done that and had multiple WG calls on that. It would be helpful if, when making claims like this, you could back them up with links to the ML archive. In this case specifically, we obviously haven't done a great job analysing the problem, since we have no solutions to the issues Sergio is raising. Emil -- https://jitsi.org From nobody Mon Apr 3 07:25:53 2017 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 9C4011200C5 for ; Mon, 3 Apr 2017 07:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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 E5HKbtLeo2Ih for ; Mon, 3 Apr 2017 07:25:49 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB09126C89 for ; Mon, 3 Apr 2017 07:25:49 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id k6so166660442wre.2 for ; Mon, 03 Apr 2017 07:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mIg8k8tb67PC0sztgEPvSqZWwqXHIEzLqPhmwam3EiM=; b=JAD050w9C3PFJ+Yr+HdtuGPPfVuI1U5GjnR6EFVm7c7obCdoQxrnfR8ZOgTvqEZVxE fZtdgTL1Kojumr1HhFSLBU8awCX3K3f+9ltqkkJk42gRFO/R2HTF3+We0PjP44Xz0Gkn oA7PoGM48dM332HVDpqmPDliVcvv33jOQeKqboPNbcIwPzEk03nSlBOc2Ka6YMLROAJK vaMgG5HBsNvjWjpt42iPqEArU7qtvnWsFf+DN/jeUJt8grlbGcle2FizmkHCljBy9+Qi vCir0k1RS1XGVB8upaJs81GNrVyKZu3+zFBOIbsVLG0Z911FrLUFZiidnhO5FCYoCPwi KukA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mIg8k8tb67PC0sztgEPvSqZWwqXHIEzLqPhmwam3EiM=; b=tH6EAypQoCySVwwV4x6d+EFF+Tn+hT59BgozOaR0yCjbW6wGpz9DQGf1XQN7XAQgNb hX2KMlBcq+w5a/mh2O9DLXX7txYoeDtaxmZ5z6V4l9xwSxnQaD+AcErrF/zaHn8IURKc mBafyaftpTwulowEWO6wGVwzxMY90IYM+ENN7mll+V06cK7g0ZRpGzNlR+Yzia5FNOB8 OQLTT8n1hiMx9rAqMGjg6NIJPZmiediZhUcMxmZtQxmgCXYuEI/+ZhDyHPSGJeCX5PYS xsvAZRQ/I/gu99oujptV+Hr87S4SzAUIsRCARr6WRy/gfA3ikLpk8KBCXSspOPp75IlH iDOA== X-Gm-Message-State: AFeK/H2wKYQ3SaU/cIKdTFhLOqpLlKHV6YAsXEDBTC3vWpdYGGvqmbjTM+ayXpHKwnu4OA== X-Received: by 10.28.169.130 with SMTP id s124mr9862714wme.137.1491229547526; Mon, 03 Apr 2017 07:25:47 -0700 (PDT) Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com. [209.85.128.173]) by smtp.gmail.com with ESMTPSA id j2sm15873892wrd.26.2017.04.03.07.25.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 07:25:47 -0700 (PDT) Received: by mail-wr0-f173.google.com with SMTP id k6so166659874wre.2 for ; Mon, 03 Apr 2017 07:25:47 -0700 (PDT) X-Received: by 10.28.210.13 with SMTP id j13mr4448455wmg.94.1491229547157; Mon, 03 Apr 2017 07:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.6 with HTTP; Mon, 3 Apr 2017 07:25:26 -0700 (PDT) In-Reply-To: <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> <45F9AEBA-8454-4A79-BC05-7A85603E36B4@iii.ca> From: Emil Ivov Date: Mon, 3 Apr 2017 09:25:26 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Sergio Garcia Murillo , perc@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Double Encryption and header extensions issue X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:25:52 -0000 On Sat, Apr 1, 2017 at 11:18 AM, Cullen Jennings wrote: > >> On Mar 30, 2017, at 9:16 AM, Sergio Garcia Murillo wrote: >> >> My concerns is that there are scenarios in which this is not possible: >> =E2=80=A2 Sender and receiver may not support same set of header e= xtensions >> =E2=80=A2 Sender and receiver may have negotiated a different id f= or same header extension >> In any of the previous scenarios, the receiver will not be able to parse= the packet correctly, and at best case scenario, it will ignore the header= extension. >> > > Which header extensions are in use is negotiated in the SDP. The confere= ncing software need to ensure that it only negotiates header extensions suc= h that any device receiving them can process them. Great idea! Only problem is that Offer/Answer doesn't allow said conferencing software to guarantee consistent use of extension IDs across the entire call. Even without that, asserting use of the same extension across the entire conference would be rather painful as it would mean that non-supporting clients would either need to be left out, or supporting clients may have to be forced to turn them off at any time. Is this worth the trouble? What is the downside of having all extensions be HBH as per Sergio's propos= al? Emil --=20 https://jitsi.org From nobody Mon Apr 3 09:05:46 2017 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 6B7AD12945A for ; Mon, 3 Apr 2017 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4LpNh0B661bJ for ; Mon, 3 Apr 2017 09:05:43 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 357291292AE for ; Mon, 3 Apr 2017 09:05:43 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id f193so131441168oib.2 for ; Mon, 03 Apr 2017 09:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hnZAnhaVvmBFPl0MR0Gk8wKA7sU1SOSzhvUYmgoYZEI=; b=MLK0FK6rpQXbyITqRHodLWi9Kzta5SfQ0EiFRGsRmnAxWmvHsGJZEFReE+L6EtoR17 SZRAIcDE59Lee9KQtU9JZpE3dUyty21Xq5p6/tu5G/r/NPievEXIJyfWybLyW3dqWgSW hadNPMZRwB5VFJhANu7/kj1uv1j/F1OOZaD2KcrK10MVbFX7SZXl40ss30ejX9uWatHx RLQR9fO8QizLTy2e3B/QFN0/BNvwhyBFJVoMrmU14CJGLyB/+PqrLB7YG+bS0ooEUtNA fHU9altzUBAd/tPkAhZ4xFa+bfXYmqgWfmz8e0cbtYxr2zSzu6v0iVPUSTrMbIO1Ok2g twhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hnZAnhaVvmBFPl0MR0Gk8wKA7sU1SOSzhvUYmgoYZEI=; b=b949USxDt9N73vSInQ1gaMNsQx5pYU51QvvT336r1b/3GKdTuUGy1KH3LqxY0d2smq QPm73xu54/aay3nERuZV4x2Fq2Gs/oX/SDmwm3tZWGIEAhmKoUYpAR9CI/DAkaHfqGrB XJCFYas0ewODBryZJg46e8b7yfTm9eyyQq8fEcsm2Db3GdpyoeFor3X+sk8UTciud9qb kxcG7uDr6ryuaXDR1bAoNWN/4BhgFBtrKBVHe2/ModmgH0eRsd34WToMuaZWYC4viZ22 Kh6KGyoVArx1eOUGuM5WZNlCn8aLBlbajqcgyEDJTYiSMJWHaW+qoGbq6KfifCSv8D1K KPYQ== X-Gm-Message-State: AFeK/H0Fgrma0QLGjILCsJYlxNYcED9WBxz9nKBquou7gcSZfTVYOF8cMYqkqCxTidX2tx0Vw2o9yM7BruWM2g== X-Received: by 10.202.252.193 with SMTP id a184mr8175265oii.40.1491235542401; Mon, 03 Apr 2017 09:05:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Mon, 3 Apr 2017 09:05:41 -0700 (PDT) In-Reply-To: References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> From: Stephen Botzko Date: Mon, 3 Apr 2017 12:05:41 -0400 Message-ID: To: Bernard Aboba Cc: Sergio Garcia Murillo , "Paul E. Jones" , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113deffcc8073b054c4554c6 Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:05:45 -0000 --001a113deffcc8073b054c4554c6 Content-Type: text/plain; charset=UTF-8 +1 For RTX and XOR this might not be as important, but if you have more than one repair packet per group, then an evil actor could poison the repair (with some help from the combinatorial explosion) On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba wrote: > This would be my preferred option as well, particularly because it would > allow the FEC and RTX packets to be authenticated. > > On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> On 31/03/2017 0:43, Paul E. Jones wrote: >> >>> >>> RTX is a problem, because we want the middlebox to act on packets. But >>> since the RTX data is inserted before encryption and since the middlebox >>> does not have the E2E key, it's a problem. FEC presents similar >>> challenges. A possible solution is to do one pass of encryption, then RTX, >>> then the second. That was proposed at the meeting yesterday. >>> >>> >>> This would be my preferred option too, which would mean that FEC (well, >> Flex FEC better) and RTX are also HBH. >> >> Best regards >> Sergio >> >> >> _______________________________________________ >> 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 > > --001a113deffcc8073b054c4554c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

For RTX and XOR this might not be as= important, but if you have more than one repair packet per group, then an = evil actor could poison the repair (with some help from the combinatorial e= xplosion)

On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:
This would be my preferred option as well, particularly because it= would allow the FEC and RTX packets to be authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 31/03/2017 0:43, Paul E. Jones wrote:

RTX is a problem, because we want the middlebox to act on packets.=C2=A0 Bu= t since the RTX data is inserted before encryption and since the middlebox = does not have the E2E key, it's a problem. FEC presents similar challen= ges.=C2=A0 A possible solution is to do one pass of encryption, then RTX, t= hen the second.=C2=A0 That was proposed at the meeting yesterday.


This would be my preferred option too, which would mean that FEC (well, Fle= x FEC better) and RTX are also HBH.

Best regards
Sergio


_______________________________________________
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


--001a113deffcc8073b054c4554c6-- From nobody Mon Apr 3 09:21:20 2017 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 25B61129407 for ; Mon, 3 Apr 2017 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 97ms393CN8VB for ; Mon, 3 Apr 2017 09:21:16 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B142A127A97 for ; Mon, 3 Apr 2017 09:21:15 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id w11so175221078wrc.3 for ; Mon, 03 Apr 2017 09:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=wre1Fsrgig53Rdh2UiDR8Qo/zCX8fugpvSGhL36o/Fo=; b=l/7Wg47XmJuBzzDerW0lvR6q26R96Sq0Rlzl9iOAoICp0dTk1jka2vLzkLHgd3aP8v ZU0CQFAz/pgd5jVWA1ppU1Xp47wRow6qrUl5IxXs7RWG7F0yhesRL6l+eF1DIbVHt/lf n/F3Pb4q0mlHJ76vWIZ+l8oRuAsURJbSvIsGT8ewqVt9Rxky1aCTPA1XcUeAapd3wx9x bCtrLYhoqknCpZWPXRjFJMcH+MalTTBWlT9BKxqEKhPQ2tzPt964KBUozRS0T1uxgaHQ n69NuByAERQDbEqptR2gyVdL2bW+Iou2q4BlukwGtYr8ZEE3GgOjGjAPZ4qJO4O+tF7B G4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=wre1Fsrgig53Rdh2UiDR8Qo/zCX8fugpvSGhL36o/Fo=; b=Ha8g5+MtcehvVyDd44H/s7NOarmqAK5O0QQoivIVa24JI72HGaGbtPssiKxQ9fOIxe JInA5MdrAHAE7pJlxLX6pLzcLijndwuMGRK8oGypFL8U0Exrt4VudT17tpLUYOaoz7Sp ViCyJZLMOKvRHbeHUGArCOMyeHHtl7RvJl0Wr5YXBYhPlthE4xDlRhKJr6q1kZxUuOmD h68bKfCYfzYpXSCDvExxksLGv1XAD/sEdo2MIUPY6nvKLDRqzCC8po+wEyHBTeGu2w/2 i+NM2m9Wamokq44uzNAmGldZmUNWkD5ROZ0BXpHRZqOOOAVATrhK7QGZ33In5L3DjhoP 6MwQ== X-Gm-Message-State: AFeK/H059Rd4Qf1+hRlhOy2ywNeZ2IpOgbER3KcawYwRDTAur1bqyNWyU9HrLC1hcLdzyg== X-Received: by 10.223.173.165 with SMTP id w34mr16465185wrc.125.1491236473907; Mon, 03 Apr 2017 09:21:13 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id w93sm18861465wrb.3.2017.04.03.09.21.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 09:21:12 -0700 (PDT) To: Stephen Botzko , Bernard Aboba References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> Cc: "Paul E. Jones" , perc@ietf.org From: Sergio Garcia Murillo Message-ID: <22e7bb4d-c3ac-168b-0310-f560286f3415@gmail.com> Date: Mon, 3 Apr 2017 19:21:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------11B8EDDDDEF2C46127A5D7FE" Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:21:19 -0000 This is a multi-part message in MIME format. --------------11B8EDDDDEF2C46127A5D7FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit But this will not specific for PERC but DTLS/SRTP, right? I mean, same would apply to a non-perc rtx stream on webrtc. Best regards Sergio On 03/04/2017 18:05, Stephen Botzko wrote: > +1 > > For RTX and XOR this might not be as important, but if you have more > than one repair packet per group, then an evil actor could poison the > repair (with some help from the combinatorial explosion) > > On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba > > wrote: > > This would be my preferred option as well, particularly because it > would allow the FEC and RTX packets to be authenticated. > > On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo > > wrote: > > On 31/03/2017 0:43, Paul E. Jones wrote: > > > RTX is a problem, because we want the middlebox to act on > packets. But since the RTX data is inserted before > encryption and since the middlebox does not have the E2E > key, it's a problem. FEC presents similar challenges. A > possible solution is to do one pass of encryption, then > RTX, then the second. That was proposed at the meeting > yesterday. > > > This would be my preferred option too, which would mean that > FEC (well, Flex FEC better) and RTX are also HBH. > > Best regards > Sergio > > > _______________________________________________ > 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 > > > --------------11B8EDDDDEF2C46127A5D7FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
But this will not specific for PERC but DTLS/SRTP, right? I mean, same would apply to a non-perc rtx stream on webrtc.

Best regards
Sergio
On 03/04/2017 18:05, Stephen Botzko wrote:
+1

For RTX and XOR this might not be as important, but if you have more than one repair packet per group, then an evil actor could poison the repair (with some help from the combinatorial explosion)

On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
This would be my preferred option as well, particularly because it would allow the FEC and RTX packets to be authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 31/03/2017 0:43, Paul E. Jones wrote:

RTX is a problem, because we want the middlebox to act on packets.  But since the RTX data is inserted before encryption and since the middlebox does not have the E2E key, it's a problem. FEC presents similar challenges.  A possible solution is to do one pass of encryption, then RTX, then the second.  That was proposed at the meeting yesterday.


This would be my preferred option too, which would mean that FEC (well, Flex FEC better) and RTX are also HBH.

Best regards
Sergio


_______________________________________________
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



--------------11B8EDDDDEF2C46127A5D7FE-- From nobody Mon Apr 3 10:06:12 2017 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 3ACCE12948B for ; Mon, 3 Apr 2017 10:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 pTldXJiKRG2Z for ; Mon, 3 Apr 2017 10:06:08 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 921D4129483 for ; Mon, 3 Apr 2017 10:06:08 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id d2so555098oig.1 for ; Mon, 03 Apr 2017 10:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8yQsLQRraWSVCBpkr95IcoIJyq2A118UoTXVCQjAxjA=; b=c+FXSvFl8JknxrpCO6CuHLbXyXlGbmkyc1yGeywAyk0WRHPgF40QPxd0czLxqTvwd2 lnBZYmjqw1JWlmeJo6TNW93LdiGhguvq4uTk7EvtvN/THrOHcNhjd2kR1GCVFK8+7xLY xF7HoliinyHAgbI73aoqVLxLGI26TTdnrP9krRxlmad/BC/lMUirHuRBj1TqVdiA6hBy bz4k0LUmYLTBuiSKfDJ/VPCbMZW1/H5gGVtmFlB/liV6jTx2L2r7oxej2xNyIxkBUhF+ Rc8cwRX1JkrVDbJmblseEMJQsNom8+txZs1PnaSSlHPkZagG3hk+ds7vGP+chfYBcyza MGWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8yQsLQRraWSVCBpkr95IcoIJyq2A118UoTXVCQjAxjA=; b=WvuJfD0UeGMZdBObt07JWaghjSMn3rY+Rjw7adN3/vG2+tszoFsukRlNIU7aqwzLtZ tcS484rCskw8zVFgbtuz0CUw/V/w0t2ewa4C2Ad8G7Bs2koKKG30JDCFByQ1Y/bQT/Su DWBiOMFllWv2DIOkLer55k01QC1lqZ1yGbnK6djh9qyDkWjDzbiYe0b0p71K0vBnSA+y 3r9T7tJalVoP8+GrpJddrWU+D6Z9q3bOPlg83SwzN6SgAyslNTIdGyZTuir1YjxoeOSC pFeH0ix8A9CiQNivN0XgiQvYTXwFe/L/tOU5zBXSFrYJaElfhxZZ4WE1onSQhb/y8xCM 7Q2A== X-Gm-Message-State: AFeK/H3GKKur+8wbB5/uKMWTk1ewK9o/bVVcwkZ7/zSKuxiUs9/2B083wgGeI22b0Jnqkw3XAHp1n17FntWFtQ== X-Received: by 10.202.252.193 with SMTP id a184mr8308741oii.40.1491239167781; Mon, 03 Apr 2017 10:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Mon, 3 Apr 2017 10:06:07 -0700 (PDT) In-Reply-To: <22e7bb4d-c3ac-168b-0310-f560286f3415@gmail.com> References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> <22e7bb4d-c3ac-168b-0310-f560286f3415@gmail.com> From: Stephen Botzko Date: Mon, 3 Apr 2017 13:06:07 -0400 Message-ID: To: Sergio Garcia Murillo Cc: Bernard Aboba , "Paul E. Jones" , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113deffcdef129054c462c37 Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:06:11 -0000 --001a113deffcdef129054c462c37 Content-Type: text/plain; charset=UTF-8 Repair Poisoning can occur in any use case in which the repair packets themselves are not authenticated. Poisoning is a result of an evil actor sending bogus repair packets that are the correct size and which appear to be from the correct source. If the bogus packets are used to repair, then the reconstructed packet is incorrect. In PERC, the receiver can detect that the repair failed, since the reconstructed packet won't authenticate. If there is only one repair packet per block, then the receiver can try each received repair packet in turn, until it finds the true one that does reconstruct a packet that authenticates. However, if there are multiple repair packets per block, then this mitigation quickly becomes impractical. Instead, you need to reject the bogus repair packets prior to reconstruction. RFC 3711 states The default processing when using Forward Error Correction (e.g., RFC 2733 ) processing with SRTP SHALL be to perform FEC processing prior to SRTP processing on the sender side and to perform SRTP processing prior to FEC processing on the receiver side. Any change to this ordering (reversing it, or, placing FEC between SRTP encryption and SRTP authentication) SHALL be signaled out of band. That default processing order ensures that the repair packets can be authenticated, which mitigates the threat. In the specific case of Double, the threat is also mitigated if the repair packets are authenticated hop-by-hop. That allows the MD to repair flows it receives, and also to generate its own repair packets on flows it sends. Stephen On Mon, Apr 3, 2017 at 1:21 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > But this will not specific for PERC but DTLS/SRTP, right? I mean, same > would apply to a non-perc rtx stream on webrtc. > > Best regards > Sergio > > On 03/04/2017 18:05, Stephen Botzko wrote: > > +1 > > For RTX and XOR this might not be as important, but if you have more than > one repair packet per group, then an evil actor could poison the repair > (with some help from the combinatorial explosion) > > On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba > wrote: > >> This would be my preferred option as well, particularly because it would >> allow the FEC and RTX packets to be authenticated. >> >> On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >>> On 31/03/2017 0:43, Paul E. Jones wrote: >>> >>>> >>>> RTX is a problem, because we want the middlebox to act on packets. But >>>> since the RTX data is inserted before encryption and since the middlebox >>>> does not have the E2E key, it's a problem. FEC presents similar >>>> challenges. A possible solution is to do one pass of encryption, then RTX, >>>> then the second. That was proposed at the meeting yesterday. >>>> >>>> >>>> This would be my preferred option too, which would mean that FEC (well, >>> Flex FEC better) and RTX are also HBH. >>> >>> Best regards >>> Sergio >>> >>> >>> _______________________________________________ >>> 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 >> >> > > --001a113deffcdef129054c462c37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Repair Poisoning can occur in any use case in which the re= pair packets themselves are not authenticated.=C2=A0 Poisoning is a result = of an evil actor sending bogus repair packets that are the correct size and= which appear to be from the correct source.=C2=A0 If the bogus packets are= used to repair, then the reconstructed packet is incorrect. =C2=A0=C2=A0
In PERC, the receiver can detect that the repair failed, = since the reconstructed packet won't authenticate.=C2=A0 If there is on= ly one repair packet per block, then the receiver can try each received rep= air packet in turn, until it finds the true one that does reconstruct a pac= ket that authenticates.=C2=A0 However, if there are multiple repair packets= per block, then this mitigation quickly becomes impractical.=C2=A0 Instead= , you need to reject the bogus repair packets prior to reconstruction.
=
RFC 3711 states
=
   The default processing when using Forward Error Correction (e.g., RFC
   2733) processing wit=
h SRTP SHALL be to perform FEC processing prior
   to SRTP processing on the sender side and to perform SRTP processing
   prior to FEC processing on the receiver side.  Any change to this
   ordering (reversing it, or, placing FEC between SRTP encryption and
   SRTP authentication) SHALL be signaled out of band.

That default processing order ensures tha=
t the repair packets can be authenticated, which mitigates the threat.

In the specific case of Double, the threat i=
s also mitigated if the repair packets are authenticated hop-by-hop.  That =
allows the MD to repair flows it receives, and also to generate its own rep=
air packets on flows it sends.  

Stephen

On Mon, Apr 3, 2017 at 1:21 PM, Sergi= o Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
But this will not sp= ecific for PERC but DTLS/SRTP, right? I mean, same would apply to a non-perc rtx stream on webrtc.

Best regards
Sergio

On 03/04/2017 18:05, Stephen Botzko wrote:
+1

For RTX and XOR this might not be as important, but if you have more than one repair packet per group, then an evil actor could poison the repair (with some help from the combinatorial explosion)

On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
This would be my preferred option as well, particularly because it would allow the FEC and RTX packets to be authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo <sergio.garcia= .murillo@gmail.com> wrote:
On 31/03/2017 0:43, Paul E. Jones wrote:

RTX is a problem, because we want the middlebox to act on packets.=C2=A0 But since the RTX data is inserted before encryption and since the middlebox does not have the E2E key, it's a problem. FEC presents similar challenges.=C2=A0 A possible solution is to do one pass of encryption, then RTX, then the second.=C2=A0 That w= as proposed at the meeting yesterday.


This would be my preferred option too, which would mean that FEC (well, Flex FEC better) and RTX are also HBH.

Best regards
Sergio


_______________________________________________<= br> Perc mailing list
Pe= rc@ietf.org
https://www.ietf.org/mailman/li= stinfo/perc


_______________________________________________
Perc mailing list
Perc@ietf.or= g
https://www.ietf.org/mailman/listinfo/per= c




--001a113deffcdef129054c462c37-- From nobody Mon Apr 3 12:46:21 2017 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 DE40E1294FB for ; Mon, 3 Apr 2017 12:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 AZmSTXVkY8s9 for ; Mon, 3 Apr 2017 12:46:17 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 828D31294C3 for ; Mon, 3 Apr 2017 12:46:16 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id t20so5360663wra.1 for ; Mon, 03 Apr 2017 12:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=khzndwtg0m+M58gZNwuhtYoLzsLnCquYcBt936NzP4A=; b=UaQmxQWzX5IhvbNiXAuLVr7eci3TIF9dNBKerj4LAybSrRAbaxuxTdr+MkRyhKOeZd AoeID4MTFlRXGWsrdTvLE0qEJZoQiSi2NQdGU/A/F0TcTSpLRx0ze8BMLuvdoScXzrvg 5Ere+xPJj98mMZWGrfAqQ9zEJiAvyHTvplm0F/iCGmobgGWzhGUADKPsdf86ssFog9H3 VND6o0NtUNSRlzjFv88TPuizmuA8cow31DqPDtC0Ip0zSbuHfYb6NuI+Hr2vrcrKjFhI 2MFi+uGRvKmOBX6Yg7+uAjUcCN0fHnW2zJ5soz7hAeFL/Yk6lFDLfKrKjBB05hxTsO7d whsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=khzndwtg0m+M58gZNwuhtYoLzsLnCquYcBt936NzP4A=; b=k6LECZDcqbHGciiYjGYD//tVcr2OIjG0NJO6I0IPr6/bvvHfxt98Y++TZfhQ4gotsx vuZkw9Cfc0iMKbNNhpAhS4aM3L+gg0Ry5qbixf/KibfgHfnDgQ1/qysbTHqi1uMdiRll 2/TPA6uElNNmKjiRa5vwzOMUFTICWKiI/bFVv1pxeZjZ1vfQbsMrdzCPv4to1IQ1Tlt9 Nt2rqzX5LXK9HANY8fK7eLnwDNH3nnBv/fWtjN1OS8PGdhOsqGk7u6YLsU1wldZIar7/ i9yAJ/3TRr5q5qVbpXejP++Ah7oofAIzK33Eq4xo/dEzfOgPTR05IWJ8l/PXc583k5B5 rINQ== X-Gm-Message-State: AFeK/H3tld/OSzokT4DIdZLCRQz8ssIKYc8+20Fy1I2oYxg+pi8w4cDi nF9vMaA/oAc97w== X-Received: by 10.28.30.197 with SMTP id e188mr10380574wme.99.1491248774962; Mon, 03 Apr 2017 12:46:14 -0700 (PDT) Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id y22sm19431735wry.51.2017.04.03.12.46.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 12:46:14 -0700 (PDT) To: Stephen Botzko References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> <22e7bb4d-c3ac-168b-0310-f560286f3415@gmail.com> Cc: Bernard Aboba , "Paul E. Jones" , perc@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Mon, 3 Apr 2017 21:46:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DAFF0C5D7F8A9903454D1012" Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:46:19 -0000 This is a multi-part message in MIME format. --------------DAFF0C5D7F8A9903454D1012 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ste, Not following you, RTX packets are proposed to be HBH (as you state at the end), so they will be encrypted and authenticated. Best regards Sergio On 03/04/2017 19:06, Stephen Botzko wrote: > Repair Poisoning can occur in any use case in which the repair packets > themselves are not authenticated. Poisoning is a result of an evil > actor sending bogus repair packets that are the correct size and which > appear to be from the correct source. If the bogus packets are used > to repair, then the reconstructed packet is incorrect. > > In PERC, the receiver can detect that the repair failed, since the > reconstructed packet won't authenticate. If there is only one repair > packet per block, then the receiver can try each received repair > packet in turn, until it finds the true one that does reconstruct a > packet that authenticates. However, if there are multiple repair > packets per block, then this mitigation quickly becomes impractical. > Instead, you need to reject the bogus repair packets prior to > reconstruction. > > RFC 3711 states > The default processing when using Forward Error Correction (e.g.,RFC > 2733 ) processing with SRTP SHALL be to perform FEC processing prior > to SRTP processing on the sender side and to perform SRTP processing > prior to FEC processing on the receiver side. Any change to this > ordering (reversing it, or, placing FEC between SRTP encryption and > SRTP authentication) SHALL be signaled out of band. > That default processing order ensures that the repair packets can be > authenticated, which mitigates the threat. > In the specific case of Double, the threat is also mitigated if the > repair packets are authenticated hop-by-hop. That allows the MD to > repair flows it receives, and also to generate its own repair packets > on flows it sends. > Stephen > > On Mon, Apr 3, 2017 at 1:21 PM, Sergio Garcia Murillo > > wrote: > > But this will not specific for PERC but DTLS/SRTP, right? I mean, > same would apply to a non-perc rtx stream on webrtc. > > Best regards > Sergio > > On 03/04/2017 18:05, Stephen Botzko wrote: >> +1 >> >> For RTX and XOR this might not be as important, but if you have >> more than one repair packet per group, then an evil actor could >> poison the repair (with some help from the combinatorial explosion) >> >> On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba >> > wrote: >> >> This would be my preferred option as well, particularly >> because it would allow the FEC and RTX packets to be >> authenticated. >> >> On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo >> > > wrote: >> >> On 31/03/2017 0:43, Paul E. Jones wrote: >> >> >> RTX is a problem, because we want the middlebox to >> act on packets. But since the RTX data is inserted >> before encryption and since the middlebox does not >> have the E2E key, it's a problem. FEC presents >> similar challenges. A possible solution is to do one >> pass of encryption, then RTX, then the second. That >> was proposed at the meeting yesterday. >> >> >> This would be my preferred option too, which would mean >> that FEC (well, Flex FEC better) and RTX are also HBH. >> >> Best regards >> Sergio >> >> >> _______________________________________________ >> 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 >> >> >> > > --------------DAFF0C5D7F8A9903454D1012 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Ste,

Not following you, RTX packets are proposed to be HBH (as you state at the end), so they will be encrypted and authenticated.

Best regards
Sergio
On 03/04/2017 19:06, Stephen Botzko wrote:
Repair Poisoning can occur in any use case in which the repair packets themselves are not authenticated.  Poisoning is a result of an evil actor sending bogus repair packets that are the correct size and which appear to be from the correct source.  If the bogus packets are used to repair, then the reconstructed packet is incorrect.   

In PERC, the receiver can detect that the repair failed, since the reconstructed packet won't authenticate.  If there is only one repair packet per block, then the receiver can try each received repair packet in turn, until it finds the true one that does reconstruct a packet that authenticates.  However, if there are multiple repair packets per block, then this mitigation quickly becomes impractical.  Instead, you need to reject the bogus repair packets prior to reconstruction.

RFC 3711 states
   The default processing when using Forward Error Correction (e.g., RFC
   2733) processing with SRTP SHALL be to perform FEC processing prior
   to SRTP processing on the sender side and to perform SRTP processing
   prior to FEC processing on the receiver side.  Any change to this
   ordering (reversing it, or, placing FEC between SRTP encryption and
   SRTP authentication) SHALL be signaled out of band.

            
That default processing order ensures that the repair packets can be authenticated, which mitigates the threat.

In the specific case of Double, the threat is also mitigated if the repair packets are authenticated hop-by-hop.  That allows the MD to repair flows it receives, and also to generate its own repair packets on flows it sends.  

            
Stephen

On Mon, Apr 3, 2017 at 1:21 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
But this will not specific for PERC but DTLS/SRTP, right? I mean, same would apply to a non-perc rtx stream on webrtc.

Best regards
Sergio

On 03/04/2017 18:05, Stephen Botzko wrote:
+1

For RTX and XOR this might not be as important, but if you have more than one repair packet per group, then an evil actor could poison the repair (with some help from the combinatorial explosion)

On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
This would be my preferred option as well, particularly because it would allow the FEC and RTX packets to be authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 31/03/2017 0:43, Paul E. Jones wrote:

RTX is a problem, because we want the middlebox to act on packets.  But since the RTX data is inserted before encryption and since the middlebox does not have the E2E key, it's a problem. FEC presents similar challenges.  A possible solution is to do one pass of encryption, then RTX, then the second.  That was proposed at the meeting yesterday.


This would be my preferred option too, which would mean that FEC (well, Flex FEC better) and RTX are also HBH.

Best regards
Sergio


_______________________________________________
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





--------------DAFF0C5D7F8A9903454D1012-- From nobody Mon Apr 3 12:48:45 2017 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 9766012963F for ; Mon, 3 Apr 2017 12:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tBdbhrBU-Z1P for ; Mon, 3 Apr 2017 12:48:33 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3772129531 for ; Mon, 3 Apr 2017 12:48:32 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id z204so151967875vkd.1 for ; Mon, 03 Apr 2017 12:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6LY4qzMB5NbM+S5t6WlQeZcSt0NqMWrWZMDLknzSU1A=; b=VCXNdlMLZDkErASBQnQTbliTio1ggfPf1Ldt7p6/nXz+dFsAEjt5cdx+o+XlVP9T3B dEioTWeta6WjUvKkq1J2fLMniiwbV2RtXPrPXm9snGODbZtQT/TU53YDehNXFGZu42i3 hb8nZYXjHo+OasS0GsIRenQQenXOFdjKP0LEX5nzvWJP/aBZo4HLWnBt2PkVKtUlW53m WAODwT0g3NYc1yP3/oCVJEGYRmil6ioAGXOESkfshCEPI9+pBrkf37olJqgzUSar9eib tZwcMGkMb1t2N6y1KG4vkIBkNRMXd3ueJ2HhTzV9qAsk6TRcfxXcXdm7sWZLUQDCjDnS l2tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6LY4qzMB5NbM+S5t6WlQeZcSt0NqMWrWZMDLknzSU1A=; b=cQOUp88++OT8RjgsFSCibaLNhUU9TSx6KacjCVovjIVC627/adBeGkcPeufjxPVDAP TYtsQa+W0bC+N4aEL41q8sFADbG1GcVZksPAr2XaRjyZqoybNzh07wUz9VbO1ZTnX5AV zky4fp1/9PqJBQsV8qNZMBJCpY4ZPc1rKCkGUE2Up1h7lXb/o6rlMVUw6RSjU1/iMubt 5T1ePZUp9Xz+1mP0rYYqxke7VZDhhOf/aerKfkMKrJMOrcjPCiC9PMAueS/H55Y3xOGI fxYkenJCEOI4NjzPkHsgO+yO98Cf0Lw2/YBkcx8/a74uPPL8R2yJ8k6d4vMiFRHdx1rn 8Jwg== X-Gm-Message-State: AFeK/H3Zoh4d+q2YUKqGGFOgWV/PT8mFja5/w9aqupOCXkhRoKyFLAInGWTpUlU+fjFk2w8YBQ+YtKW0FlwKTA== X-Received: by 10.159.36.77 with SMTP id 71mr10152809uaq.124.1491248911682; Mon, 03 Apr 2017 12:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.99 with HTTP; Mon, 3 Apr 2017 12:48:11 -0700 (PDT) In-Reply-To: References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com> <22e7bb4d-c3ac-168b-0310-f560286f3415@gmail.com> From: Bernard Aboba Date: Mon, 3 Apr 2017 12:48:11 -0700 Message-ID: To: Stephen Botzko Cc: Sergio Garcia Murillo , "Paul E. Jones" , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113dc80ea714f6054c48716e Archived-At: Subject: Re: [Perc] FEC/RTX Was: Double encryption codec/payload type X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:48:38 -0000 --001a113dc80ea714f6054c48716e Content-Type: text/plain; charset=UTF-8 In general, having to perform operations prior to verifying packet authenticity tends to lead to problems. Moxie Marlinspike gives several examples of this in his blog post "The Cryptographic Doom Principle": https://moxie.org/blog/the-cryptographic-doom-principle/ For example, it might be possible to use "repair poisoning" to create a PERC "padding attack". On Mon, Apr 3, 2017 at 10:06 AM, Stephen Botzko wrote: > Repair Poisoning can occur in any use case in which the repair packets > themselves are not authenticated. Poisoning is a result of an evil actor > sending bogus repair packets that are the correct size and which appear to > be from the correct source. If the bogus packets are used to repair, then > the reconstructed packet is incorrect. > > In PERC, the receiver can detect that the repair failed, since the > reconstructed packet won't authenticate. If there is only one repair > packet per block, then the receiver can try each received repair packet in > turn, until it finds the true one that does reconstruct a packet that > authenticates. However, if there are multiple repair packets per block, > then this mitigation quickly becomes impractical. Instead, you need to > reject the bogus repair packets prior to reconstruction. > > RFC 3711 states > > The default processing when using Forward Error Correction (e.g., RFC > 2733 ) processing with SRTP SHALL be to perform FEC processing prior > to SRTP processing on the sender side and to perform SRTP processing > prior to FEC processing on the receiver side. Any change to this > ordering (reversing it, or, placing FEC between SRTP encryption and > SRTP authentication) SHALL be signaled out of band. > > > That default processing order ensures that the repair packets can be authenticated, which mitigates the threat. > > > In the specific case of Double, the threat is also mitigated if the repair packets are authenticated hop-by-hop. That allows the MD to repair flows it receives, and also to generate its own repair packets on flows it sends. > > > Stephen > > > On Mon, Apr 3, 2017 at 1:21 PM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> But this will not specific for PERC but DTLS/SRTP, right? I mean, same >> would apply to a non-perc rtx stream on webrtc. >> >> Best regards >> Sergio >> >> On 03/04/2017 18:05, Stephen Botzko wrote: >> >> +1 >> >> For RTX and XOR this might not be as important, but if you have more than >> one repair packet per group, then an evil actor could poison the repair >> (with some help from the combinatorial explosion) >> >> On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba >> wrote: >> >>> This would be my preferred option as well, particularly because it would >>> allow the FEC and RTX packets to be authenticated. >>> >>> On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo < >>> sergio.garcia.murillo@gmail.com> wrote: >>> >>>> On 31/03/2017 0:43, Paul E. Jones wrote: >>>> >>>>> >>>>> RTX is a problem, because we want the middlebox to act on packets. >>>>> But since the RTX data is inserted before encryption and since the >>>>> middlebox does not have the E2E key, it's a problem. FEC presents similar >>>>> challenges. A possible solution is to do one pass of encryption, then RTX, >>>>> then the second. That was proposed at the meeting yesterday. >>>>> >>>>> >>>>> This would be my preferred option too, which would mean that FEC >>>> (well, Flex FEC better) and RTX are also HBH. >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> > --001a113dc80ea714f6054c48716e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In general, having to perform operations prior to verifyin= g packet authenticity tends to lead to problems.

Moxie Marlins= pike gives several examples of this in his blog post "The Cryptographi= c Doom Principle":

For example, it might be possibl= e to use "repair poisoning" to create a PERC "padding attack= ". =C2=A0

On Mon, Apr 3, 2017 at 10:06 AM, Stephen Botzko <= stephen.botzko@gmail.com> wrote:
Repair Poisoning can occur in any use case in which = the repair packets themselves are not authenticated.=C2=A0 Poisoning is a r= esult of an evil actor sending bogus repair packets that are the correct si= ze and which appear to be from the correct source.=C2=A0 If the bogus packe= ts are used to repair, then the reconstructed packet is incorrect. =C2=A0= =C2=A0

In PERC, the receiver can detect that the repair = failed, since the reconstructed packet won't authenticate.=C2=A0 If the= re is only one repair packet per block, then the receiver can try each rece= ived repair packet in turn, until it finds the true one that does reconstru= ct a packet that authenticates.=C2=A0 However, if there are multiple repair= packets per block, then this mitigation quickly becomes impractical.=C2=A0= Instead, you need to reject the bogus repair packets prior to reconstructi= on.

RFC 3711 states

On Mon, Apr 3, 2017 at 1:21= PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
But this will not specific for PERC but DTLS/SRTP, right? I mean, same would apply to a non-perc rtx stream on webrtc.

Best regards
Sergio

On 03/04/2017 18:05, Stephen Botzko wrote:
+1

For RTX and XOR this might not be as important, but if you have more than one repair packet per group, then an evil actor could poison the repair (with some help from the combinatorial explosion)

On Thu, Mar 30, 2017 at 10:08 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
This would be my preferred option as well, particularly because it would allow the FEC and RTX packets to be authenticated.

On Thu, Mar 30, 2017 at 6:07 PM, Sergio Garcia Murillo <sergio.garcia= .murillo@gmail.com> wrote:
On 31/03/2017 0:43, Paul E. Jones wrote:

RTX is a problem, because we want the middlebox to act on packets.=C2=A0 But since the RTX data is inserted before encryption and since the middlebox does not have the E2E key, it's a problem. FEC presents similar challenges.=C2=A0 A possible solution is to do one pass of encryption, then RTX, then the second.=C2=A0 That w= as proposed at the meeting yesterday.


This would be my preferred option too, which would mean that FEC (well, Flex FEC better) and RTX are also HBH.

Best regards
Sergio


_______________________________________________<= br> Perc mailing list
Pe= rc@ietf.org
https://www.ietf.org/mailman/li= stinfo/perc


_______________________________________________
Perc mailing list
Perc@ietf.or= g
https://www.ietf.org/mailman/listinfo/per= c





--001a113dc80ea714f6054c48716e-- From nobody Tue Apr 4 03:22:39 2017 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 6284A1294B8 for ; Tue, 4 Apr 2017 03:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 j20B3NrvPscC for ; Tue, 4 Apr 2017 03:22:35 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 8D2271294B2 for ; Tue, 4 Apr 2017 03:22:35 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id z15so90008645lfd.1 for ; Tue, 04 Apr 2017 03:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=f+yw1kbDqyMv3/68e4iroQ7i1fMnHkatyR11ujkZIrE=; b=sXw+WV413B0s77HK6BF76QEAIpYOeZjrIGf03a07owtAJ0UV3XL+I8rnrDs8/agHig f8Z0do0AGWUVNOO/5A3n2NCsOoCDvEer6A/zGrS6m7PeHJKP8t0XuQpeP77oClr5zAoH 0FLwn07WRFM92ESeIVZ7+VBWjq1BOhQpMSAsuvfZ+7DivdHNdkBv68Xql0iqtstvFPli R6Jnb/2mYrq6yKUNuZkZNCcJV4W2EKlmnHWbzCq43qhk0T/lJjLYhgZoX2Ix9HGLPl+P E6H4y5UueR2hcJUR/6Rjv0AFnhsY73F4o6lxeJhxhOMsuedF6AAkMxkyaK1Xkn4ij3S9 wTwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=f+yw1kbDqyMv3/68e4iroQ7i1fMnHkatyR11ujkZIrE=; b=Aie8pl3Lm6RbvYE3hwNik0veai2tpXrX3Lw6OmDC+NR9O5srUrVgvxK1HBIaDDYiwI xZLRZWp/KmMWGPtTMfbrw+lpOYT2vsfnk4dtkVBYL8QgMabWXk0VaySE/N0a6U8XX+oT O2YZVdA6H8TSLY63Rh/OPuYBDj85XKA8gdwJjxAZWL70A18bTrN7gv+V1ZCfWgef90Wc k0U/2pC/PCoQhZruwkyKgTzWQxInY7kIvL3nKqRN+kj/CkWR/96SOJz6cmwCzsK+amWg 7msdRfXp6ah5M0lLWtEQrmmIO3UNm6yoeSEcw60nvZyxoyi2g30jy77aGb3SwSbdUkEx OJHw== X-Gm-Message-State: AFeK/H1NXyyuVzuzbBiATAm6zsAKex/IbfAml2Qgc2SiaofKPEuqFw0i B/2YLysidJLdNOMpBWU= X-Received: by 10.28.64.131 with SMTP id n125mr12887293wma.78.1491301353494; Tue, 04 Apr 2017 03:22:33 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id 92sm21802823wrh.8.2017.04.04.03.22.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 03:22:32 -0700 (PDT) To: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> Date: Tue, 4 Apr 2017 12:22:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 10:22:37 -0000 Hi all, Hate to ask this, but I have one more doubt when making changes to libwertc to support double. Should DTMF be also double protected or we should send it HBH? At least on webrtc, browsers are only meant to send DTMF, not receive them, so it would make sense to end them at the SFU and not propagate it to the other participants. Best regards Sergio From nobody Tue Apr 4 06:24:29 2017 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 E992A129697 for ; Tue, 4 Apr 2017 06:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 egPxvzpCoVum for ; Tue, 4 Apr 2017 06:24:25 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 2006C129574 for ; Tue, 4 Apr 2017 06:24:25 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id m133so54042829ybb.1 for ; Tue, 04 Apr 2017 06:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AfDVvtvpWSjzN8wREAsB5ChHyHP5gd4Wnj88N5nc89Y=; b=anjk5Ay5leryXmVVTniP9ay/1uIta+3xJnkNBhNSwNHnd1+TV5CTrF3ugZL6C4lbmP sU9UdT+fJVfxa1CVc7PfCVzuDhPy7lmqHOyOOpRIvHISR2xBPWq/CpaI9SC7tmRXACKe R8JUbNzuVCHfrRpXwjoL1U5UIn/mMDm6d9ZJv+xHNklez2MSzh8gQWQgzVPitYFWVwdb wYpTEnppIhJMdhNgjpbJipsVV+P0kl3D/vxU+xjpviMYy7+d8xEpbAcG5QanckDo7ELT UExtL0fwVBdzucF42zIyUiawl/nrJS4s6V2tBy7MduDMQbpnBZpN4BfphbISQFqpFO3u hpZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AfDVvtvpWSjzN8wREAsB5ChHyHP5gd4Wnj88N5nc89Y=; b=Nh0DagKrq2BAIFwfTYhRLMln0R33DC5d5RPeDf/44QC8lX53Tpc0ID/KUA5aR6HZqX ZFk/jZak+6f/f5xy2/vXdQjtqYoihIqGv4Jp6xgdZhg1dkJeWFtVr31oTlx6IO3gCaBa vjoMnAtN6cgcBp6axtgNJgdccydDw//j0UGSvzM2gKC0mBh9Krhfr8yzzwu7Y75N5dW3 +aAj+F1mgHppZc+IPAxPztIpTMCKfFXvyW7LtHaGrvfYiivOAd8Eu3Hx52EyshHCDNbM shA+Kwjn7Q65WxQLHpYeyrzOqD9QQewKzMeuztOvHAqPiZQ7ESIJKStbddB8aoX0IEmF 6KxA== X-Gm-Message-State: AFeK/H3Qh4nn3/4SMQ2fVwnP46dpOVF0oFh2HJPF/oPFXGdNn3I6qofqthTtuwufuSnNu3z082hPlc5QkCb8vw== X-Received: by 10.37.53.138 with SMTP id c132mr13708748yba.105.1491312264388; Tue, 04 Apr 2017 06:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 4 Apr 2017 06:23:43 -0700 (PDT) In-Reply-To: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> From: Eric Rescorla Date: Tue, 4 Apr 2017 06:23:43 -0700 Message-ID: To: Sergio Garcia Murillo Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114bbb32c4ba4b054c573154 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:24:28 -0000 --001a114bbb32c4ba4b054c573154 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi all, > > Hate to ask this, but I have one more doubt when making changes to > libwertc to support double. Should DTMF be also double protected or we > should send it HBH? > > At least on webrtc, browsers are only meant to send DTMF, not receive > them, so it would make sense to end them at the SFU and not propagate it to > the other participants. > I'm not following this reasoning. DTMF is media, so it should behave like other media. -Ekr Best regards > > Sergio > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a114bbb32c4ba4b054c573154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo <s= ergio.garcia.murillo@gmail.com> wrote:
Hi all,

Hate to ask this, but I have one more doubt when making changes to libwertc= to support double. Should DTMF be also double protected or we should send = it HBH?

At least on webrtc, browsers are only meant to send DTMF, not receive them,= so it would make sense to end them at the SFU and not propagate it to the = other participants.

I'm not followi= ng this reasoning. DTMF is media, so it should behave like other
= media.

-Ekr
=C2=A0

<= div>
Best regards

Sergio

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

--001a114bbb32c4ba4b054c573154-- From nobody Tue Apr 4 06:37:31 2017 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 7BFA81296B7 for ; Tue, 4 Apr 2017 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRZ4A2a85FQJ for ; Tue, 4 Apr 2017 06:37:27 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0DC1296B8 for ; Tue, 4 Apr 2017 06:37:20 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id w11so213587745wrc.3 for ; Tue, 04 Apr 2017 06:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=LAxjY8b5FW7UVpGc+gjp6htfM0oXrfcaXnMrW7YzNQQ=; b=rISrTGnD64ElPTPua/omvEirKT6TGf5GB1S7A1ygyxGBRA+YYbqBLriqh3hMt6ta1n jQDe67GydpVZItSQ8Y4fTnEYxJrNXKAswxoGIZGNx43JNtNbmxx0Wv84jK6PI95BNGDO YofbA31C7BLOeqF++71WoOsoDSMeG6MD+lyP7yTQUKUg0m4SsqxGoufn8cRY6Y+fkGlh HxSCdgSK2fPcdrjjtwh4tMEHLLc7af+h4srr6u1iTypgCEBuHQRXdpHrUBgP2aUxrkgF MK23Q8hxDmCLh54oLLsB5+/ptgzYjN8A84K9IKwy2FYIhlBLoLPByaoz4JYOb7Z2W6u0 JRiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=LAxjY8b5FW7UVpGc+gjp6htfM0oXrfcaXnMrW7YzNQQ=; b=AOPrMcV2sNXbjKSHBbF6/oS0sFL8D6bPN31yXaHsEtDVrpC90Iqyjm2AX3PeekjReA Tg63JzmWcDVZzfB5GveeuXNXGnrXHRbzDHS77dbtXF6Jr3lBPEv6c7NdpEchS280mEvh OU374GAIkoVr4dqzbdEcspdpOOiZ7YdBVXFkkLS0E2jjvPF3xYT0PlOufzELG7nK6KZI VO94IdV62gzvd+OcIOGEVzfvkjxE5MfYFek7eXW2G4zAwfohX25pE0B9T+7sUvBmsFr1 pxVql1hdhuY7JA8jjpNv08bhPClNQfL9dBx7/WxDG5mTnkvn4mgxqG0TEpFAg7GBHlTx Xvww== X-Gm-Message-State: AFeK/H0qdIpQc4oCkb2raEP7ZPOW0rVDxCKJ/SL6dMiJgxJJCHOe1Bc7 FXo5jlwZamiN7Q== X-Received: by 10.28.167.203 with SMTP id q194mr14446928wme.111.1491313037693; Tue, 04 Apr 2017 06:37:17 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id b42sm22476920wra.36.2017.04.04.06.37.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 06:37:16 -0700 (PDT) To: Eric Rescorla References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> Date: Tue, 4 Apr 2017 15:37:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------718C4ABDD9B06B2663F57A19" Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:37:29 -0000 This is a multi-part message in MIME format. --------------718C4ABDD9B06B2663F57A19 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 04/04/2017 15:23, Eric Rescorla wrote: > > > On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo > > wrote: > > Hi all, > > Hate to ask this, but I have one more doubt when making changes to > libwertc to support double. Should DTMF be also double protected > or we should send it HBH? > > At least on webrtc, browsers are only meant to send DTMF, not > receive them, so it would make sense to end them at the SFU and > not propagate it to the other participants. > > > I'm not following this reasoning. DTMF is media, so it should behave > like other > media. DTMF is media, for some definitions of media.. :) Avoiding the issue that using DTMF on webrtc is kind of, well, you know, my point is that there is no sense in forwarding DTMF to the meeting participants, as it is typically consumed by the media servers and also webrtc browsers don't allow to receive it in JS. Being imaginative, I can think in a use case when DTMF in PERC could make sense, for example to join PSTN participants into a conference. In this scenario, you will allow the participant to perform some operations via DTMF, and this operations would be done in the SFU, so the SFU needs to end the DTMF, and DTMF can't be E2E. Best regards Sergio --------------718C4ABDD9B06B2663F57A19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 04/04/2017 15:23, Eric Rescorla wrote:


On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi all,

Hate to ask this, but I have one more doubt when making changes to libwertc to support double. Should DTMF be also double protected or we should send it HBH?

At least on webrtc, browsers are only meant to send DTMF, not receive them, so it would make sense to end them at the SFU and not propagate it to the other participants.

I'm not following this reasoning. DTMF is media, so it should behave like other
media.

DTMF is media, for some definitions of media.. :)

Avoiding the issue that using DTMF on webrtc is kind of, well, you know, my point is that there is no sense in forwarding DTMF to the meeting participants, as it is typically consumed by the media servers and also webrtc browsers don't allow to receive it in JS.

Being imaginative, I can think in a use case when DTMF in PERC could make sense, for example to join PSTN participants into a conference. In this scenario, you will allow the participant to perform some operations via DTMF, and this operations would be done in the SFU, so the SFU needs to end the DTMF, and DTMF can't be E2E.

Best regards
Sergio



--------------718C4ABDD9B06B2663F57A19-- From nobody Tue Apr 4 08:26:37 2017 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 698B3120227 for ; Tue, 4 Apr 2017 08:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 M47YPAL3ADYD for ; Tue, 4 Apr 2017 08:26:34 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FD31286CA for ; Tue, 4 Apr 2017 08:26:34 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i203so63364348ywc.3 for ; Tue, 04 Apr 2017 08:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rqDsFIZOlDP7djpCOlkBiYgn64V6R6T2RPDvT9GP0Lk=; b=jtMtAi0g1+PBi31GpxgWAjR2LNvAHu0f6lebeYmVNSyLkq3lZGza1ilpvnN0AqyRCL mA7eujI6rBeIj6f7DjfnXYQCKJJndhQfYQlky7D/T9kqLbfEC6KMIDxqlYNiuBnR63oQ dHb+J6z2kispCR8HZBQvNYD1cOMDQTgHu2AXjgj2VtmPfPVA/ahxg73W3T/Twi4Jp5rO CkUrvtjNERxOCZLMrsBfnVFGAcNgpCfqM0rXUTQc3I+sId8I4+66LNChti3gHHH9iWD/ +zalbNS/uoZEeBHgpCJZWQwQi2pJnbeqhyaE+nPAwgnsEwhIwiO7aPKDFEWDzY1GGtlC nS9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rqDsFIZOlDP7djpCOlkBiYgn64V6R6T2RPDvT9GP0Lk=; b=NV12ny+LUbS1IFh7DmaDFBkdkf+WClEhCYnGbE4Ce0dpd20u9GbY4DaoVWZXvudNVu temsqK6e1HPewS0CLF4+qCQT9tg1baXGiqxSa4vVThuRVyYH55D612iKnvowDwpkkZPK 7N+Ib0i9FYR7nN/PIAM9lDgIEJMcRp/1QSb64XavQTemxHrJrZTQg/4zOVU0YRUiujw6 iElY9SjU8rbDPlW4n4JWSpGZ0GLDSYkW/ku9Wf0BnASEg4EW+GrnvV4Ljqyu/Wui/968 zoSF7EMlrZqPby+McQWiqXI807CxYrLzvifx52uGI1lOZiCSZYin2J8yYf2JksWbBaTr KuCQ== X-Gm-Message-State: AFeK/H1DYzq3iii5y6dOq7FwXaXJcpXgU9USEAdo5j67FYOsoRyTd2Iml3EmBpRpD7T2IDrYpE86vyvkTGWJJw== X-Received: by 10.13.204.206 with SMTP id o197mr16333149ywd.87.1491319593722; Tue, 04 Apr 2017 08:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 4 Apr 2017 08:25:53 -0700 (PDT) In-Reply-To: <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> From: Eric Rescorla Date: Tue, 4 Apr 2017 08:25:53 -0700 Message-ID: To: Sergio Garcia Murillo Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114e6b3ca17c16054c58e614 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:26:36 -0000 --001a114e6b3ca17c16054c58e614 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 6:37 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 04/04/2017 15:23, Eric Rescorla wrote: > > > > On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> Hi all, >> >> Hate to ask this, but I have one more doubt when making changes to >> libwertc to support double. Should DTMF be also double protected or we >> should send it HBH? >> >> At least on webrtc, browsers are only meant to send DTMF, not receive >> them, so it would make sense to end them at the SFU and not propagate it to >> the other participants. >> > > I'm not following this reasoning. DTMF is media, so it should behave like > other > media. > > > DTMF is media, for some definitions of media.. :) > > Avoiding the issue that using DTMF on webrtc is kind of, well, you know, > my point is that there is no sense in forwarding DTMF to the meeting > participants, as it is typically consumed by the media servers and also > webrtc browsers don't allow to receive it in JS. > > Being imaginative, I can think in a use case when DTMF in PERC could make > sense, for example to join PSTN participants into a conference. In this > scenario, you will allow the participant to perform some operations via > DTMF, and this operations would be done in the SFU, so the SFU needs to end > the DTMF, and DTMF can't be E2E. > Then you should create a separate channel, not make an exception. -Ekr > Best regards > Sergio > > > > --001a114e6b3ca17c16054c58e614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 4, 2017 at 6:37 AM, Sergio Garcia Murillo <s= ergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
On 04/04/2017 15:23,= Eric Rescorla wrote:


On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gma= il.com> wrote:
Hi all,

Hate to ask this, but I have one more doubt when making changes to libwertc to support double. Should DTMF be also double protected or we should send it HBH?

At least on webrtc, browsers are only meant to send DTMF, not receive them, so it would make sense to end them at the SFU and not propagate it to the other participants.

I'm not following this reasoning. DTMF is media, so it should behave like other
media.

DTMF is media, for some definitions of media.. :)

Avoiding the issue that using DTMF on webrtc is kind of, well, you know, my point is that there is no sense in forwarding DTMF to the meeting participants, as it is typically consumed by the media servers and also webrtc browsers don't allow to receive it in JS.
Being imaginative, I can think in a use case when DTMF in PERC could make sense, for example to join PSTN participants into a conference. In this scenario, you will allow the participant to perform some operations via DTMF, and this operations would be done in the SFU, so the SFU needs to end the DTMF, and DTMF can't be E2E.
<= /blockquote>

Then you should create a separate channel, = not make an exception.

-Ekr


Best regards
Sergio




--001a114e6b3ca17c16054c58e614-- From nobody Tue Apr 4 08:48:53 2017 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 030901293E9 for ; Tue, 4 Apr 2017 08:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRj1NFyykt6S for ; Tue, 4 Apr 2017 08:48:49 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 B5CA8128DE5 for ; Tue, 4 Apr 2017 08:48:48 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id k6so214274556wre.2 for ; Tue, 04 Apr 2017 08:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=y4Swhfu7M2JlCxZvXdQkNxlT73uCutuMg5Ney+fNGTU=; b=qklgfi2sW0T/uCdfDbypjzFkQEVkDSEQ6ja1YtPBR0ZzTVmFNUkJeFibZ6HEm/Jzdl ZkcmwXGflMXR2MmDDvGsKpvSizM6jJRIZyjWmV4FT95VRLws/wfeqG4jwDP0Ki6Vn5xy S5e/V4wolcQpOO4WdgygWi8biuhd2yI13SwnmdPtkX2sLJfzCG7tkhimdE4LmaAmfIKT bkSN9E7JnTfEUJj1mFSJuaLbm/1aG8vLOxH8BhWCBGw3KmQ4jfQaaU1GlyduWOtIKSUu f1Xe0DLisfzFDDbw65WPYgPy0tN5FNTv0SXGuywGDBaj8ma25iEh4mFfRfOI6Lu4gw6M IQzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=y4Swhfu7M2JlCxZvXdQkNxlT73uCutuMg5Ney+fNGTU=; b=g+EsoA/0FrfjlnPpTUDb/GkgA2R+TJr3L0ke5UFMKSa9vSHaenqxivjaQ4MutyScFT e1LaESPdfs+bSIl0cCwOWat941WYaXTLvLEmXTIYMSJ+AK1+lM1Dyty9LkY3icy/LxES L31OmXuTDIQuo8u+984uwv2etBr3usrFpwEWXgDU2fLL+uc/uKULSebQlh3cPJ3phy2Q oekCQKR0Nf7a3Ip0r0xP1kYUQ9xdzVx62+33AK0VZzzBYRZDO82AOmeC3hz+SYCu4QdG poj9IkJ1VYDD6V4tMdtibiU6ejFO9mftVnRqV68zE7Mdt2k0GibHR1SzoBhem52WOvnJ h9WQ== X-Gm-Message-State: AFeK/H1x3Jb1Rzl6wIZ9sigfU33/YLdBH20zuPtqrC3Goy/6N606Vw2mnmE2giM0ATGZKA== X-Received: by 10.223.153.108 with SMTP id x99mr20706184wrb.55.1491320927227; Tue, 04 Apr 2017 08:48:47 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id x133sm18964299wme.22.2017.04.04.08.48.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 08:48:45 -0700 (PDT) To: Eric Rescorla References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> Date: Tue, 4 Apr 2017 17:48:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8174B3CF8AD5CE5DA473EE4B" Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:48:51 -0000 This is a multi-part message in MIME format. --------------8174B3CF8AD5CE5DA473EE4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 04/04/2017 17:25, Eric Rescorla wrote: > > > On Tue, Apr 4, 2017 at 6:37 AM, Sergio Garcia Murillo > > wrote: > > On 04/04/2017 15:23, Eric Rescorla wrote: >> >> >> On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo >> > > wrote: >> >> Hi all, >> >> Hate to ask this, but I have one more doubt when making >> changes to libwertc to support double. Should DTMF be also >> double protected or we should send it HBH? >> >> At least on webrtc, browsers are only meant to send DTMF, not >> receive them, so it would make sense to end them at the SFU >> and not propagate it to the other participants. >> >> >> I'm not following this reasoning. DTMF is media, so it should >> behave like other >> media. > > DTMF is media, for some definitions of media.. :) > > Avoiding the issue that using DTMF on webrtc is kind of, well, you > know, my point is that there is no sense in forwarding DTMF to the > meeting participants, as it is typically consumed by the media > servers and also webrtc browsers don't allow to receive it in JS. > > Being imaginative, I can think in a use case when DTMF in PERC > could make sense, for example to join PSTN participants into a > conference. In this scenario, you will allow the participant to > perform some operations via DTMF, and this operations would be > done in the SFU, so the SFU needs to end the DTMF, and DTMF can't > be E2E. > > > Then you should create a separate channel, not make an exception. DTMF is already an exception, anyway, I am fine making DTMF in webrtc non functional with PERC. Best regards Sergio --------------8174B3CF8AD5CE5DA473EE4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 04/04/2017 17:25, Eric Rescorla wrote:


On Tue, Apr 4, 2017 at 6:37 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 04/04/2017 15:23, Eric Rescorla wrote:


On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi all,

Hate to ask this, but I have one more doubt when making changes to libwertc to support double. Should DTMF be also double protected or we should send it HBH?

At least on webrtc, browsers are only meant to send DTMF, not receive them, so it would make sense to end them at the SFU and not propagate it to the other participants.

I'm not following this reasoning. DTMF is media, so it should behave like other
media.

DTMF is media, for some definitions of media.. :)

Avoiding the issue that using DTMF on webrtc is kind of, well, you know, my point is that there is no sense in forwarding DTMF to the meeting participants, as it is typically consumed by the media servers and also webrtc browsers don't allow to receive it in JS.

Being imaginative, I can think in a use case when DTMF in PERC could make sense, for example to join PSTN participants into a conference. In this scenario, you will allow the participant to perform some operations via DTMF, and this operations would be done in the SFU, so the SFU needs to end the DTMF, and DTMF can't be E2E.

Then you should create a separate channel, not make an exception.

DTMF is already an exception, anyway, I am fine making DTMF in webrtc non functional with PERC.

Best regards
Sergio

--------------8174B3CF8AD5CE5DA473EE4B-- From nobody Tue Apr 4 11:32:31 2017 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 F052D129487 for ; Tue, 4 Apr 2017 11:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7cYQLsdMJHY for ; Tue, 4 Apr 2017 11:32:28 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 5A537129476 for ; Tue, 4 Apr 2017 11:32:28 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id x125so160273044pgb.0 for ; Tue, 04 Apr 2017 11:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=A5mh85vfsUEVGTP4ZfVoUsFtcBPKr0h+Ao7qniTwGys=; b=dGlYu5VNFUFZfsX5M07+vlZnKsDJjjuvWwxX1KMS6qPVVeg05b5nf5kVso+yYKcPgW 90rllIAla+HHL7CcVXDUSVanKwkheaHS/+njsETBSxwnojOIWoU1TOdrGnClttslyKFj djB5OAFprUwnlZFWzoDYb/dr7BScMGYm3KEwo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=A5mh85vfsUEVGTP4ZfVoUsFtcBPKr0h+Ao7qniTwGys=; b=f/73PiQUDHYQlKaoInUbpUhWPEXabJTOKDbSP1HyWBroK3YYKOr4ka58WX3r54N812 pnGYssczKOgN6tc04r5ZY7xU5NS6W1dqgHhhye3KxRS0NsTNsj2UBgLo7wGQ03h7MKA5 rnmjLOgonqhNBLNBjLBB7Nx/dRPHAhLTXs9yhiYjUzmh66EwDsobRfVC8mr02eec1XTH uUlRRKQ+0tleIlMep+v1U73Hn853fn3m01FPJKs08H/oY3jWbLHh4GN6BQRp98iyvar3 x2JhsTxDbHvb/MeH5ukpnoyU8P06uS0xA1tqFj1Q05NjHR9Y0CIEOenuhO0wQGLy6xBZ HOxQ== X-Gm-Message-State: AFeK/H1rRBgs+5ghJ3okur467+7l3E60LwfUMHRwMvHb5rv8RBvlNpgxa1hu3XGcBy+geyN6 X-Received: by 10.99.178.19 with SMTP id x19mr25078579pge.122.1491330747756; Tue, 04 Apr 2017 11:32:27 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:808e:d80f:e0c3:7474? ([2620:101:80fc:224:808e:d80f:e0c3:7474]) by smtp.gmail.com with ESMTPSA id w28sm33062689pfl.115.2017.04.04.11.32.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:32:26 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DDD8A065-B357-4E97-ACD6-236E496FF540"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 4 Apr 2017 11:32:23 -0700 In-Reply-To: <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> Cc: Eric Rescorla , perc@ietf.org To: Sergio Garcia Murillo References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:32:30 -0000 --Apple-Mail=_DDD8A065-B357-4E97-ACD6-236E496FF540 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 4, 2017, at 08:48, Sergio Garcia Murillo = wrote: >=20 >=20 > DTMF is already an exception, anyway, I am fine making DTMF in webrtc = non functional with PERC. +1 for declaring that DTMF is not going to be supported by PERC. Especially since the only use case I see would be trying to connect a = PERC call with double encryption to something in a legacy network = without any encryption at all, which appears like a bad idea to start = with. Nils --Apple-Mail=_DDD8A065-B357-4E97-ACD6-236E496FF540 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4+a4AAoJEJ3NnGfOORkk84QP/3kCuM2t9MUHeHPRFg2xYR19 V8vikkVLpzWMNkX7QdNheK2Gxq4dYgxhQsk6dAUPi7R/Kn52dVHT2RAhts0HAlaF StiFXzLbCKqpLYEIThQ/i/51V2ohZKy+PyZoEDyQuA+q5E3Z3N5dXF51oj5myRBR iB1/oQr8/+EVWzVrPUm9ui2MWGMs9pobzsIu0buwYX7Z8NZtjrWDXqvnvKh0GRS6 l19M4Jyp+xoErmxGAWlrLiqkQ6Dkyj+xhWSDLan+w2dBhPQ1cxdzsU6z3DEkWsZP pRq8DtELkQkhgmSdo0Hk5Wwg7tFr012znPwK7w7haDEUitGXdQDfDtaXLfkEwXwc M5YUV+U5Uu3JSYbsIoVTQdP6Oo7gPFEXDLhB+Q1l/PocYjR+ymKcOZTuRO1QXQ9r T3Q+27Vzr8MR7YcJUVYzR6H2sQSSks8wtd8Nkixy/dYqJzkrTVRd1iirnZChR/47 133X/ARu17kJq/XXWfzvejEPI0H/XxlXQ+HnmWipgAISjEBy2aYbSjWcQHrmAmJk UiokPSk5f0xsp9wO69EL7nZ8TP6w+XFpuTck3TWOC6XNPt9gTttjgAJxuL/H4Tul 3wUjg2bUM7lZAWM56bt4En4m3Mp3erkosfg2aPmWLBB+S+ZHFUOLOIuVrXyAAoq/ c8/4FYvcpZbSn72G/vPm =juJT -----END PGP SIGNATURE----- --Apple-Mail=_DDD8A065-B357-4E97-ACD6-236E496FF540-- From nobody Tue Apr 4 11:37:14 2017 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 E755D129498 for ; Tue, 4 Apr 2017 11:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=jive.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 qJ1-5HpZf3tB for ; Tue, 4 Apr 2017 11:37:11 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 0855B129476 for ; Tue, 4 Apr 2017 11:37:11 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id n21so146745413qta.1 for ; Tue, 04 Apr 2017 11:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YHbqKSF1UsyPgl9v6BUGUvZiwvdJxOUuG2Aum0otw3E=; b=tnVDHNbBiKDniqzxrwYzoYwFOcD2eVuYu1BhvnkAMFg3zF0ekYi+pXtMk2e/8Sz0YW 3OQd27n58N4O4x3tEUo1qP5WCj7+6Am9nU+G3Pe0nW5CyjylQlTeBI5+YMEg7RV+xGl7 T6wgq9aMusYoeSH31CroUELEjAKOUgYfh6uVgVRlfwSPpVKst3rImGRM4GM1jhfyMIuv ETkATJUHrzta9KORUDcKNbXPtO9kb9+hqdz/YKtfuzydukBA707nrDoR9i34JmHkgCBP iN9x08SdL0aN4MRauBCDegr0I+HlWzhz+YQcgW9o5v7QlYHZ5Yt+K+mojMPYksXrImNp 0KGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YHbqKSF1UsyPgl9v6BUGUvZiwvdJxOUuG2Aum0otw3E=; b=EjIZn6F0fg7L0PIPHgEQqu50+i+YB1vMleyEJO912Ni1Zt1SfRY5D89RBAO5iEAVWi c610NLyLUFMQS1Fr69QKNw4WpPT5oU7Mww0J4SQ6GZFyDI0GaKHk5E18Cvm/6xyBRUlU NgcIun2K8QnoKVEhLnywPTvKciEz9ihEE786yjKUUaWhYYrFpSZj7D06LNBpUo/+LKCC KLMNSts8NYXaxSBNymplfruthPyi4j0Wmb0qIugfFqUOxDTmHinIzzF/vx85nqDIirmW uS8rRFRgRjuQyi3cqv41yOLdceeZu/IRwNJ4IiN3sxrNc349zkFAOqbx4jwwD19SH1/t XgYQ== X-Gm-Message-State: AFeK/H2ayd2FHSlRRz3o9R1TSZwYVsDgufJ39mnmN4A5OxTx3aOIJQJxpouLW9P84QETPUwkkqac722xkjFnN5JRJO0hQRvuj7E0jwOEGWk1FKK+7HSakSQ0qE8GyOUOzUPpIF4cCfjGetmMIhvU0zJzJ/ccW5tz0Nct9CPEvL8= X-Received: by 10.200.53.209 with SMTP id l17mr24676409qtb.281.1491331030065; Tue, 04 Apr 2017 11:37:10 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:54bd:3e47:33a7:b167]) by smtp.gmail.com with ESMTPSA id f126sm12396735qkc.47.2017.04.04.11.37.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:37:09 -0700 (PDT) To: Nils Ohlmeier , Sergio Garcia Murillo References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> Cc: Eric Rescorla , perc@ietf.org From: Simon Perreault Message-ID: <3817a5d4-b570-0fc0-5bb6-31fdc44cbffa@jive.com> Date: Tue, 4 Apr 2017 14:37:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:37:13 -0000 Le 2017-04-04 14:32, Nils Ohlmeier a crit : > +1 for declaring that DTMF is not going to be supported by PERC. DTMF will work fine. It's just the relay that won't have access to it. Endpoints will get DTMF as usual. > Especially since the only use case I see would be trying to connect a PERC call with double encryption to something in a legacy network without any encryption at all, which appears like a bad idea to start with. Real-world use cases for DTMF in conferences: - 3-way call where one user is helping another navigate an IVR. - Dialing out from a conference to a PSTN user and having to enter the user's extension number as DTMF. Those should still work with PERC, as far as I know. Using a PERC/PSTN gateway, of course. -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Tue Apr 4 11:43:50 2017 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 34E101294A2 for ; Tue, 4 Apr 2017 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mCrmN6f39C29 for ; Tue, 4 Apr 2017 11:43:46 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 DBFA11294A9 for ; Tue, 4 Apr 2017 11:43:35 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id o81so32835821wmb.1 for ; Tue, 04 Apr 2017 11:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9ZYBkz0eqcUG/TdElGAQWy5/LQM7ke3qlEOPWhoxCbI=; b=CGtcoZ/8wJpAqLB4qX646LG0oFz3NNCz8TPbpx9th4x3Shjz+ki7kJfyZNiGTkqBRn 5IegbA85G4MArWiX/7x8yhVwot4JiGAQC708SdMKton0pqXLux2ojo5Rd7Y+lTU7KzzV zpiQ7+l6kHLF1bssSsAlGeBaRinNzykCZJquG/X4qZKSMkL6/ut7XUKJNaLEJR9Uieqz 4O3W5coVSDKKTwUQLAYRdeVVGkNyShr/VRJD9tGySWV+OhZlFj9Q/rbPxo9eoTi28DeN b+9f7BvuJeWtI4BAgc97Bsa7N8RVdyJjdBHmkhdIR0nBgwgu8GGGGwWAVrJRmpZdF5bM ntug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9ZYBkz0eqcUG/TdElGAQWy5/LQM7ke3qlEOPWhoxCbI=; b=mDnsSR1WqdPBHycxGVx8DAK0cIkSe05YD6y+V63uCpwbskXmqOy4jg65io1oqciqz9 O4Ify++wYQy+TQMd3str5GkyAGp9emo765chrBdYb8f4qCd6QdhN6FUPF/fBSXFK4jhU vgxYqIlFDedE7qYZr/8gpr5Qvjr9A0SRL2hPeItd0u6XdnECpQOx25kNkStW6KYqiMYv +ZZdFqqYFJYGHjZ/512FRr986yZ4VkcvBykqd7EcLBtb5GNsMkuSvWOpINmNzzCpHKI0 LYqKsMA3bS3ATDNHZdWBCO3k7PpcDqgaQ8QcIGw1rinCtC7ys/XyA5fi0Ii7VT2BpuD6 0NNg== X-Gm-Message-State: AFeK/H1A2udIG6+3gs+JyVQWURWGmwltVfKFhlDwYYgoI5+Fn0EGSCSO 1atsD/aCRNeMZTiUMFM= X-Received: by 10.28.113.12 with SMTP id m12mr15670591wmc.18.1491331414157; Tue, 04 Apr 2017 11:43:34 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id n13sm9398013wmi.28.2017.04.04.11.43.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:43:33 -0700 (PDT) To: Simon Perreault , Nils Ohlmeier References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <3817a5d4-b570-0fc0-5bb6-31fdc44cbffa@jive.com> Cc: Eric Rescorla , perc@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Tue, 4 Apr 2017 20:43:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3817a5d4-b570-0fc0-5bb6-31fdc44cbffa@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:43:48 -0000 On 04/04/2017 20:37, Simon Perreault wrote: > Le 2017-04-04 14:32, Nils Ohlmeier a crit : >> +1 for declaring that DTMF is not going to be supported by PERC. > DTMF will work fine. It's just the relay that won't have access to it. > Endpoints will get DTMF as usual. WebRTC only supports sending DTMF not receiving it. >> Especially since the only use case I see would be trying to connect a PERC call with double encryption to something in a legacy network without any encryption at all, which appears like a bad idea to start with. > Real-world use cases for DTMF in conferences: > > - 3-way call where one user is helping another navigate an IVR. > > - Dialing out from a conference to a PSTN user and having to enter the > user's extension number as DTMF. That won't work as that would be have to be performed on the conferencing server, which will not have access to the DTMF data if it is E2E. BR Sergio From nobody Tue Apr 4 11:46:02 2017 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 BF7D912426E for ; Tue, 4 Apr 2017 11:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 P9xI6FrN3yya for ; Tue, 4 Apr 2017 11:45:59 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 817791293DF for ; Tue, 4 Apr 2017 11:45:59 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-10v.sys.comcast.net with SMTP id vTSicXJ2s61D9vTSocYQ0r; Tue, 04 Apr 2017 18:45:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1491331558; bh=n5VhfHXI5w44K2T0ggNXb6OmuMeewqiO/HVyqSu4Gj0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PQUrAw83Lg4DvidKRdIuyMrqWrTekbTfEGXOpTj208O5RnGxsLwrlxLEntpEOZwX+ efkUn/99KaE1DydfI/hDaSJhbV+wKSunerrVj7krKx+eoG1pW05EOnulZ5FSvrpnrp js+e/lImz/bWe7OYwLijhrGaAAusJqdDxHcBW8g6TRXg5S0WEvY/i099xenEKlbp5G 99EBT1qyQz0mAIAo0ShCIWJULbq2iRr7tZ8+Svyl3BzxAev0SFOsoi2uLDGMT6jVq4 VrjGZy96hrKR7g+Hawx2vFlM8osMulxn6iQ8Iv/bZc2WotacPOP1wuDvbp/4hpxybj gR7eV9EAQciww== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-09v.sys.comcast.net with SMTP id vTSncxszSjCS0vTSocf2pA; Tue, 04 Apr 2017 18:45:58 +0000 To: perc@ietf.org References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> From: Paul Kyzivat Message-ID: <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> Date: Tue, 4 Apr 2017 14:45:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFwn0IWiTBgNWXj+bUMGbZNlPZt9T7ksdhgKezeVxQGG7qEAsGFR64s+BYPy+jN0ZQdBZQxzn8cOEJAVO6/8aPPfE106Mx/gsw4i19pvLcdSS1k+4VY/ 1gbWxobeCv/wOXRw1aREXw6p9Hb9TRBIo+pxWS9W/qskhvjXij/YNgOT Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:46:01 -0000 On 4/4/17 2:32 PM, Nils Ohlmeier wrote: > >> On Apr 4, 2017, at 08:48, Sergio Garcia Murillo wrote: >> >> >> DTMF is already an exception, anyway, I am fine making DTMF in webrtc non functional with PERC. > > +1 for declaring that DTMF is not going to be supported by PERC. > Especially since the only use case I see would be trying to connect a PERC call with double encryption to something in a legacy network without any encryption at all, which appears like a bad idea to start with. Are you talking about DTMF via RTP (Telephone Events) or DTMF in the signaling channel? DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why would you be singling it out? Whether DTMF is supported with PERC in webrtc is a separate question. It gets tied up in UI, and I can see how it might not be supported. But that is more about webrtc than it is about PERC. Thanks, Paul From nobody Tue Apr 4 11:47:00 2017 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 8DAE61293DF for ; Tue, 4 Apr 2017 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=jive.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 mzsFSN8XC3ot for ; Tue, 4 Apr 2017 11:46:56 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 3B7D1129417 for ; Tue, 4 Apr 2017 11:46:56 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id g195so77891298qke.2 for ; Tue, 04 Apr 2017 11:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XWDDFEqJUh1dKfJc/wcSp7YYcg0wUW3aIL+5cy53ZEw=; b=tsNAxM4KDAExkJCA8eqt2iUJdD2xjVNmj6Ouh+6oocStIorCbvRyMhM+Jg0BE9nrUr 3fayNWAez9xE+Vy7G3D3hReOOjlKGX0kYlWBvWVEJ258kCErj7ZgZldjKoWIWXEQbELC U7eSbiaFPn8TxZr+rjc8A0ZTMVvrIy8PzPc5frtg6HlZFODMC6sCsFizyWjJR7pLbXlE oYoJkVjCiAaPiolbWYGSpXg25Vk9rZRdpR5FVAiXSosaYI7YQPHw327pEmm1j2TsjgGf m8pLlFqUM07B9KK324L/SGy854ZcUiHW5mYhurFNxVbapi6XOsot29lSCMYK3MGn60fO MMqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XWDDFEqJUh1dKfJc/wcSp7YYcg0wUW3aIL+5cy53ZEw=; b=ENyq8eVE4JBJLllnnkxVyxRyeIXHvqe6js2SZlilOWZRZO4wCMkIsNOp+mZZn+taD9 iTRq30JgYxADsylH8uBSFFq0C+O1Z3SQ3dbI3XQyixI2gOAgS3uDQyheAzIst/ou7/92 /IiJ5Pa08z+qDewvNltSNg+PqZCUqdTGlqFbQOqBPt/wyQ6hPSMr8/SsPj6tCeyWX7J/ 8MndrcPjwHHE7XRWssSpkgd5LKBjEO96SWPVQfbGL8TSl/Ahwfj6Nyi++lXWLCitm2vy x9BT/7/Ey623NgOfn6GzpPLFU4KaQO3ettHPmR6eCWCAvtYy0TL1QXaAUS7JyHuwv2vT Svtg== X-Gm-Message-State: AFeK/H1zxL46UZbXYllUSI3XellmWgty7x2RDborL7dzjygfW6vjs2LIsp42HaSq3ZFk2aGlkjGh1+9nDRAFa7XmATvVr4H7nwy7Zg88NbGErAfnI8YOIWnUhYT26zIEY7GEfO5p5rUgouDpnF5SjxhZSH5HaPM608YtZ63Gvms= X-Received: by 10.55.182.193 with SMTP id g184mr9692491qkf.20.1491331615382; Tue, 04 Apr 2017 11:46:55 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:54bd:3e47:33a7:b167]) by smtp.gmail.com with ESMTPSA id v123sm12433564qkh.10.2017.04.04.11.46.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:46:54 -0700 (PDT) To: Sergio Garcia Murillo , Nils Ohlmeier References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <3817a5d4-b570-0fc0-5bb6-31fdc44cbffa@jive.com> Cc: Eric Rescorla , perc@ietf.org From: Simon Perreault Message-ID: <220e5396-7b36-9187-dc10-7fbdb0e93f63@jive.com> Date: Tue, 4 Apr 2017 14:47:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:46:58 -0000 Le 2017-04-04 14:43, Sergio Garcia Murillo a crit : > On 04/04/2017 20:37, Simon Perreault wrote: >> Le 2017-04-04 14:32, Nils Ohlmeier a crit : >>> +1 for declaring that DTMF is not going to be supported by PERC. >> DTMF will work fine. It's just the relay that won't have access to it. >> Endpoints will get DTMF as usual. > > WebRTC only supports sending DTMF not receiving it. Uh? >> Real-world use cases for DTMF in conferences: >> >> - 3-way call where one user is helping another navigate an IVR. >> >> - Dialing out from a conference to a PSTN user and having to enter the >> user's extension number as DTMF. > That won't work as that would be have to be performed on the > conferencing server, which will not have access to the DTMF data if it > is E2E. Uh? You appear to be misinformed. -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Tue Apr 4 11:51:42 2017 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 1712B129497 for ; Tue, 4 Apr 2017 11:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mPpo5GFTozF6 for ; Tue, 4 Apr 2017 11:51:38 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FAE1294A0 for ; Tue, 4 Apr 2017 11:51:37 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id t189so36081054wmt.1 for ; Tue, 04 Apr 2017 11:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=haRS2mjyGzeBUdQhoFUHotq3Lxu8ukbVeoaLbWUn6rk=; b=CX29xNqY6h/uB/AS9jX+Q9jE39aPGqKu/ito5Xmf22ACSrfJq80U8GEORPXgbjHs0s dbHqHN3ji7J/hx/1JFX+B60m4yA3+2zIUFBUZqXrAgmen4zmWMRkASOqpeHF8EkPJDDC 3i7rWWR6V+tTMfwvwKLargppbgPrh3FWW1XNGpuK5f7T+QB2f6hEdrdvImYL5jliz39F NLWp/bwH1Y3fwjEGbUoVyJ78oRCpBmuEt2IZOfhqJoOIU4qNpVRG79TvC6RpJ+rMIfuE ZQZojPcd2NHkHLmYDa+dbsjPY7J9iIC4rjo39ZOKEyF35ajF9uHSE7OByQa8rMmpfb2I E0Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=haRS2mjyGzeBUdQhoFUHotq3Lxu8ukbVeoaLbWUn6rk=; b=HiewG+/qgXs/J/U41v7fpaTmapGrxepwR3d8Ym5kmom3AF4PLn3th9R+V7LPKy0GTy xYI+FoRutfMQo9UkgCcmO3bARbwpHNkPIkfYMhnYa8IM5IJ6JAB5tCNjR+pGTyHMxeOM 1HYVFUf2xPv6DRCjwzLotj6ohE+cuj/gaCRar7srU+onwsLb9SzOKjS0LZ8RvIOhVWKY ZIFdPCZfkDpQUYPHhWiQRAAEsWCFTJP63SjjtHhQEMP/Hcpa9qqleRsT8GpP+N6r1Hdf 3UfB3wHLym4CuwjprSztjS0mU7KCm3PRqr0W+bO/r7MxliO6OjaBwnJQK1D0v2+c+YjW IhOA== X-Gm-Message-State: AFeK/H0JH+dJxUP9pi74gY7NM5GMiHv5TM9R4Z550OfTcUKnfQlipJ7bg7sRTfQde7gmkA== X-Received: by 10.28.20.85 with SMTP id 82mr10693946wmu.59.1491331895547; Tue, 04 Apr 2017 11:51:35 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id v7sm11209807wrd.0.2017.04.04.11.51.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:51:34 -0700 (PDT) To: Simon Perreault , Nils Ohlmeier References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <3817a5d4-b570-0fc0-5bb6-31fdc44cbffa@jive.com> <220e5396-7b36-9187-dc10-7fbdb0e93f63@jive.com> Cc: Eric Rescorla , perc@ietf.org From: Sergio Garcia Murillo Message-ID: <470363ca-c7b5-807c-3a25-835b355052c3@gmail.com> Date: Tue, 4 Apr 2017 20:51:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <220e5396-7b36-9187-dc10-7fbdb0e93f63@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:51:40 -0000 On 04/04/2017 20:47, Simon Perreault wrote: > Le 2017-04-04 14:43, Sergio Garcia Murillo a crit : >> On 04/04/2017 20:37, Simon Perreault wrote: >>> Le 2017-04-04 14:32, Nils Ohlmeier a crit : >>>> +1 for declaring that DTMF is not going to be supported by PERC. >>> DTMF will work fine. It's just the relay that won't have access to it. >>> Endpoints will get DTMF as usual. >> WebRTC only supports sending DTMF not receiving it. > Uh? https://tools.ietf.org/html/rfc7874 WebRTC only mandates sending DTMF, please check where it says anything about receiving it. Also, please, point me out which w3c apis are available to receive those events: https://www.w3.org/TR/webrtc/#peer-to-peer-dtmf >>> Real-world use cases for DTMF in conferences: >>> >>> - 3-way call where one user is helping another navigate an IVR. >>> >>> - Dialing out from a conference to a PSTN user and having to enter the >>> user's extension number as DTMF. >> That won't work as that would be have to be performed on the >> conferencing server, which will not have access to the DTMF data if it >> is E2E. > Uh? > > You appear to be misinformed. Could you be more precise in which part I am misinformed? Best regards Sergio From nobody Tue Apr 4 11:56:20 2017 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 637C112949E for ; Tue, 4 Apr 2017 11:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgSrKwyfWzm6 for ; Tue, 4 Apr 2017 11:56:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A721294A2 for ; Tue, 4 Apr 2017 11:56:06 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v34IttQl055130 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Apr 2017 13:55:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Paul Kyzivat , perc@ietf.org References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> From: Adam Roach Message-ID: <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> Date: Tue, 4 Apr 2017 13:55:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 18:56:19 -0000 [as individual] On 4/4/17 13:45, Paul Kyzivat wrote: > DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so > why would you be singling it out? Yes. This is the right answer. /a From nobody Tue Apr 4 12:03:47 2017 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 DDB6212949E for ; Tue, 4 Apr 2017 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 Ovap-82xfrqx for ; Tue, 4 Apr 2017 12:03:44 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 50DD4129476 for ; Tue, 4 Apr 2017 11:53:48 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t189so36126902wmt.1 for ; Tue, 04 Apr 2017 11:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=IDtbXNkvwJ+S00bGyxbDWl9QMJSSTRWLhO+77BUI4wA=; b=EVZfPb6+C1Qzv4X0N8pAaMQ60a1aR7TnRolW1NLhsUYwVv96tmDnjRHa3V3YN94LIY ip/kgXT1/O4VOTzmrosifSX1IO2PHrKi9md9nAVLdt52AbkQfadLAEMtHgV40aWCsKIe vKuAN6JNYJS2dXSNTXkD7hyt9b7Vxubx7PKMNbcXizPMYRJlTz9DXXvAosMjBDnkT8eB FTTcFL8f3F0Ah/Lcy9eZ/m63vj1McF4mCRwQOnTg8np8qOZU9UkvZaD1obSNO10IlptF EYtIXmsA120g76e+djNPYVbmtKJI0iIxuUZ75JxIXaGBFWmveUMoCJJfAokFLAfBoKlt wB6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IDtbXNkvwJ+S00bGyxbDWl9QMJSSTRWLhO+77BUI4wA=; b=bvU7h0bjMsovF/DpNMM1PXZ0xg+OD/XFdrVauCxBwTO7mqMzvxmRIfdre0cpt00tot R6bqPejcXCCJqZjMXW49D7i0fBuB2oqqpb4DQN89G91t+xY+tUOCq15B+e1pKfzS8Xga 1bglBfELSwx5pdJc2rWOOKy3lT+WuilYgzFfZY2mzqjPx9wDnQm+2MTaV7LgfqL57Q4k uq436ynigLvTBO3sCtD2FdZNLrA/LzxBlYag5RB5O/DzWN5pciKXJz3c/dZVoDR168ud zgXaB7sonX+qVq+IGXINdai+eQdTsVsZxqjV0Y/2hbN81HTgu7Ko9Xz/5pYblwLidUKM oZVA== X-Gm-Message-State: AFeK/H3KVHn8BqrfPivrhyF611juqu3/9C5CoxbQ9Z1eNHzBrVpK4E5l jbNge6nItFslceo8AE0= X-Received: by 10.28.64.131 with SMTP id n125mr14959137wma.78.1491332026643; Tue, 04 Apr 2017 11:53:46 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id 191sm19500031wmv.25.2017.04.04.11.53.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 11:53:45 -0700 (PDT) To: perc@ietf.org References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> From: Sergio Garcia Murillo Message-ID: <5369ed64-12c1-88d2-66dc-93d6cd9bee2e@gmail.com> Date: Tue, 4 Apr 2017 20:53:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:03:46 -0000 On 04/04/2017 20:45, Paul Kyzivat wrote: > On 4/4/17 2:32 PM, Nils Ohlmeier wrote: >> >>> On Apr 4, 2017, at 08:48, Sergio Garcia Murillo >>> wrote: >>> >>> DTMF is already an exception, anyway, I am fine making DTMF in >>> webrtc non functional with PERC. >> >> +1 for declaring that DTMF is not going to be supported by PERC. >> Especially since the only use case I see would be trying to connect a >> PERC call with double encryption to something in a legacy network >> without any encryption at all, which appears like a bad idea to start >> with. > > Are you talking about DTMF via RTP (Telephone Events) or DTMF in the > signaling channel? telephone-events > DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so > why would you be singling it out? PERC, at least double should not be codec agnostic, at least to be able to do RTX/FEC/RED/Flex-FEC HBH. The question is if DTMF should be HBH or E2E, and in a conferencing environment I see no use of E2E DTMF at all. Please correct me if you see it otherwise. Regards Sergio From nobody Tue Apr 4 12:11:52 2017 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 515DA1205D3 for ; Tue, 4 Apr 2017 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 xvzUoqUT_Nam for ; Tue, 4 Apr 2017 12:11:48 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 89EA2128DF3 for ; Tue, 4 Apr 2017 12:11:48 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id x124so36619843wmf.0 for ; Tue, 04 Apr 2017 12:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MiXtNyUxytqUO0bIJ9GfdYLr8eNgVOSFEt+PNZR42eo=; b=hPIa/rM/Kr3wmq5axYVlLeRMwzxKNf7vBrd7cSyvm6aPNchjDhkak2aJVcJqQxbieX 7MdP3AbgOMYsSxtrPTNHwnpTVgRew7FKdGAvKSqW/AL7f+pnuarm4V2Ye6RhJrmZUXw7 BOnwzlvXXhmOIivYsHkHbBDz1B873p4mydUP+yfCBK1jmr7Qj9fu0l29/v7+wsVzBxeH Nl6VYTspXBDuaYZG7CKH+AXX63y680wxTYMZZACfRqZIqUSHcRuaTV4KEfudSK7OPjHz tcu6M8VULbifDDWyD9e9ZR3+6Z+UNktC3K459nNTzci4fncoftcgQ4QzcnFtstENRbGN d3lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MiXtNyUxytqUO0bIJ9GfdYLr8eNgVOSFEt+PNZR42eo=; b=tOPbdLwz864raDohcNPwTcVBygoZWSGZNqpMN2TYrbp35VGxsQW8ppQ+opSlJ2rUq4 ma+oyvv94//D3PCkqwA/YV0lXDc7ZhYREdWcCenkSp/opGHShuaaNVDpOjjCUrmzw3Cg 7uegTfgVdxdY58rxeXLnVE1jJSWz4VWhFluyFFe0mh3Teo6Daf9E0A1DXizF70ls1Agh GsuYMuakRbqNJVJ4WpNcrR3N1CZAK2rAP3VgC0CLeEjSjWgrHoZgeeLZeKzK8W4wn2A4 Z8580P5C1PcWeIGIWmlSuXKXCEaSSHs9DBTUqb+XuNib0H0R4gLeGQhGS8OsHGws/9qX vBVg== X-Gm-Message-State: AFeK/H1uBcisDqJen4A62pDE4NoA80MVga46z/cw6rIs8S4xBcRFBnHU2O//BVOmsy79vFMCQ6r1jRDuUn/8xg== X-Received: by 10.28.111.3 with SMTP id k3mr16333045wmc.39.1491333107028; Tue, 04 Apr 2017 12:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.179.70 with HTTP; Tue, 4 Apr 2017 12:11:45 -0700 (PDT) Received: by 10.28.179.70 with HTTP; Tue, 4 Apr 2017 12:11:45 -0700 (PDT) In-Reply-To: <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> From: Sergio Garcia Murillo Date: Tue, 4 Apr 2017 21:11:45 +0200 Message-ID: To: Adam Roach Cc: perc@ietf.org, Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1147cae41619ab054c5c0c6b Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:11:50 -0000 --001a1147cae41619ab054c5c0c6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 4/4/2017 20:56, "Adam Roach" escribi=C3=B3: [as individual] On 4/4/17 13:45, Paul Kyzivat wrote: > DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so wh= y > would you be singling it out? > Yes. This is the right answer Have to disagree. I think one of the key questions in PERC is to define what makes sense in conferencing environment to be HBH and what E2E. And an SFU developer, IMO the following ones only make sense to be HBH: -RTP header extensions -RTX -RED -FEC -Flex FEC -DTMF Pretending to make PERC agnostic and just tunnel everything E2E is not going to work. Best regards Sergio --001a1147cae41619ab054c5c0c6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 4/4/2017 20:56, "Adam Roach" <adam@nostrum.com> escribi=C3=B3:
[as individual]


On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why = would you be singling it out?


Yes. This is the right answer

Have to disagree. I th= ink one of the key questions in PERC is to define what makes sense in confe= rencing environment to be HBH and what E2E.

And an SFU developer, IMO the following ones only make = sense to be HBH:

-RTP head= er extensions
-RTX
-RED
=
-FEC=C2=A0
-Flex FEC
-DTMF

Pretendi= ng to make PERC agnostic and just tunnel everything E2E is not going to wor= k.

Best regards
Sergio

--001a1147cae41619ab054c5c0c6b-- From nobody Tue Apr 4 12:30:38 2017 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 54AD11205D3 for ; Tue, 4 Apr 2017 12:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 AwM5m2PCN26t for ; Tue, 4 Apr 2017 12:30:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 94964127275 for ; Tue, 4 Apr 2017 12:30:35 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with SMTP id vU9ncNRNrAfZsvU9ycPmoS; Tue, 04 Apr 2017 19:30:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1491334234; bh=vnqwbUXTH9wLAeC7QIsFwOZ5kxqGoqLPV1slPcq3bMw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MYpDSS/FgWPLTSztng3edGvx+suoDWzRf1NPCHN5LmiIh7O3ATavidKzhR3ueu3+F 8BE2y9w1x/m0o6W4/XNrmSx4Rhkj5Bk408bdO2RRI4Tdgpf073syIiULiK9h1PfIYk HuJiAMjRbuaEEl/wQrfhFYoYbYF9+s/fXAz6eV143bhTYTB+2WGr0CyT/WMeVdqZhK eDK5ToXKH4RPlU5fdVmi1sZifD1y+nAFsg6dMRYA6ihmKYJVgDtoFPUjwqgV9/8ZSR bNe7aNVH9l4fzM682uDrTSNetGOoAYrMYCNhdSvzS8kQOnSty4RcJF6RlXnjeayxJs 9eW/O3dJ4PAbQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-07v.sys.comcast.net with SMTP id vU9xcHRUSt1ZsvU9yclahP; Tue, 04 Apr 2017 19:30:34 +0000 To: perc@ietf.org References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <5369ed64-12c1-88d2-66dc-93d6cd9bee2e@gmail.com> From: Paul Kyzivat Message-ID: Date: Tue, 4 Apr 2017 15:30:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5369ed64-12c1-88d2-66dc-93d6cd9bee2e@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNOUcdqCOaSasXzAoM62CfO5f58fvn355Avao4arg8wloNmj+79Rb0g7eBwU4K3biWEMTkll28Xs5peaa2aIVM0gEDUEgHp6ozqw00+GvHjppEEfY4oX EVB2CJ8o7P3Ku8jLcgnV10D+Su9iMhADRdSlxAWw5Qfwz3QTmDWPbhsv Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:30:37 -0000 On 4/4/17 2:53 PM, Sergio Garcia Murillo wrote: > On 04/04/2017 20:45, Paul Kyzivat wrote: >> On 4/4/17 2:32 PM, Nils Ohlmeier wrote: >>> >>>> On Apr 4, 2017, at 08:48, Sergio Garcia Murillo >>>> wrote: >>>> >>>> DTMF is already an exception, anyway, I am fine making DTMF in >>>> webrtc non functional with PERC. >>> >>> +1 for declaring that DTMF is not going to be supported by PERC. >>> Especially since the only use case I see would be trying to connect a >>> PERC call with double encryption to something in a legacy network >>> without any encryption at all, which appears like a bad idea to start >>> with. >> >> Are you talking about DTMF via RTP (Telephone Events) or DTMF in the >> signaling channel? > telephone-events >> DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so >> why would you be singling it out? > > PERC, at least double should not be codec agnostic, at least to be able > to do RTX/FEC/RED/Flex-FEC HBH. These are "special" - not really codecs, and so may well require some special handling. > The question is if DTMF should be HBH or E2E, and in a conferencing > environment I see no use of E2E DTMF at all. Please correct me if you > see it otherwise. IMO DTMF is a "normal" codec, like G711, and ought to be treated the same. Hence the conferencing equipment won't have access to it unless also acting as an endpoint. That does seem to exclude using it for controlling the properties of the conference. Whether the participants in the conference can use received DTMF in any meaningful way is a separate question. Often they won't, and that may be the case for webrtc participants. But as somebody mentioned, one of the participants might be an IVR that *could* make use of it. Thanks, Paul From nobody Tue Apr 4 12:44:16 2017 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 06B3B1294D4 for ; Tue, 4 Apr 2017 12:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-sXLwf8JZeQ for ; Tue, 4 Apr 2017 12:44:10 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 82F771294D2 for ; Tue, 4 Apr 2017 12:44:06 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id x125so161898435pgb.0 for ; Tue, 04 Apr 2017 12:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p6rnxNusyJ74fs5IGPRZZIKSemV/P9+ZK8ATkoZrQWM=; b=aoqIchFzMsNXqaicwOMLwEjP9Qw61TWNOyRd1sHm9PBeMpIiXh/ZvJdJKagI6DFL2Z ysnbwJ+Jt1MXY3xXsV2D6xGpJH34mxXj0epPu3XpGeyeDey6brQFNWV4HuiiOt8bqkoV +/Oq3Pg9TRHfAEAAPIDIeve9fiBae/wf/3T7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p6rnxNusyJ74fs5IGPRZZIKSemV/P9+ZK8ATkoZrQWM=; b=DI16c3UiSup31+v/V3ffI1v+EFZsG/cXDdlrE+i2G+fL836JTMQuHE6VSpoGJfoyiR Fs2n+JMyGPImboUnA8Pv08ur9C1vKFuaQFeIdORL/8ZwRNSGLpbh0yv336wt9fzKi7OP KzosbJVZmGE9Ki8mZQV9otIWlXtay2hYv4/pzWHyF1S++qHz35GS0dR6F3nvEyjovD52 RWN7OJid32cMSSc3PDvQuLOf2hlzH7mAG8EwK4D3GU8hcBZWecFWPFAhCGwwUwkYflil 4Szzx+sXPd4cPSy3MEzR/sGDOmF5i4UgWyskTtcDT4kpq55k9HMVqIdjsgdEpeHZYRtG ecYg== X-Gm-Message-State: AFeK/H3ebgJQbKrySoQ7sAReWi5Qc1wstHaEQ+wHCkHPVzqpMtq8JDPo/S5qNvWF1n0NfoPP X-Received: by 10.99.5.133 with SMTP id 127mr25542659pgf.8.1491335046050; Tue, 04 Apr 2017 12:44:06 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:808e:d80f:e0c3:7474? ([2620:101:80fc:224:808e:d80f:e0c3:7474]) by smtp.gmail.com with ESMTPSA id h25sm33247821pfk.119.2017.04.04.12.44.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 12:44:04 -0700 (PDT) From: Nils Ohlmeier Message-Id: <292B9B66-998C-4F8D-8DD2-892E32AEA7C3@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_64583769-CA52-409F-9D3F-B2D6DCEF3FA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 4 Apr 2017 12:43:59 -0700 In-Reply-To: Cc: perc@ietf.org To: Paul Kyzivat References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <5369ed64-12c1-88d2-66dc-93d6cd9bee2e@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:44:14 -0000 --Apple-Mail=_64583769-CA52-409F-9D3F-B2D6DCEF3FA8 Content-Type: multipart/alternative; boundary="Apple-Mail=_31B2447F-8872-4A34-8CFA-041B3C248C07" --Apple-Mail=_31B2447F-8872-4A34-8CFA-041B3C248C07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 4, 2017, at 12:30, Paul Kyzivat = wrote: >=20 >> The question is if DTMF should be HBH or E2E, and in a conferencing >> environment I see no use of E2E DTMF at all. Please correct me if you >> see it otherwise. >=20 > IMO DTMF is a "normal" codec, like G711, and ought to be treated the = same. I=E2=80=99m not sure I would call DTMF =E2=80=9Cnormal=E2=80=9D, but = that is splitting hairs. > Hence the conferencing equipment won't have access to it unless also = acting as an endpoint. That does seem to exclude using it for = controlling the properties of the conference. >=20 > Whether the participants in the conference can use received DTMF in = any meaningful way is a separate question. Often they won't, and that = may be the case for webrtc participants. But as somebody mentioned, one = of the participants might be an IVR that *could* make use of it. I agree. What I meant to say earlier, apology for not being more precise, was = that I would be opposed to put in extra effort to make DTMF work in a = HBH way towards the MD. If endpoints want to utilize DTMF E2E that is up = to them. I guess what is going to be challenging is to get something like DTMF = negotiated E2E. But that is somewhat different topic. Best Nils --Apple-Mail=_31B2447F-8872-4A34-8CFA-041B3C248C07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 4, 2017, at 12:30, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:

The question is if DTMF should be HBH or E2E, and in a = conferencing
environment I see no use of E2E DTMF at all. = Please correct me if you
see it otherwise.

IMO DTMF is a = "normal" codec, like G711, and ought to be treated the same.

I=E2=80=99m not = sure I would call DTMF =E2=80=9Cnormal=E2=80=9D, but that is splitting = hairs.

Hence the conferencing equipment won't = have access to it unless also acting as an endpoint. That does seem to = exclude using it for controlling the properties of the = conference.

Whether the = participants in the conference can use received DTMF in any meaningful = way is a separate question. Often they won't, and that may be the case = for webrtc participants. But as somebody mentioned, one of the = participants might be an IVR that *could* make use of it.

I = agree.

What I = meant to say earlier, apology for not being more precise, was that I = would be opposed to put in extra effort to make DTMF work in a HBH way = towards the MD. If endpoints want to utilize DTMF E2E that is up to = them.
I guess what is going to be challenging is to = get something like DTMF negotiated E2E. But that is somewhat different = topic.

Best
  Nils
= --Apple-Mail=_31B2447F-8872-4A34-8CFA-041B3C248C07-- --Apple-Mail=_64583769-CA52-409F-9D3F-B2D6DCEF3FA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY4/eAAAoJEJ3NnGfOORkkxb0P/jEEMF8YfTYCqOlUIocBEX6+ Hk1/5F+v+JurlaQSLFF4CIeqri7v2jlM5fyfDE9CdHVaCPqsWCbSBg21NooLYutH R1Zodb7MIBH3ai3BQei/TMSE5hnyOEyf+/ub63SlwLSQGWuCstNSZ0MPeZ2PL+OJ koqiJIm0cul84cNsTlhbqfesINi1mPNX2HAq7bbIUot50G5U1LLwpNhp5dnPr+Oe V67kTS6oetL72IDTNyowFb9iUYNVmqOUfKDDbxsAAtIeGZKkwQ+l9OlIYAMqjlbB 1BwexemPlHlSRwtDDGewNP/sT69bhcoTCz8Fz15WQRUiqvtNGluAihRUsxX5KZ6B a0Y8oXpPG+hJCig+/FghhtF3vwkQY6KOCe9IZ+IX5GaLY5/NGJacBaCIkdu20V4U 3qkuvi6OBFCUgl0p2pfTg048YcUIU7B90WZejqatShQNWkYW5d/jdOt8IllXPSZP U+pLvVnzAj0MYJadoOdBX4qdcvShfAKu3uG7CNSX11PaE39pqQYna4tr9IVH3fSw h0n/mpvBEReNzzHw8PUNzcTUyHP4mZ+g5nIE8duFRYbb2+0QgQPumE2hGskYft4U YjDmh6hknAX8WhjWrIg3qE1zxWJ6zWIBhbzrzf1MDt1RoFZe20JHr3tkaq+G2duW b8+/sFC6UMFk9f38MeBD =uNA2 -----END PGP SIGNATURE----- --Apple-Mail=_64583769-CA52-409F-9D3F-B2D6DCEF3FA8-- From nobody Tue Apr 4 13:03:01 2017 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 EF5401294D2 for ; Tue, 4 Apr 2017 13:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 DTZNSyHlyCDw for ; Tue, 4 Apr 2017 13:02:59 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 049421294E4 for ; Tue, 4 Apr 2017 13:02:51 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id w43so222050085wrb.0 for ; Tue, 04 Apr 2017 13:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=kIfSNdbH7vn6vwSH9WzOuoq5JtlKPOoogRpT0iJwTmw=; b=THMOaz6BGc5a6Y1KrzwbNvEgsOu/I8X6LaasAF5UUDl1nAYY0V87hkgxc0WKKvH3sh u8GUaw5z4ieO/nF2euZUBLDIwb7wJl4NT8hZtw5eVjTXABtcrSofKWaakxxSseNZkd/C lh2+P+DnE0sjMFFBAg7zP8cJD2deXH53gGrQj6kj/3jiEEn0oet/1K5Lu6eipZrc6UTW /DScExoV2ZGkyj0V5xGYCGIaYwLwpZ+50arcSTWzXxkNLtdpQBqkx6bVAzjHNmsleU0u E/bpdh4qAQ6jiQXRxCndfIQ1Ko1VEvNkf/R15N51wSbI65XkKU8+EQGRfa6d2sbj6t7L xo7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=kIfSNdbH7vn6vwSH9WzOuoq5JtlKPOoogRpT0iJwTmw=; b=CrJubIMX74SY3JtP0ovfp3sCsISK4UXPXaIPdA1ZE29NfciRWA15478yjrVCSTQPPr k3uS+5vxs6ucBaCEcVYU3Dcfq+nA+gGpAdx1llmXx2RmWLHAnflvijR42EBI8Yqv2f4N 0rFz5Leb0plP7JPJPvui7w46RnTp2U1fTIC5bhD4dAy7GMTWR/xsaGnhpEaGyyI1Mw7P x9+jsgb8LLNUykxVvMJI3fCqR+JQsjCW1PogK2BipblaFFGPfL2o0edc7Pu+66HLn249 dyXE2XzQ4/twTJGNzpQB+dVMcdzpfo5C+WXWXJrAUEd1ujhE+RWmeXbtDuxd5xOCd5Q+ 0lvQ== X-Gm-Message-State: AFeK/H3zGdd4A3i1I8xOhkkTmUjZY2zQKHVaV7JByv3kjxobuSsnGdCOR0RMpoMmd0yn+w== X-Received: by 10.223.183.29 with SMTP id l29mr23345605wre.42.1491336169291; Tue, 04 Apr 2017 13:02:49 -0700 (PDT) Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id 18sm23552433wrt.52.2017.04.04.13.02.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 13:02:48 -0700 (PDT) To: perc@ietf.org References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <5369ed64-12c1-88d2-66dc-93d6cd9bee2e@gmail.com> <292B9B66-998C-4F8D-8DD2-892E32AEA7C3@mozilla.com> From: Sergio Garcia Murillo Message-ID: <21367380-79ee-bd61-efba-b1280d8dc7d6@gmail.com> Date: Tue, 4 Apr 2017 22:02:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <292B9B66-998C-4F8D-8DD2-892E32AEA7C3@mozilla.com> Content-Type: multipart/alternative; boundary="------------F088747BC768B4BF1310D4B8" Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:03:00 -0000 This is a multi-part message in MIME format. --------------F088747BC768B4BF1310D4B8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/04/2017 21:43, Nils Ohlmeier wrote: > >> On Apr 4, 2017, at 12:30, Paul Kyzivat > > wrote: >> > >> Hence the conferencing equipment won't have access to it unless also >> acting as an endpoint. That does seem to exclude using it for >> controlling the properties of the conference. >> >> Whether the participants in the conference can use received DTMF in >> any meaningful way is a separate question. Often they won't, and that >> may be the case for webrtc participants. But as somebody mentioned, >> one of the participants might be an IVR that *could* make use of it. > > I agree. > > What I meant to say earlier, apology for not being more precise, was > that I would be opposed to put in extra effort to make DTMF work in a > HBH way towards the MD. If endpoints want to utilize DTMF E2E that is > up to them. > I guess what is going to be challenging is to get something like DTMF > negotiated E2E. But that is somewhat different topic. I agree also, I raised the question because when implementing double in libwertc it was more complex to get DTMF as E2E than keeping it HBH as the code to handle the audio media and telephone-events are in different places. Regards Sergio --------------F088747BC768B4BF1310D4B8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 04/04/2017 21:43, Nils Ohlmeier wrote:

On Apr 4, 2017, at 12:30, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:


Hence the conferencing equipment won't have access to it unless also acting as an endpoint. That does seem to exclude using it for controlling the properties of the conference.

Whether the participants in the conference can use received DTMF in any meaningful way is a separate question. Often they won't, and that may be the case for webrtc participants. But as somebody mentioned, one of the participants might be an IVR that *could* make use of it.

I agree.

What I meant to say earlier, apology for not being more precise, was that I would be opposed to put in extra effort to make DTMF work in a HBH way towards the MD. If endpoints want to utilize DTMF E2E that is up to them.
I guess what is going to be challenging is to get something like DTMF negotiated E2E. But that is somewhat different topic.

I agree also, I raised the question because when implementing double in libwertc it was more complex to get DTMF as E2E than keeping it HBH as the code to handle the audio media and telephone-events are in different places.

Regards
Sergio


--------------F088747BC768B4BF1310D4B8-- From nobody Wed Apr 5 07:26:08 2017 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 EE673129437 for ; Wed, 5 Apr 2017 07:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IGFWRg6eKCRj for ; Wed, 5 Apr 2017 07:26:03 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4A4129446 for ; Wed, 5 Apr 2017 07:26:00 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z13so10639702iof.2 for ; Wed, 05 Apr 2017 07:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=okLJwyLvU4fIpOk3kt5i/miyXOoeiqoX3QdCPmnYgFc=; b=IGrRNZQWGq8g8pjL9RzW5PDazOTQIF4ccvRjA1CubBkGdneqxPUBOC/WaXcV87jPy7 zuxGAHXLZcwSqmYM8BvQOeHw06bgDB0Fxc/1bFzrrvC6un9WDfaKXREspptTsrM+cMDw cf5cddwEmtoORc2dn1gdn7lCPS45qSr3FCEi4tfxiSItxLAczkCPaqv24hQwOw+6VWqU KuD7vhs7YAxBndnD0rP5hedyzHVtx1JhCDCF4bAr2XVOEYB8J/UGt136ZiNaMZCUAjwZ Dr2MZTl2tbt7eoVYbmj7M/7dFqjr/TTmyAffA840/nOL1eDOPqJzYZ/6Rg9YX0RBnOa9 G7ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=okLJwyLvU4fIpOk3kt5i/miyXOoeiqoX3QdCPmnYgFc=; b=pIRR/g7p3rmjXIT6BdyRJlyH0wDRfTbZm+1gpOxKp8AuzaGsMA8p/wTBfVmi2exyID PLN3P7ey1aI+QRmI2FqwkemZvAQCNFs94cjWA2WEhFAgB9Pfz3Y4egLqVFLz1T8VaSIh biLfEtorS61MR1ZRDQmScL6qbtDy/2e2N0aYXsLs8RMRGmRdMuFWKM6BIde/gPg0+rWJ YzVweaqnIEG0nxpDj60GDJWu/UAA82xeNGKCwnyrwdrea0n7lRJMgiFm/XV0BvWPs8G/ d7VlYvur7AJ4+toPYuIZP5bSl73yec4anMQreMqIl5hAg2TI8rhh/1Hw/wU0mGEUm1+c ikmw== X-Gm-Message-State: AFeK/H2UVuRTdGRQAwnWgaVZouAPWlhfBkLbp47DYeq8v+ZYMy8v4+jhY2oi+abDlPOPSKY0gekageIQZuVXJA== X-Received: by 10.157.41.36 with SMTP id d33mr15149542otb.24.1491402359503; Wed, 05 Apr 2017 07:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Wed, 5 Apr 2017 07:25:58 -0700 (PDT) In-Reply-To: <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> From: Stephen Botzko Date: Wed, 5 Apr 2017 10:25:58 -0400 Message-ID: To: Adam Roach Cc: Paul Kyzivat , perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c04faa2db0202054c6c2ba8 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:26:06 -0000 --94eb2c04faa2db0202054c6c2ba8 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: > [as individual] > > On 4/4/17 13:45, Paul Kyzivat wrote: > >> DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so >> why would you be singling it out? >> > > > Yes. This is the right answer. > > /a > > [SB] The point here was that DTMF over RTP secured with double can *only* be used end-to-end *unless* you treat it as a special case. Choosing to treat it as "any other codec" means the MD cannot use DTMF to extend conference functions that it might have. Most traditional MCUs do use DTMF to extend conference controls. Personally I don't see that as a problem for PERC, and potentially allowing an actor w/o the e2e key access to control conference functions is a bad idea. There are two other unusual cases I know of - Far End Camera Control over RTP (RFC 4573) and Text over RTP (RFC 4103) At first glance RFC 4573 appears to work with double and PERC generally for it's intended use of camera control. There is at least one MCU that uses RFC 4573 for conference control, and that particular use won't work for MDs. That's not a problem for me. I believe RFC 4103 also works. There is information leakage in the packet lengths unless some form of padding is provided, and the use of marker bits also leaks some information. RFC 4103 is old, and it's security considerations doesn't mention either of these. RFC 6562 could apply, but it's scope is limited specifically to VBR audio, and RFC 4103 is not that. Stopping those leaks is not a PERC issue of course, but might be something that AVT should clean up. Paul K and Paul J - In a conference where accessibility is needed, does there need to be some way for the MD to manage distribution of text? I don't believe PERC provides that, and it might be hard to do. [/SB] --94eb2c04faa2db0202054c6c2ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:
[as indivi= dual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why = would you be singling it out?


Yes. This is the right answer.

/a


[SB] The point here was that DTMF= over RTP secured with double can only be used end-to-end = unless you treat it as a special case.=C2=A0 Choosing to treat i= t as "any other codec" means the MD cannot use DTMF to extend con= ference functions that it might have.=C2=A0 Most traditional MCUs do use DT= MF to extend conference controls.=C2=A0 Personally I don't see that as = a problem for PERC, and potentially allowing an actor w/o the e2e key acces= s to control conference functions is a bad idea.=C2=A0

=

There are two other unusual cases I know of - Far End C= amera Control over RTP (RFC 4573) and Text over RTP (RFC 4103)
At first glance RFC 4573 appears to work with double and PERC = generally for it's intended use of camera control.=C2=A0 There is at le= ast one MCU that uses RFC 4573 for conference control, and that particular = use won't work for MDs.=C2=A0 That's not a problem for me.

I believe RFC 4103 also works.=C2=A0 There is information = leakage in the packet lengths unless some form of padding is provided, and = the use of marker bits also leaks some information.=C2=A0 RFC 4103 is old, = and it's security considerations doesn't mention either of these.= =C2=A0 RFC 6562 could apply, but it's scope is limited specifically to = VBR audio, and RFC 4103 is not that.=C2=A0 Stopping those leaks is not a PE= RC issue of course, but might be something that AVT should clean up.
<= div>

Paul K and Paul J - =C2=A0In a conference= where accessibility is needed, does there need to be some way for the MD t= o manage distribution of text?=C2=A0 I don't believe PERC provides that= , and it might be hard to do. [/SB]


--94eb2c04faa2db0202054c6c2ba8-- From nobody Wed Apr 5 07:35:27 2017 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 139D512869B for ; Wed, 5 Apr 2017 07:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 B0QF72HJ67sa for ; Wed, 5 Apr 2017 07:35:24 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C27C129420 for ; Wed, 5 Apr 2017 07:35:22 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id f193so17368447oib.2 for ; Wed, 05 Apr 2017 07:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a2ZWtT3wWnzqM4W4Zzhw8yOdtSXC+5djhqbbwPHWD4k=; b=Qgz+ojngdpM0LmrrLtPMVsiIOv9ZIXABnbUm7CsKvLZHs5RhyJFYRTbMl5U1eKgCcG 1PK1t6Q+mQKc4LzQYT4VqIVPmP7sWYhcVLWF5s8jWl6uKQT4XK9yixH3Z1DOku8ZOyLY tzKISyTt5vTLOWG35iYvcV/JQSI00FsGhOW6yEMyBucc9K0Nf/YUky2/wWpN8kMgqQc4 EKkOoeJUEsm5MEonnzeB2fNkX19SFHvJ57dKqgvp0gWjwP6GuxoG2ZrA7JM29gYHE54M T9KDhCVDVd1svKiAUKhS3WBKZUrZv/QK1dcdJFgD/Un1t9xGVJFftdxCmyI8ohTz7EeI n7fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a2ZWtT3wWnzqM4W4Zzhw8yOdtSXC+5djhqbbwPHWD4k=; b=kK88svwNzuS9ekdsA9lbsa03z35In0qHRB5Iyb75plgsCSbP1KeDG1PfMbzsIMhgcI jNc9ac0fO6QJjtw5Ytlt/sh4YJVqy5IJ38BszGSbkD1cuIYFKgIHZkfSvgITU3OkALxK uVlrEAFmW8I6DJIu7Blk4kH+EsQ3if5jmVDhXVRMjlUQW4OBrzCPNzUKorf0uKfFiA5l io9gluAbgJCboxCGmDRRazFJ6v3rxe+8/v6xqKCf7QSk/eohRytFqlcz8jpYOdtXmR+o M0zoe+VnommqGofYAlqx4lCW9vI6jC8KNiCdWUwOUcIunSO1uXi1TBestP+Lj7fQxWiu nfMA== X-Gm-Message-State: AFeK/H2c9arBilZ2qgziYJtOPct/jIcG0IwfQ94MqRNET2+nOAwW3RkYEQN54/Jwj4bwTZWIZl2fyJ/ns6f0tA== X-Received: by 10.202.81.83 with SMTP id f80mr4916584oib.23.1491402921258; Wed, 05 Apr 2017 07:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Wed, 5 Apr 2017 07:35:20 -0700 (PDT) In-Reply-To: References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> From: Stephen Botzko Date: Wed, 5 Apr 2017 10:35:20 -0400 Message-ID: To: Adam Roach Cc: Paul Kyzivat , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113b06c456c105054c6c4d87 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:35:26 -0000 --001a113b06c456c105054c6c4d87 Content-Type: text/plain; charset=UTF-8 >>>*potentially allowing an actor w/o the e2e key access to control conference functions is a bad idea.* We might have this issue already, since SRTCP is h2h. That needs to be added to the security considerations. Stephen On Wed, Apr 5, 2017 at 10:25 AM, Stephen Botzko wrote: > > > On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: > >> [as individual] >> >> On 4/4/17 13:45, Paul Kyzivat wrote: >> >>> DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so >>> why would you be singling it out? >>> >> >> >> Yes. This is the right answer. >> >> /a >> >> > [SB] The point here was that DTMF over RTP secured with double can *only* > be used end-to-end *unless* you treat it as a special case. Choosing to > treat it as "any other codec" means the MD cannot use DTMF to extend > conference functions that it might have. Most traditional MCUs do use DTMF > to extend conference controls. Personally I don't see that as a problem > for PERC, and potentially allowing an actor w/o the e2e key access to > control conference functions is a bad idea. > > > There are two other unusual cases I know of - Far End Camera Control over > RTP (RFC 4573) and Text over RTP (RFC 4103) > > At first glance RFC 4573 appears to work with double and PERC generally > for it's intended use of camera control. There is at least one MCU that > uses RFC 4573 for conference control, and that particular use won't work > for MDs. That's not a problem for me. > > I believe RFC 4103 also works. There is information leakage in the packet > lengths unless some form of padding is provided, and the use of marker bits > also leaks some information. RFC 4103 is old, and it's security > considerations doesn't mention either of these. RFC 6562 could apply, but > it's scope is limited specifically to VBR audio, and RFC 4103 is not that. > Stopping those leaks is not a PERC issue of course, but might be something > that AVT should clean up. > > > Paul K and Paul J - In a conference where accessibility is needed, does > there need to be some way for the MD to manage distribution of text? I > don't believe PERC provides that, and it might be hard to do. [/SB] > > > --001a113b06c456c105054c6c4d87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>>potentiall= y allowing an actor w/o the e2e key access to control conference functions = is a bad idea.
We might hav= e this issue already, since SRTCP is h2h.=C2=A0 That needs to be added to t= he security considerations.

Stephen

On Wed, = Apr 5, 2017 at 10:25 AM, Stephen Botzko <stephen.botzko@gmail.com> wrote:

On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:
[as individ= ual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why = would you be singling it out?


Yes. This is the right answer.

/a


=
[SB] The point here was that DTMF over RTP secured with d= ouble can only be used end-to-end unless you tr= eat it as a special case.=C2=A0 Choosing to treat it as "any other cod= ec" means the MD cannot use DTMF to extend conference functions that i= t might have.=C2=A0 Most traditional MCUs do use DTMF to extend conference = controls.=C2=A0 Personally I don't see that as a problem for PERC, and = potentially allowing an actor w/o the e2e key access to control conference = functions is a bad idea.=C2=A0


Ther= e are two other unusual cases I know of - Far End Camera Control over RTP (= RFC 4573) and Text over RTP (RFC 4103)

At first gl= ance RFC 4573 appears to work with double and PERC generally for it's i= ntended use of camera control.=C2=A0 There is at least one MCU that uses RF= C 4573 for conference control, and that particular use won't work for M= Ds.=C2=A0 That's not a problem for me.

I belie= ve RFC 4103 also works.=C2=A0 There is information leakage in the packet le= ngths unless some form of padding is provided, and the use of marker bits a= lso leaks some information.=C2=A0 RFC 4103 is old, and it's security co= nsiderations doesn't mention either of these.=C2=A0 RFC 6562 could appl= y, but it's scope is limited specifically to VBR audio, and RFC 4103 is= not that.=C2=A0 Stopping those leaks is not a PERC issue of course, but mi= ght be something that AVT should clean up.


Paul K and Paul J - =C2=A0In a conference where accessibility is ne= eded, does there need to be some way for the MD to manage distribution of t= ext?=C2=A0 I don't believe PERC provides that, and it might be hard to = do. [/SB]



--001a113b06c456c105054c6c4d87-- From nobody Wed Apr 5 08:26:59 2017 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 94EFA129477 for ; Wed, 5 Apr 2017 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZx17p-mtO06 for ; Wed, 5 Apr 2017 08:26:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 ED46A128854 for ; Wed, 5 Apr 2017 08:26:53 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v35FQlsq028255 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 11:26:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1491406009; bh=oFZpP4L8jw7M4j4oBEdnQWb46lata8fDuIFib61OxQo=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=FA9jSrH0OyBZh/bec/bR1hhJ218GBsjNwWQGy7PTWKKFwUPeoLQGf7CmX246oJuVK Q2m2tGU3IMan0mENFuAYhPeGaoSfkRVKIWHzzffofXLg5IA7+fSukdbr+7XVddVV0y bVBWRu9H+qH8w6vWxuEzF+aP+JNUwUoO2gCZhdyI= From: "Paul E. Jones" To: "Stephen Botzko" , "Adam Roach" Cc: "Paul Kyzivat" , perc@ietf.org, "Gunnar Hellstrom" Date: Wed, 05 Apr 2017 15:26:49 +0000 Message-Id: In-Reply-To: References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB57916EC0-704D-4DCB-9C15-836141D768FE" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Wed, 05 Apr 2017 11:26:49 -0400 (EDT) Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:26:57 -0000 --------=_MB57916EC0-704D-4DCB-9C15-836141D768FE Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Steve, I would expect the MD to just send any incoming RFC 4103 packets to all=20 other participants in the conference. How that text is rendered would=20 be a local issue. The MD really cannot do anything else with those=20 packets, nor should it, really. Often, RFC 4103 is used with RFC 2198. =20 However, I see no reason for that to not go E2E, as well. In terms of security, figuring out the security weaknesses is tough. =20 The RFC 4103 payload is whatever characters the user types within a=20 buffering period. There are no word boundaries, just characters=20 collected over a period of time. There might be as little as one=20 character per packet if the typist is slow. I think it would be hard to=20 figure out what is being typed. However, one could perhaps get a hint=20 about typing rate (modulo the fact that text is buffered for a period of=20 time), that text might have been copied and pasted into a chat window,=20 or guess at some test. As an example of the latter, characters can be=20 counted, so seeing one to 5 packets with a total of five characters=20 followed by a long pause (>=3D1 buffering period) might suggest the word=20 "hello" was typed. In any case, an attack would require looking at=20 string lengths and pauses where a buffering period passes where no text=20 is sent. It would interesting if people are aware of exploits of a=20 similar nature. Perhaps as a means of mitigating even those potential=20 exploits, we might recommend to pad the transmitted packets. I'm not=20 sure what might be most appropriate, but Unicode does define a=20 zero-width space (U+200B). I copied Gunnar, as he always has insight to add on these matters. Paul ------ Original Message ------ From: "Stephen Botzko" To: "Adam Roach" Cc: "Paul Kyzivat" ; perc@ietf.org Sent: 4/5/2017 10:25:58 AM Subject: Re: [Perc] DTMF and Double > > >On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: >>[as individual] >> >>On 4/4/17 13:45, Paul Kyzivat wrote: >>>DTMF via RTP is just another codec. IIUC PERC is agnostic to codec,=20 >>>so why would you be singling it out? >> >> >>Yes. This is the right answer. >> >>/a >> > >[SB] The point here was that DTMF over RTP secured with double can only=20 >be used end-to-end unless you treat it as a special case. Choosing to=20 >treat it as "any other codec" means the MD cannot use DTMF to extend=20 >conference functions that it might have. Most traditional MCUs do use=20 >DTMF to extend conference controls. Personally I don't see that as a=20 >problem for PERC, and potentially allowing an actor w/o the e2e key=20 >access to control conference functions is a bad idea. > > >There are two other unusual cases I know of - Far End Camera Control=20 >over RTP (RFC 4573) and Text over RTP (RFC 4103) > >At first glance RFC 4573 appears to work with double and PERC generally=20 >for it's intended use of camera control. There is at least one MCU=20 >that uses RFC 4573 for conference control, and that particular use=20 >won't work for MDs. That's not a problem for me. > >I believe RFC 4103 also works. There is information leakage in the=20 >packet lengths unless some form of padding is provided, and the use of=20 >marker bits also leaks some information. RFC 4103 is old, and it's=20 >security considerations doesn't mention either of these. RFC 6562=20 >could apply, but it's scope is limited specifically to VBR audio, and=20 >RFC 4103 is not that. Stopping those leaks is not a PERC issue of=20 >course, but might be something that AVT should clean up. > > >Paul K and Paul J - In a conference where accessibility is needed,=20 >does there need to be some way for the MD to manage distribution of=20 >text? I don't believe PERC provides that, and it might be hard to do.=20 >[/SB] > > --------=_MB57916EC0-704D-4DCB-9C15-836141D768FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Steve,

I would expe= ct the MD to just send any incoming RFC 4103 packets to all other participa= nts in the conference. =C2=A0How that text is rendered would be a local iss= ue. =C2=A0The MD really cannot do anything else with those packets, nor sho= uld it, really. =C2=A0Often, RFC 4103 is used with RFC 2198. =C2=A0However, = I see no reason for that to not go E2E, as well.

In terms of security, figuring out the security = weaknesses is tough. =C2=A0The RFC 4103 payload is whatever characters the = user types within a buffering period. =C2=A0There are no word boundaries,= just characters collected over a period of time. =C2=A0There might be as li= ttle as one character per packet if the typist is slow. =C2=A0I think it wo= uld be hard to figure out what is being typed. =C2=A0However, one could per= haps get a hint about typing rate (modulo the fact that text is buffered fo= r a period of time), that text might have been copied and pasted into a cha= t window, or guess at some test. =C2=A0As an example of the latter, charact= ers can be counted, so seeing one to 5 packets with a total of five charact= ers followed by a long pause (>=3D1 buffering period) might suggest the= word "hello" was typed. =C2=A0In any case, an attack would require looking= at string lengths and pauses where a buffering period passes where no text= is sent. =C2=A0It would interesting if people are aware of exploits of a si= milar nature. =C2=A0Perhaps as a means of mitigating even those potential e= xploits, we might recommend to pad the transmitted packets. =C2=A0I'm not s= ure what might be most appropriate, but Unicode does define a zero-width sp= ace (U+200B).

I copied Gunnar, as = he always has insight to add on these matters.

Paul

------ Original Message ------
From: "Stephen Botzko" <stephen.botzko@gmail.com>
To: "Adam Roach" <adam@nostrum.= com>
Sent: 4/5/2017 10:25:58 AM
Subject: Re: [Perc] DTMF and Double



On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:
[as individual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why= would you be singling it out?


Yes. This is the right answer.

/a

<= /div>

[SB] The point here was that= DTMF over RTP secured with double can only be used end-to-end = unless you treat it as a special case.=C2=A0 Choosing to tre= at it as "any other codec" means the MD cannot use DTMF to extend conferenc= e functions that it might have.=C2=A0 Most traditional MCUs do use DTMF to= extend conference controls.=C2=A0 Personally I don't see that as a problem= for PERC, and potentially allowing an actor w/o the e2e key access to contr= ol conference functions is a bad idea.=C2=A0


There are two other unusual cases I know of - Far End Camera= Control over RTP (RFC 4573) and Text over RTP (RFC 4103)

At first glance RFC 4573 appears to work with double and PERC gene= rally for it's intended use of camera control.=C2=A0 There is at least one= MCU that uses RFC 4573 for conference control, and that particular use won'= t work for MDs.=C2=A0 That's not a problem for me.

I believe RFC 4103 also works.=C2=A0 There is information leakage in the = packet lengths unless some form of padding is provided, and the use of mar= ker bits also leaks some information.=C2=A0 RFC 4103 is old, and it's secur= ity considerations doesn't mention either of these.=C2=A0 RFC 6562 could ap= ply, but it's scope is limited specifically to VBR audio, and RFC 4103 is n= ot that.=C2=A0 Stopping those leaks is not a PERC issue of course, but migh= t be something that AVT should clean up.


<= /div>
Paul K and Paul J - =C2=A0In a conference where accessibility is= needed, does there need to be some way for the MD to manage distribution of = text?=C2=A0 I don't believe PERC provides that, and it might be hard to do= . [/SB]


--------=_MB57916EC0-704D-4DCB-9C15-836141D768FE-- From nobody Wed Apr 5 08:32:28 2017 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 940B812947F for ; Wed, 5 Apr 2017 08:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dpfnt2rncIU for ; Wed, 5 Apr 2017 08:32:24 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 3E678127241 for ; Wed, 5 Apr 2017 08:32:24 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v35FWJBB028769 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 11:32:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1491406340; bh=OOPfX8pflj+8NC2LgWsp+CNh4IvMhLWijCo7rtaHhEA=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=BExGPiPyhu7kkwHYn69r6WX06wnmZPvgcVhePFkqxv0BoES0VyC64G7l1qK3W1ilE jEe/cAYZ+PB5Akv8ptFINyuM3eMGPYc/G3ajC6eDIQ9npy6SZDI+k2HnfBdF/KrCY1 9hoRaFNNU+tOacTNeK3hY8Y3DeuJj8WuStiE0F8Y= From: "Paul E. Jones" To: "Stephen Botzko" , "Adam Roach" Cc: "Paul Kyzivat" , perc@ietf.org Date: Wed, 05 Apr 2017 15:32:21 +0000 Message-Id: In-Reply-To: References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB3BB2D401-B17C-4C60-A7BE-83CFD6700F12" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Wed, 05 Apr 2017 11:32:20 -0400 (EDT) Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:32:27 -0000 --------=_MB3BB2D401-B17C-4C60-A7BE-83CFD6700F12 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would not worry about that, either. The primary objective of PERC is=20 to ensure E2E privacy of the conversation. The MD, if compromised, can=20 send media to the wrong place, discard it, etc. PERC never had an=20 objective to prevent DOS attacks of any form. Paul ------ Original Message ------ From: "Stephen Botzko" To: "Adam Roach" Cc: "Paul Kyzivat" ; perc@ietf.org Sent: 4/5/2017 10:35:20 AM Subject: Re: [Perc] DTMF and Double > >>>potentially allowing an actor w/o the e2e key access to control=20 >conference functions is a bad idea. >We might have this issue already, since SRTCP is h2h. That needs to be=20 >added to the security considerations. > >Stephen > >On Wed, Apr 5, 2017 at 10:25 AM, Stephen Botzko=20 > wrote: >> >> >>On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: >>>[as individual] >>> >>>On 4/4/17 13:45, Paul Kyzivat wrote: >>>>DTMF via RTP is just another codec. IIUC PERC is agnostic to codec,=20 >>>>so why would you be singling it out? >>> >>> >>>Yes. This is the right answer. >>> >>>/a >>> >> >>[SB] The point here was that DTMF over RTP secured with double can=20 >>only be used end-to-end unless you treat it as a special case. =20 >>Choosing to treat it as "any other codec" means the MD cannot use DTMF=20 >>to extend conference functions that it might have. Most traditional=20 >>MCUs do use DTMF to extend conference controls. Personally I don't=20 >>see that as a problem for PERC, and potentially allowing an actor w/o=20 >>the e2e key access to control conference functions is a bad idea. >> >> >>There are two other unusual cases I know of - Far End Camera Control=20 >>over RTP (RFC 4573) and Text over RTP (RFC 4103) >> >>At first glance RFC 4573 appears to work with double and PERC=20 >>generally for it's intended use of camera control. There is at least=20 >>one MCU that uses RFC 4573 for conference control, and that particular=20 >>use won't work for MDs. That's not a problem for me. >> >>I believe RFC 4103 also works. There is information leakage in the=20 >>packet lengths unless some form of padding is provided, and the use of=20 >>marker bits also leaks some information. RFC 4103 is old, and it's=20 >>security considerations doesn't mention either of these. RFC 6562=20 >>could apply, but it's scope is limited specifically to VBR audio, and=20 >>RFC 4103 is not that. Stopping those leaks is not a PERC issue of=20 >>course, but might be something that AVT should clean up. >> >> >>Paul K and Paul J - In a conference where accessibility is needed,=20 >>does there need to be some way for the MD to manage distribution of=20 >>text? I don't believe PERC provides that, and it might be hard to do.=20 >>[/SB] >> >> > --------=_MB3BB2D401-B17C-4C60-A7BE-83CFD6700F12 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I would not worry about that, either. =C2=A0Th= e primary objective of PERC is to ensure E2E privacy of the conversation. = =C2=A0The MD, if compromised, can send media to the wrong place, discard i= t, etc. =C2=A0PERC never had an objective to prevent DOS attacks of any for= m.

Paul

------ Original Message ------
From: "Stephen Botzko" <stephen.botzko@gmail.com>
To: "Adam Roach" <adam@nostrum.= com>
Sent: 4/5/2017 10:35:20 AM
Subject: Re: [Perc] DTMF and Double

>>>potentiall= y allowing an actor w/o the e2e key access to control conference functions= is a bad idea.
We might hav= e this issue already, since SRTCP is h2h.=C2=A0 That needs to be added to t= he security considerations.

Stephen<= /div>

On W= ed, Apr 5, 2017 at 10:25 AM, Stephen Botzko <stephen.botzko@gmail.com> wrote:


On Tu= e, Apr 4, 2017 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:
[as individual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why= would you be singling it out?


Yes. This is the right answer.

/a

[SB] The point here was that DTMF over RTP secured wi= th double can only be used end-to-end unless yo= u treat it as a special case.=C2=A0 Choosing to treat it as "any other code= c" means the MD cannot use DTMF to extend conference functions that it migh= t have.=C2=A0 Most traditional MCUs do use DTMF to extend conference contro= ls.=C2=A0 Personally I don't see that as a problem for PERC, and potentiall= y allowing an actor w/o the e2e key access to control conference functions= is a bad idea.=C2=A0


There are= two other unusual cases I know of - Far End Camera Control over RTP (RFC 45= 73) and Text over RTP (RFC 4103)

At first glance = RFC 4573 appears to work with double and PERC generally for it's intended= use of camera control.=C2=A0 There is at least one MCU that uses RFC 4573 f= or conference control, and that particular use won't work for MDs.=C2=A0 Th= at's not a problem for me.

I believe RFC 4103 al= so works.=C2=A0 There is information leakage in the packet lengths unless s= ome form of padding is provided, and the use of marker bits also leaks some = information.=C2=A0 RFC 4103 is old, and it's security considerations doesn= 't mention either of these.=C2=A0 RFC 6562 could apply, but it's scope is l= imited specifically to VBR audio, and RFC 4103 is not that.=C2=A0 Stopping= those leaks is not a PERC issue of course, but might be something that AVT= should clean up.


Paul K and Pau= l J - =C2=A0In a conference where accessibility is needed, does there need= to be some way for the MD to manage distribution of text?=C2=A0 I don't bel= ieve PERC provides that, and it might be hard to do. [/SB]

=


--------=_MB3BB2D401-B17C-4C60-A7BE-83CFD6700F12-- From nobody Wed Apr 5 10:49:40 2017 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 F1F87126C26 for ; Wed, 5 Apr 2017 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1rZfeTY5HK2I for ; Wed, 5 Apr 2017 10:49:36 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1EB12940E for ; Wed, 5 Apr 2017 10:49:36 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id r203so24313181oib.3 for ; Wed, 05 Apr 2017 10:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=faIhXpuLXkqWDkUWxjBSZlqzQ6wbR7bD4w2El7Znnz8=; b=E7C0gy9h/jXKJKljduyf9QXieUCMPZHW2UFuYoTi27RoYJceTeN1KqyNjPu5szVwsk 9zarZWuoMxIGEGa1FBnD/ueI1Z5rYQwptr3bOkEieDCH1B/uwrYX8sGwp/126EDM5hX+ KDRWPApgU5Qu0FAcmjwFmNMT93P5z92WEKHQ6SJi9AtkWGznRxKMFnz57BmqGwuQA9PD uyG13sWnyhov5NEJjROjLsr4wuUTFEvARf7H3nfoUEwkyMT8ih+D7q8THMS1gwX+hFTV 7f1KOw61ruUkmcY4lsHZnuv2xCAYQ8+c+wcFb+V7yCtSqAepB2nYOcUE9UddHRoeuB2d ka5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=faIhXpuLXkqWDkUWxjBSZlqzQ6wbR7bD4w2El7Znnz8=; b=QMrjOwIxNy2ocXLOLlUF3p/OGeL6GOOGbwjJ8v1AlAO7sOZPwLVXBJ/ls9wXHAdI3L aCl7Sib5iwRYMmcv47aAWFP5nd6F/WwyDZlQaPny/xjKBQuO126t81yJYTx4Rr+DsNss Kw32Ll0uNLj5OzjAAd4se6tYL7//v0i9id0NYCGekiLfmI2voOhVLYXONBGqL0sE38ZP A8zxnGjM/8/rI6a42AhFQmVZc910gH9CzJibeFo9yEQTKQxQo0KqRHl//Ha2Wb5Y1fGQ EJ1wZ8u11T03535gj/H9pwvgemF+LVzRpqbndZsVCPoZoznK85wH+G4vNe6pm1JKzTVd OK6Q== X-Gm-Message-State: AFeK/H2Xaj0nDw0siHabxBYV5rVg3KHtnkHc+w+vco5AWL3p0inqArTCzM5mMvv22l7hnDip7az6JL1m79spKw== X-Received: by 10.202.252.193 with SMTP id a184mr13501805oii.40.1491414575883; Wed, 05 Apr 2017 10:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Wed, 5 Apr 2017 10:49:35 -0700 (PDT) In-Reply-To: References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> From: Stephen Botzko Date: Wed, 5 Apr 2017 13:49:35 -0400 Message-ID: To: "Paul E. Jones" Cc: Adam Roach , Paul Kyzivat , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113deffc0228bd054c6f04d8 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:49:39 -0000 --001a113deffc0228bd054c6f04d8 Content-Type: text/plain; charset=UTF-8 Of course the MD can execute a wide range of DOS attacks. SRTCP today is always h2h, so PERC doesn't open any new doors here. But the implications of e2e SRTP and h2h SRTCP with a semi-trusted MD isn't described in double security considerations at all. There is a lot of stuff that is sent over RTCP. Some of these things can also be sent over RTP (for instance per RFC 7941), and if the MD doesn't need those things, perhaps they should be sent only over RTP with PERC. And of course things the MD does need must be sent over RTCP. Anyway, my original "might have this issue" was simply a realization that I hadn't actually considered the full range of information (status, feedback, etc) that can sent over RTCP. In addition to the attacks you list in your framework draft, a compromised MD can also use TMMBR and other RTCP controls to attack a conference. Stephen On Wed, Apr 5, 2017 at 11:32 AM, Paul E. Jones wrote: > I would not worry about that, either. The primary objective of PERC is to > ensure E2E privacy of the conversation. The MD, if compromised, can send > media to the wrong place, discard it, etc. PERC never had an objective to > prevent DOS attacks of any form. > > Paul > > ------ Original Message ------ > From: "Stephen Botzko" > To: "Adam Roach" > Cc: "Paul Kyzivat" ; perc@ietf.org > Sent: 4/5/2017 10:35:20 AM > Subject: Re: [Perc] DTMF and Double > > >>>*potentially allowing an actor w/o the e2e key access to control > conference functions is a bad idea.* > We might have this issue already, since SRTCP is h2h. That needs to be > added to the security considerations. > > Stephen > > On Wed, Apr 5, 2017 at 10:25 AM, Stephen Botzko > wrote: > >> >> >> On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: >> >>> [as individual] >>> >>> On 4/4/17 13:45, Paul Kyzivat wrote: >>> >>>> DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so >>>> why would you be singling it out? >>>> >>> >>> >>> Yes. This is the right answer. >>> >>> /a >>> >>> >> [SB] The point here was that DTMF over RTP secured with double can *only* >> be used end-to-end *unless* you treat it as a special case. Choosing to >> treat it as "any other codec" means the MD cannot use DTMF to extend >> conference functions that it might have. Most traditional MCUs do use DTMF >> to extend conference controls. Personally I don't see that as a problem >> for PERC, and potentially allowing an actor w/o the e2e key access to >> control conference functions is a bad idea. >> >> >> There are two other unusual cases I know of - Far End Camera Control over >> RTP (RFC 4573) and Text over RTP (RFC 4103) >> >> At first glance RFC 4573 appears to work with double and PERC generally >> for it's intended use of camera control. There is at least one MCU that >> uses RFC 4573 for conference control, and that particular use won't work >> for MDs. That's not a problem for me. >> >> I believe RFC 4103 also works. There is information leakage in the >> packet lengths unless some form of padding is provided, and the use of >> marker bits also leaks some information. RFC 4103 is old, and it's >> security considerations doesn't mention either of these. RFC 6562 could >> apply, but it's scope is limited specifically to VBR audio, and RFC 4103 is >> not that. Stopping those leaks is not a PERC issue of course, but might be >> something that AVT should clean up. >> >> >> Paul K and Paul J - In a conference where accessibility is needed, does >> there need to be some way for the MD to manage distribution of text? I >> don't believe PERC provides that, and it might be hard to do. [/SB] >> >> >> > --001a113deffc0228bd054c6f04d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Of course the MD can execute a wide range of DOS atta= cks.=C2=A0

SRTCP today is always h2h, so PERC does= n't open any new doors here.=C2=A0 But the implications of e2e SRTP and= h2h SRTCP with a semi-trusted MD isn't described in double security co= nsiderations at all.

There is a lot of stuff that = is sent over RTCP.=C2=A0 Some of these things can also be sent over RTP (fo= r instance per RFC 7941), and if the MD doesn't need those things, perh= aps they should be sent only over RTP with PERC.=C2=A0 And of course things= the MD does need must be sent over RTCP.=C2=A0

An= yway, my original "might have this issue" was simply a realizatio= n that I hadn't actually considered the full range of information (stat= us, feedback, etc) that can sent over RTCP.=C2=A0 In addition to the attack= s you list in your framework draft, a compromised MD can also use TMMBR and= other RTCP controls to attack a conference.

Steph= en

On W= ed, Apr 5, 2017 at 11:32 AM, Paul E. Jones <paulej@packetizer.com&= gt; wrote:
<= /u>
I would not worry about that, either.=C2=A0 The primary object= ive of PERC is to ensure E2E privacy of the conversation.=C2=A0 The MD, if = compromised, can send media to the wrong place, discard it, etc.=C2=A0 PERC= never had an objective to prevent DOS attacks of any form.

Paul

------ Original Message ------
From: "Stephen Botzko" <stephen.botzko@gmail.com>
To: "Adam Roach" <adam@nostrum.com>
Sent: 4/5/2017 10:35:20 AM
Subject: Re: [Perc] DTMF and Double

>>>potentiall= y allowing an actor w/o the e2e key access to control conference functions = is a bad idea.
We might hav= e this issue already, since SRTCP is h2h.=C2=A0 That needs to be added to t= he security considerations.

Stephen

On Wed, = Apr 5, 2017 at 10:25 AM, Stephen Botzko <stephen.botzko@gmail.com> wrote:
<= div dir=3D"ltr">

On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
[as i= ndividual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why = would you be singling it out?


Yes. This is the right answer.

/a


=
[SB] The point here was that DTMF over RTP secured with d= ouble can only be used end-to-end unless you tr= eat it as a special case.=C2=A0 Choosing to treat it as "any other cod= ec" means the MD cannot use DTMF to extend conference functions that i= t might have.=C2=A0 Most traditional MCUs do use DTMF to extend conference = controls.=C2=A0 Personally I don't see that as a problem for PERC, and = potentially allowing an actor w/o the e2e key access to control conference = functions is a bad idea.=C2=A0


Ther= e are two other unusual cases I know of - Far End Camera Control over RTP (= RFC 4573) and Text over RTP (RFC 4103)

At first gl= ance RFC 4573 appears to work with double and PERC generally for it's i= ntended use of camera control.=C2=A0 There is at least one MCU that uses RF= C 4573 for conference control, and that particular use won't work for M= Ds.=C2=A0 That's not a problem for me.

I belie= ve RFC 4103 also works.=C2=A0 There is information leakage in the packet le= ngths unless some form of padding is provided, and the use of marker bits a= lso leaks some information.=C2=A0 RFC 4103 is old, and it's security co= nsiderations doesn't mention either of these.=C2=A0 RFC 6562 could appl= y, but it's scope is limited specifically to VBR audio, and RFC 4103 is= not that.=C2=A0 Stopping those leaks is not a PERC issue of course, but mi= ght be something that AVT should clean up.


Paul K and Paul J - =C2=A0In a conference where accessibility is ne= eded, does there need to be some way for the MD to manage distribution of t= ext?=C2=A0 I don't believe PERC provides that, and it might be hard to = do. [/SB]




--001a113deffc0228bd054c6f04d8-- From nobody Wed Apr 5 11:00:40 2017 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 3562C129489 for ; Wed, 5 Apr 2017 11:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 p5VFYwz5jpYO for ; Wed, 5 Apr 2017 11:00:34 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 102A6128DF6 for ; Wed, 5 Apr 2017 11:00:33 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r203so24673831oib.3 for ; Wed, 05 Apr 2017 11:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=npQy9D+g6qEUe25BEtEWhfktnoFj5brqwT91DEHl280=; b=l+hLnvFCtRfkpJ0swGyilVfMNqTSE8pMmeeQo6JlHIZK0/MAgmuK17t2ZBvcgoQstN xFen9/OfamIV37PwycR7B9Qs9zrU5lC7or/Ef8xfatqF7sZpV+JPb0Kqdk2iD03bAoWr 3n3eylgQ53khYezDHIkQDi0l4MAXu7hwuSrIe1cuD1N+1LGFPhqmSqU2bHLh8Z06DcV8 iyG7SPD08fLjShuiD89i82BBHLTewY3kpcbsJmgJ7MDM3kWiRTElGrB0fvzd047Z6OOq AM2rZg39mIE54eVswxCWq1oLCOGDsQjqJ+uvbZJ8YyW9VtQC65mQ2WQApucymjp/0ruU ATvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=npQy9D+g6qEUe25BEtEWhfktnoFj5brqwT91DEHl280=; b=TZ8iU2dSdnY1/QDCiDrOW9KmC7lunIBS3x+Vv/9J/Vf8oJaWtz6vDVUPWRGwizq33H XTOauCmWJL5svTSgT7K7dFfzOpcIz3Ci/0s1d+035Fih9wb8iueofB8qnweFWTCEIZAT cqtoDfD2pnIYAJVqsowiwsdAdj4wlSKRGlYmuCXvuQj6kT/GA7wXQbAht4oN1sG4GkKg OgPhqyu2PGS5n3o4AsWFhCcrfbRyyXY3H7pm/ikt16iLytwHrQd8/GZA6F1T9I0qz78b Ok4iVnnIttIgopSTmNRbqjtLiyAKEHPc3B9XtAQqSnhYNAgHLuSUCfwDRo7P0hWaUAbv eojA== X-Gm-Message-State: AFeK/H1PS+B6RtsvIrHwrxfuVQR+qo96Pg8uCGlRdq9RtR+nrltye1MPasKnCTncy/I0gkFtFcCJGFYyy6AuJg== X-Received: by 10.202.81.83 with SMTP id f80mr5465684oib.23.1491415232332; Wed, 05 Apr 2017 11:00:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Wed, 5 Apr 2017 11:00:31 -0700 (PDT) In-Reply-To: References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> From: Stephen Botzko Date: Wed, 5 Apr 2017 14:00:31 -0400 Message-ID: To: "Paul E. Jones" Cc: Adam Roach , Paul Kyzivat , perc@ietf.org, Gunnar Hellstrom Content-Type: multipart/alternative; boundary=001a113b06c422ca0c054c6f2bd1 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 18:00:39 -0000 --001a113b06c422ca0c054c6f2bd1 Content-Type: text/plain; charset=UTF-8 >>>I would expect the MD to just send any incoming RFC 4103 packets to all other participants in the conference I was hoping that was sufficient. >>> I'm not sure what might be most appropriate, but Unicode does define a zero-width space (U+200B). RTP padding is likely enough, and if the max characters per packet is small the character count might already be reasonably masked by the AES block size. The idle is harder to solve (which relates to the marker bit use). That does provide leakage about when people are talking, and perhaps the length of each remark. Steve On Wed, Apr 5, 2017 at 11:26 AM, Paul E. Jones wrote: > Steve, > > I would expect the MD to just send any incoming RFC 4103 packets to all > other participants in the conference. How that text is rendered would be a > local issue. The MD really cannot do anything else with those packets, nor > should it, really. Often, RFC 4103 is used with RFC 2198. However, I see > no reason for that to not go E2E, as well. > > In terms of security, figuring out the security weaknesses is tough. The > RFC 4103 payload is whatever characters the user types within a buffering > period. There are no word boundaries, just characters collected over a > period of time. There might be as little as one character per packet if > the typist is slow. I think it would be hard to figure out what is being > typed. However, one could perhaps get a hint about typing rate (modulo the > fact that text is buffered for a period of time), that text might have been > copied and pasted into a chat window, or guess at some test. As an example > of the latter, characters can be counted, so seeing one to 5 packets with a > total of five characters followed by a long pause (>=1 buffering period) > might suggest the word "hello" was typed. In any case, an attack would > require looking at string lengths and pauses where a buffering period > passes where no text is sent. It would interesting if people are aware of > exploits of a similar nature. Perhaps as a means of mitigating even those > potential exploits, we might recommend to pad the transmitted packets. I'm > not sure what might be most appropriate, but Unicode does define a > zero-width space (U+200B). > > I copied Gunnar, as he always has insight to add on these matters. > > Paul > > ------ Original Message ------ > From: "Stephen Botzko" > To: "Adam Roach" > Cc: "Paul Kyzivat" ; perc@ietf.org > Sent: 4/5/2017 10:25:58 AM > Subject: Re: [Perc] DTMF and Double > > > > On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: > >> [as individual] >> >> On 4/4/17 13:45, Paul Kyzivat wrote: >> >>> DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so >>> why would you be singling it out? >>> >> >> >> Yes. This is the right answer. >> >> /a >> >> > [SB] The point here was that DTMF over RTP secured with double can *only* > be used end-to-end *unless* you treat it as a special case. Choosing to > treat it as "any other codec" means the MD cannot use DTMF to extend > conference functions that it might have. Most traditional MCUs do use DTMF > to extend conference controls. Personally I don't see that as a problem > for PERC, and potentially allowing an actor w/o the e2e key access to > control conference functions is a bad idea. > > > There are two other unusual cases I know of - Far End Camera Control over > RTP (RFC 4573) and Text over RTP (RFC 4103) > > At first glance RFC 4573 appears to work with double and PERC generally > for it's intended use of camera control. There is at least one MCU that > uses RFC 4573 for conference control, and that particular use won't work > for MDs. That's not a problem for me. > > I believe RFC 4103 also works. There is information leakage in the packet > lengths unless some form of padding is provided, and the use of marker bits > also leaks some information. RFC 4103 is old, and it's security > considerations doesn't mention either of these. RFC 6562 could apply, but > it's scope is limited specifically to VBR audio, and RFC 4103 is not that. > Stopping those leaks is not a PERC issue of course, but might be something > that AVT should clean up. > > > Paul K and Paul J - In a conference where accessibility is needed, does > there need to be some way for the MD to manage distribution of text? I > don't believe PERC provides that, and it might be hard to do. [/SB] > > > --001a113b06c422ca0c054c6f2bd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 5, 2017 at 11:26 AM, Paul= E. Jones <paulej@packetizer.com> wrote:
Steve,

I would= expect the MD to just send any incoming RFC 4103 packets to all other part= icipants in the conference.=C2=A0 How that text is rendered would be a loca= l issue.=C2=A0 The MD really cannot do anything else with those packets, no= r should it, really.=C2=A0 Often, RFC 4103 is used with RFC 2198.=C2=A0 How= ever, I see no reason for that to not go E2E, as well.

=
In terms of security, figuring out the securit= y weaknesses is tough.=C2=A0 The RFC 4103 payload is whatever characters th= e user types within a buffering period.=C2=A0 There are no word boundaries,= just characters collected over a period of time.=C2=A0 There might be as l= ittle as one character per packet if the typist is slow.=C2=A0 I think it w= ould be hard to figure out what is being typed.=C2=A0 However, one could pe= rhaps get a hint about typing rate (modulo the fact that text is buffered f= or a period of time), that text might have been copied and pasted into a ch= at window, or guess at some test.=C2=A0 As an example of the latter, charac= ters can be counted, so seeing one to 5 packets with a total of five charac= ters followed by a long pause (>=3D1 buffering period) might suggest the= word "hello" was typed.=C2=A0 In any case, an attack would requi= re looking at string lengths and pauses where a buffering period passes whe= re no text is sent.=C2=A0 It would interesting if people are aware of explo= its of a similar nature.=C2=A0 Perhaps as a means of mitigating even those = potential exploits, we might recommend to pad the transmitted packets.=C2= =A0 I'm not sure what might be most appropriate, but Unicode does defin= e a zero-width space (U+200B).
<= div style=3D"direction:ltr">
I copied Gunna= r, as he always has insight to add on these matters.

Paul
<= /span>

------ Original Message ------
From: "Stephen Botzko" <stephen.botzko@gmail.com>
To: "Adam Roach" <adam@nostrum.com>
Sent: 4/5/2017 10:25:58 AM
Subject: Re: [Perc] DTMF and Double



On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:
[as indivi= dual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why = would you be singling it out?


Yes. This is the right answer.

/a


[SB] The point here was that DTMF over RTP secured with double can= only be used end-to-end unless you treat it as= a special case.=C2=A0 Choosing to treat it as "any other codec" = means the MD cannot use DTMF to extend conference functions that it might h= ave.=C2=A0 Most traditional MCUs do use DTMF to extend conference controls.= =C2=A0 Personally I don't see that as a problem for PERC, and potential= ly allowing an actor w/o the e2e key access to control conference functions= is a bad idea.=C2=A0


There are two= other unusual cases I know of - Far End Camera Control over RTP (RFC 4573)= and Text over RTP (RFC 4103)

At first glance RFC = 4573 appears to work with double and PERC generally for it's intended u= se of camera control.=C2=A0 There is at least one MCU that uses RFC 4573 fo= r conference control, and that particular use won't work for MDs.=C2=A0= That's not a problem for me.

I believe RFC 41= 03 also works.=C2=A0 There is information leakage in the packet lengths unl= ess some form of padding is provided, and the use of marker bits also leaks= some information.=C2=A0 RFC 4103 is old, and it's security considerati= ons doesn't mention either of these.=C2=A0 RFC 6562 could apply, but it= 's scope is limited specifically to VBR audio, and RFC 4103 is not that= .=C2=A0 Stopping those leaks is not a PERC issue of course, but might be so= mething that AVT should clean up.


P= aul K and Paul J - =C2=A0In a conference where accessibility is needed, doe= s there need to be some way for the MD to manage distribution of text?=C2= =A0 I don't believe PERC provides that, and it might be hard to do. [/S= B]



--001a113b06c422ca0c054c6f2bd1-- From nobody Wed Apr 5 19:44:55 2017 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 C5B991270FC for ; Wed, 5 Apr 2017 19:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfQziXLCU92g for ; Wed, 5 Apr 2017 19:44:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 35A3E1288B8 for ; Wed, 5 Apr 2017 19:44:20 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v362iFHH024365 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 22:44:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1491446656; bh=o2bWgVDIvtXqM2tseetGKB7Y2ZBNXxgAeCIrbG4rlBI=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=FQqs/71gn3doD7wmEoIvvSF9bhfIvzEH1BzPCxRseZh9frQBAnKIOGR4rK75TZvBC f6KfgLhxkC8BsGonjOXHll+JvgiNjLxhqWibnFkvIinE+jkAtJYWBWl/n1N7qAsGn4 uc3s59OGWq95qvTvF1OoZmv6+9IMMesx84fL3l3M= From: "Paul E. Jones" To: "Stephen Botzko" Cc: "Adam Roach" , "Paul Kyzivat" , perc@ietf.org Date: Thu, 06 Apr 2017 02:44:17 +0000 Message-Id: In-Reply-To: References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <71bb6330-d993-496f-9f4f-097092cb0955@gmail.com> <75f8aaee-59fb-e941-317b-382057a3f870@gmail.com> <35fa41e4-729a-5cfa-37e4-d4fe2e147a20@comcast.net> <4607aa9d-0fc1-f055-e472-ed597302dd69@nostrum.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBD333CA8B-CDB7-482B-B484-AB9132E3FB8B" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Wed, 05 Apr 2017 22:44:16 -0400 (EDT) Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 02:44:55 -0000 --------=_MBD333CA8B-CDB7-482B-B484-AB9132E3FB8B Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Steve, Yeah, you're correct. I recall in one meeting we discussed explaining=20 that one ought not send sensitive information over RTCP, but that never=20 founds its way into the text. It might be in the architecture document=20 and, IMO, that's the right place to put it, since it frames the whole=20 model. Not sure how to deal with encrypted header extensions in light of recent=20 discussion here on the list. Topic for an interim meeting, perhaps. Paul ------ Original Message ------ From: "Stephen Botzko" To: "Paul E. Jones" Cc: "Adam Roach" ; "Paul Kyzivat"=20 ; perc@ietf.org Sent: 4/5/2017 1:49:35 PM Subject: Re: [Perc] DTMF and Double >Of course the MD can execute a wide range of DOS attacks. > >SRTCP today is always h2h, so PERC doesn't open any new doors here. =20 >But the implications of e2e SRTP and h2h SRTCP with a semi-trusted MD=20 >isn't described in double security considerations at all. > >There is a lot of stuff that is sent over RTCP. Some of these things=20 >can also be sent over RTP (for instance per RFC 7941), and if the MD=20 >doesn't need those things, perhaps they should be sent only over RTP=20 >with PERC. And of course things the MD does need must be sent over=20 >RTCP. > >Anyway, my original "might have this issue" was simply a realization=20 >that I hadn't actually considered the full range of information=20 >(status, feedback, etc) that can sent over RTCP. In addition to the=20 >attacks you list in your framework draft, a compromised MD can also use=20 >TMMBR and other RTCP controls to attack a conference. > >Stephen > >On Wed, Apr 5, 2017 at 11:32 AM, Paul E. Jones =20 >wrote: >>I would not worry about that, either. The primary objective of PERC=20 >>is to ensure E2E privacy of the conversation. The MD, if compromised,=20 >>can send media to the wrong place, discard it, etc. PERC never had an=20 >>objective to prevent DOS attacks of any form. >> >>Paul >> >>------ Original Message ------ >>From: "Stephen Botzko" >>To: "Adam Roach" >>Cc: "Paul Kyzivat" ; perc@ietf.org >>Sent: 4/5/2017 10:35:20 AM >>Subject: Re: [Perc] DTMF and Double >> >>> >>>potentially allowing an actor w/o the e2e key access to control=20 >>>conference functions is a bad idea. >>>We might have this issue already, since SRTCP is h2h. That needs to=20 >>>be added to the security considerations. >>> >>>Stephen >>> >>>On Wed, Apr 5, 2017 at 10:25 AM, Stephen Botzko=20 >>> wrote: >>>> >>>> >>>>On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach wrote: >>>>>[as individual] >>>>> >>>>>On 4/4/17 13:45, Paul Kyzivat wrote: >>>>>>DTMF via RTP is just another codec. IIUC PERC is agnostic to=20 >>>>>>codec, so why would you be singling it out? >>>>> >>>>> >>>>>Yes. This is the right answer. >>>>> >>>>>/a >>>>> >>>> >>>>[SB] The point here was that DTMF over RTP secured with double can=20 >>>>only be used end-to-end unless you treat it as a special case. =20 >>>>Choosing to treat it as "any other codec" means the MD cannot use=20 >>>>DTMF to extend conference functions that it might have. Most=20 >>>>traditional MCUs do use DTMF to extend conference controls. =20 >>>>Personally I don't see that as a problem for PERC, and potentially=20 >>>>allowing an actor w/o the e2e key access to control conference=20 >>>>functions is a bad idea. >>>> >>>> >>>>There are two other unusual cases I know of - Far End Camera Control=20 >>>>over RTP (RFC 4573) and Text over RTP (RFC 4103) >>>> >>>>At first glance RFC 4573 appears to work with double and PERC=20 >>>>generally for it's intended use of camera control. There is at=20 >>>>least one MCU that uses RFC 4573 for conference control, and that=20 >>>>particular use won't work for MDs. That's not a problem for me. >>>> >>>>I believe RFC 4103 also works. There is information leakage in the=20 >>>>packet lengths unless some form of padding is provided, and the use=20 >>>>of marker bits also leaks some information. RFC 4103 is old, and=20 >>>>it's security considerations doesn't mention either of these. RFC=20 >>>>6562 could apply, but it's scope is limited specifically to VBR=20 >>>>audio, and RFC 4103 is not that. Stopping those leaks is not a PERC=20 >>>>issue of course, but might be something that AVT should clean up. >>>> >>>> >>>>Paul K and Paul J - In a conference where accessibility is needed,=20 >>>>does there need to be some way for the MD to manage distribution of=20 >>>>text? I don't believe PERC provides that, and it might be hard to=20 >>>>do. [/SB] >>>> >>>> >>> > --------=_MBD333CA8B-CDB7-482B-B484-AB9132E3FB8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Steve,

Yeah, you're = correct. =C2=A0I recall in one meeting we discussed explaining that one ou= ght not send sensitive information over RTCP, but that never founds its way = into the text. =C2=A0It might be in the architecture document and, IMO, th= at's the right place to put it, since it frames the whole model.
=
Not sure how to deal with encryp= ted header extensions in light of recent discussion here on the list. =C2= =A0Topic for an interim meeting, perhaps.

Paul

------ Original Message ------
From: "Stephen Botzko" <stephen.botzko@gmail.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Cc: "Adam Roach" <adam@nostrum.= com>; "Paul Kyzivat" <paul.kyzivat@comcast.net>; perc@ie= tf.org
Sent: 4/5/2017 1:49:35 PM
Subject: Re: [Perc] DTMF and Double

Of course the MD can execute a wide range of DOS atta= cks.=C2=A0

SRTCP today is always h2h, so PERC do= esn't open any new doors here.=C2=A0 But the implications of e2e SRTP and h= 2h SRTCP with a semi-trusted MD isn't described in double security consider= ations at all.

There is a lot of stuff that is s= ent over RTCP.=C2=A0 Some of these things can also be sent over RTP (for in= stance per RFC 7941), and if the MD doesn't need those things, perhaps they = should be sent only over RTP with PERC.=C2=A0 And of course things the MD= does need must be sent over RTCP.=C2=A0

Anyway,= my original "might have this issue" was simply a realization that I hadn't= actually considered the full range of information (status, feedback, etc) t= hat can sent over RTCP.=C2=A0 In addition to the attacks you list in your f= ramework draft, a compromised MD can also use TMMBR and other RTCP controls = to attack a conference.

Stephen

On Wed, Apr 5, 2017= at 11:32 AM, Paul E. Jones <paulej@packetizer.com> wrote:
I would not worry a= bout that, either.=C2=A0 The primary objective of PERC is to ensure E2E pri= vacy of the conversation.=C2=A0 The MD, if compromised, can send media to t= he wrong place, discard it, etc.=C2=A0 PERC never had an objective to preve= nt DOS attacks of any form.

Paul

------ Original Message ------
From: "Stephen Botzko" <stephen.botzko@gmail.com>
To: "Adam Roach" <adam@nostrum.= com>
Sent: 4/5/2017 10:35:20 AM
Subject: Re: [Perc] DTMF and Double

>>>potentiall= y allowing an actor w/o the e2e key access to control conference functions= is a bad idea.
We might hav= e this issue already, since SRTCP is h2h.=C2=A0 That needs to be added to t= he security considerations.

Stephen<= /div>

On W= ed, Apr 5, 2017 at 10:25 AM, Stephen Botzko <stephen.botzko@gmail.com> wrote:


On Tue, Apr 4, 2017 at 2:55 PM, Adam Roach <adam@nostrum.com> wrote:
[as individual]

On 4/4/17 13:45, Paul Kyzivat wrote:
DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why= would you be singling it out?


Yes. This is the right answer.

/a

[SB] The point here was that DTMF over RTP secured wi= th double can only be used end-to-end unless yo= u treat it as a special case.=C2=A0 Choosing to treat it as "any other code= c" means the MD cannot use DTMF to extend conference functions that it migh= t have.=C2=A0 Most traditional MCUs do use DTMF to extend conference contro= ls.=C2=A0 Personally I don't see that as a problem for PERC, and potentiall= y allowing an actor w/o the e2e key access to control conference functions= is a bad idea.=C2=A0


There are= two other unusual cases I know of - Far End Camera Control over RTP (RFC 45= 73) and Text over RTP (RFC 4103)

At first glance = RFC 4573 appears to work with double and PERC generally for it's intended= use of camera control.=C2=A0 There is at least one MCU that uses RFC 4573 f= or conference control, and that particular use won't work for MDs.=C2=A0 Th= at's not a problem for me.

I believe RFC 4103 al= so works.=C2=A0 There is information leakage in the packet lengths unless s= ome form of padding is provided, and the use of marker bits also leaks some = information.=C2=A0 RFC 4103 is old, and it's security considerations doesn= 't mention either of these.=C2=A0 RFC 6562 could apply, but it's scope is l= imited specifically to VBR audio, and RFC 4103 is not that.=C2=A0 Stopping= those leaks is not a PERC issue of course, but might be something that AVT= should clean up.


Paul K and Pau= l J - =C2=A0In a conference where accessibility is needed, does there need= to be some way for the MD to manage distribution of text?=C2=A0 I don't bel= ieve PERC provides that, and it might be hard to do. [/SB]

=



--------=_MBD333CA8B-CDB7-482B-B484-AB9132E3FB8B-- From nobody Mon Apr 10 06:28:52 2017 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 D45F11294E1 for ; Mon, 10 Apr 2017 06:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ8xNiol57B9 for ; Mon, 10 Apr 2017 06:28:50 -0700 (PDT) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26801294DF for ; Mon, 10 Apr 2017 06:28:49 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 290E920265; Mon, 10 Apr 2017 09:28:49 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C09AA20189; Mon, 10 Apr 2017 09:28:48 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 10 Apr 2017 09:28:49 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> Date: Mon, 10 Apr 2017 07:28:47 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <89E57A5F-1C30-4346-AF9B-B58927C17F38@iii.ca> References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:28:52 -0000 > On Apr 4, 2017, at 4:22 AM, Sergio Garcia Murillo = wrote: >=20 > Hi all, >=20 > Hate to ask this, but I have one more doubt when making changes to = libwertc to support double. Should DTMF be also double protected or we = should send it HBH? >=20 > At least on webrtc, browsers are only meant to send DTMF, not receive = them, so it would make sense to end them at the SFU and not propagate it = to the other participants. >=20 > Best regards >=20 > Sergio >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc DTMF send in RTP should be treated just like any other media. There are = PERC use cases where we do want DTMF to get to the far end and be E2E = protected. Keep in mind PERC is meant to work with WebRTC but also with = things other than WebRTC. If and endpoint wants to signal things to the = MD ( like mute ), then there are much better ways than using DTMF to do = that.=20 From nobody Mon Apr 10 06:35:30 2017 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 B1A111294DF for ; Mon, 10 Apr 2017 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kesO89-oXdU7 for ; Mon, 10 Apr 2017 06:35:28 -0700 (PDT) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC5C12947D for ; Mon, 10 Apr 2017 06:35:28 -0700 (PDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 42F965CCF; Mon, 10 Apr 2017 09:35:17 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B42086205; Mon, 10 Apr 2017 09:35:16 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 10 Apr 2017 09:35:17 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 10 Apr 2017 07:35:15 -0600 Message-Id: To: perc@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:35:29 -0000 I've looked at a bunch of options for how we could approach this. = Originally I planned to write them all up but the one that Nils (and = others) was talking about seems like a clear best one to me so let me = describe that then perhaps list some of the others ... The goal of this is to keep the basic flow of information in your = average endpoint as close to possible as it is today and not need to = substantial change any existing specification when using double vs when = using other STLS-SRTP transforms. The goals is also not to just solve = the problems of RTX and FEC used today, but also be compatible with more = complex FEC schemes that might be done in the future which have far more = state that can become corrupted by un authenticated packets.=20 The basic approach is pretty simple. We add to the OBH block a flag that = indicates if that double algorithm does normal crypto where the half the = key is used for the inner encrypt, then 2nd half key used for outer, or, = if the flag is set, it only does the outer part. This allows a packet = that is meant for the Media Distributor, and does not contain a payload = that has non encrypted user media, to effectively be marked for single, = not double encryption. RTX, FEC, and RTCP packets would be marked this = way. It keeps all the flow of processing the same as existing systems = that are not using double. The reason the flag needs to be in the OBH is = the system receiving the packets needs to know this information to be = able to decrypt.=20 I don't think that using RTX for creating wasted bandwidth via padding = is a great idea but none the less, this would support that use of RTX. = It also allows the Media Distributor, to look at the RTX payload to find = the OSN (original Sequence Number) so that the Media Distributor, can do = repair. A RTX sender would cache the packets it is sending (which are = normal double encrypted) and when it got a request for a retransmission, = it would take the cached packet to form the RTX packet to send. This is = exactly how RTX works if the endpoint is not doing double so it is nice = that it is the same.=20 Below I will list a few options that I considered but view as = significantly worse than the above proposal.=20 1. Send RTX/FEC non authenticated, do the repair, and if the repair = packet validated, then consider it OK=20 2. Send RTX/FEC on separate steam that did not not negotiate double=20 3. When using RTX and double, create a new RTP header extension that = provides the Media Distributor with the OSN in the header extension. The = RTX packet would still have the OSN in it.=20 4. Leave RTX out of the first version of PERC and solve it as an = extension to PERC later=20 5. Some sequence o extracting an inserting packets half way through the = double transform. Among other problems with requires the endpoints to = significantly change their flow when using double and problem involves = updating many specs to have special text around double handling.=20 6. Simply use RTX in end to end way and not have the Media Distributor = participate in RTX. 7. Do a new version of RTX that puts the OSN as a header extension = instead of as a payload extension.=20 From nobody Mon Apr 10 07:04:23 2017 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 AF014128BB6 for ; Mon, 10 Apr 2017 07:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0GHLv-BxbO2y for ; Mon, 10 Apr 2017 07:04:14 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 A8D68120046 for ; Mon, 10 Apr 2017 07:04:13 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w204so8927570wmd.1 for ; Mon, 10 Apr 2017 07:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Zp7slJHpFxKEJdm/Ay2eaolySaXLvWbaVqLmsO/vSTA=; b=BK+IpPQSzGQEduKKbciETGGLBrxT6M1IGQeAgkd0HHcwDw1hbBig9vHWV5QJzmycA/ y8aD9nx9LlrFrEA4jkxYcoQgob5cOj2EFOp58axEoricNp4zSJBBY26AhkzON/yN4KNs LvDtxENCnB0Ago1ITSy3ZR3m5HQgEpnroC39NnoorTGlJrXh62FyrGNxvjr9C8SZ8y9E d6GXHiAKh7H6rdnhqZiDn59Q+D6sF1/MsxpQwwBTe56uTbwgawBQbe8mvg2to3yPZb/2 Xd2XCFRJPDDMau3ZoxNHUzE4fvHoYnVYsc2FApScyCbQxZOyDz1vsUhZDsuwcfoKLMAL wN4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Zp7slJHpFxKEJdm/Ay2eaolySaXLvWbaVqLmsO/vSTA=; b=triQhugm9SqoHXW1DUUhOFBYzFmURF+c4qplqaoMydNB9PH7vJvAY80vl2BM64nrkg rwkO7uWVPN8YHWxu8n70FaCcbmafc9ccYWRdo/Tajs8BSgSqE3H1I8lWyQiuJbs46kE7 XZmsf+A17fXTkp2odI5vJW4y5urnUipRXbEI+QvQwJEJ2kz/4q+XAoVzSYoHsgwejU+0 GuAeWCGhRLXNmmk9uF74flbqcDO9MfAyv8JmC68KyHXc/4bjUzHzF3R65Is1PTrhIECT XztmohJcWPjftpNSKhjw3Ifj2i4zMbORY6fhksylZjvf1U7Jqbg7wSP6yEiWk+/i7vls FtvQ== X-Gm-Message-State: AN3rC/5zF0ZFRZ7HJhduqywMPAXR/eAPdvW8UznHyeKSOXakbTZdAIzNnxq1mBhGFBYi3A== X-Received: by 10.28.45.216 with SMTP id t207mr10406313wmt.85.1491833051828; Mon, 10 Apr 2017 07:04:11 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id 204sm10468180wmw.0.2017.04.10.07.04.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 07:04:10 -0700 (PDT) To: perc@ietf.org References: From: Sergio Garcia Murillo Message-ID: Date: Mon, 10 Apr 2017 16:04:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:04:22 -0000 Hi Cullen, One thing I don't agree with is that currently RTX sender does not store sent packets after applying the DTLS/SRTP transform, they store it in clear. When a retransmission is requested, it retrieves the raw packet, creates the RTX packet by appending the OSN and appending the raw media and applies the DTLS/SRTP crypto to it. In order to keep the same scheme in double, the RTX sender must keep the rtp packets after the inner crypto is applied but before the outer crypto is done. That way, when a retransmission is requested, it will create a rtp packet with the OSN and append the media of the "inner crypted" packet, and perform the outher crypto. Also, not sure why we need to add a flag to the OHB header when RTX and FEC packets are already defined by payload type, except if we want to allow RTX/FEC both HBH and E2E. For RTCP it is not possible at all. Best regards Sergio On 10/04/2017 15:35, Cullen Jennings wrote: > I've looked at a bunch of options for how we could approach this. Originally I planned to write them all up but the one that Nils (and others) was talking about seems like a clear best one to me so let me describe that then perhaps list some of the others ... > > The goal of this is to keep the basic flow of information in your average endpoint as close to possible as it is today and not need to substantial change any existing specification when using double vs when using other STLS-SRTP transforms. The goals is also not to just solve the problems of RTX and FEC used today, but also be compatible with more complex FEC schemes that might be done in the future which have far more state that can become corrupted by un authenticated packets. > > The basic approach is pretty simple. We add to the OBH block a flag that indicates if that double algorithm does normal crypto where the half the key is used for the inner encrypt, then 2nd half key used for outer, or, if the flag is set, it only does the outer part. This allows a packet that is meant for the Media Distributor, and does not contain a payload that has non encrypted user media, to effectively be marked for single, not double encryption. RTX, FEC, and RTCP packets would be marked this way. It keeps all the flow of processing the same as existing systems that are not using double. The reason the flag needs to be in the OBH is the system receiving the packets needs to know this information to be able to decrypt. > > I don't think that using RTX for creating wasted bandwidth via padding is a great idea but none the less, this would support that use of RTX. It also allows the Media Distributor, to look at the RTX payload to find the OSN (original Sequence Number) so that the Media Distributor, can do repair. A RTX sender would cache the packets it is sending (which are normal double encrypted) and when it got a request for a retransmission, it would take the cached packet to form the RTX packet to send. This is exactly how RTX works if the endpoint is not doing double so it is nice that it is the same. > > Below I will list a few options that I considered but view as significantly worse than the above proposal. > > 1. Send RTX/FEC non authenticated, do the repair, and if the repair packet validated, then consider it OK > > 2. Send RTX/FEC on separate steam that did not not negotiate double > > 3. When using RTX and double, create a new RTP header extension that provides the Media Distributor with the OSN in the header extension. The RTX packet would still have the OSN in it. > > 4. Leave RTX out of the first version of PERC and solve it as an extension to PERC later > > 5. Some sequence o extracting an inserting packets half way through the double transform. Among other problems with requires the endpoints to significantly change their flow when using double and problem involves updating many specs to have special text around double handling. > > 6. Simply use RTX in end to end way and not have the Media Distributor participate in RTX. > > 7. Do a new version of RTX that puts the OSN as a header extension instead of as a payload extension. > > > > > > > > > > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Mon Apr 10 07:25:35 2017 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 7C9E2129522 for ; Mon, 10 Apr 2017 07:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd6KqByGElrU for ; Mon, 10 Apr 2017 07:25:31 -0700 (PDT) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F811292AE for ; Mon, 10 Apr 2017 07:25:28 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 786025FE0; Mon, 10 Apr 2017 10:25:25 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id EF2975FDF; Mon, 10 Apr 2017 10:25:24 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 10 Apr 2017 10:25:25 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Mon, 10 Apr 2017 08:25:23 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> References: To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:25:34 -0000 Obviously if implementations cache and encrypted version or non = encrypted and then recreate is an implementation detail. Can you walk me = through how you think RTX works in a direct call from A to B wth normal = SRTP with no double and no PERC and no conference bridge? If we can get = to the point where it is clear we both understand that, then it might be = easier to have this discussion.=20 As a side note, I think it would be good to have an implementors email = list where we can help folks implementing this understand the existing = RFC specifications without doing it on the same list where we try and = develop new ones.=20 > On Apr 10, 2017, at 8:04 AM, Sergio Garcia Murillo = wrote: >=20 > Hi Cullen, >=20 > One thing I don't agree with is that currently RTX sender does not = store sent packets after applying the DTLS/SRTP transform, they store it = in clear. When a retransmission is requested, it retrieves the raw = packet, creates the RTX packet by appending the OSN and appending the = raw media and applies the DTLS/SRTP crypto to it. >=20 > In order to keep the same scheme in double, the RTX sender must keep = the rtp packets after the inner crypto is applied but before the outer = crypto is done. That way, when a retransmission is requested, it will = create a rtp packet with the OSN and append the media of the "inner = crypted" packet, and perform the outher crypto. >=20 > Also, not sure why we need to add a flag to the OHB header when RTX = and FEC packets are already defined by payload type, except if we want = to allow RTX/FEC both HBH and E2E. For RTCP it is not possible at all. >=20 > Best regards > Sergio >=20 > On 10/04/2017 15:35, Cullen Jennings wrote: >> I've looked at a bunch of options for how we could approach this. = Originally I planned to write them all up but the one that Nils (and = others) was talking about seems like a clear best one to me so let me = describe that then perhaps list some of the others ... >>=20 >> The goal of this is to keep the basic flow of information in your = average endpoint as close to possible as it is today and not need to = substantial change any existing specification when using double vs when = using other STLS-SRTP transforms. The goals is also not to just solve = the problems of RTX and FEC used today, but also be compatible with more = complex FEC schemes that might be done in the future which have far more = state that can become corrupted by un authenticated packets. >>=20 >> The basic approach is pretty simple. We add to the OBH block a flag = that indicates if that double algorithm does normal crypto where the = half the key is used for the inner encrypt, then 2nd half key used for = outer, or, if the flag is set, it only does the outer part. This allows = a packet that is meant for the Media Distributor, and does not contain a = payload that has non encrypted user media, to effectively be marked for = single, not double encryption. RTX, FEC, and RTCP packets would be = marked this way. It keeps all the flow of processing the same as = existing systems that are not using double. The reason the flag needs to = be in the OBH is the system receiving the packets needs to know this = information to be able to decrypt. >>=20 >> I don't think that using RTX for creating wasted bandwidth via = padding is a great idea but none the less, this would support that use = of RTX. It also allows the Media Distributor, to look at the RTX payload = to find the OSN (original Sequence Number) so that the Media = Distributor, can do repair. A RTX sender would cache the packets it is = sending (which are normal double encrypted) and when it got a request = for a retransmission, it would take the cached packet to form the RTX = packet to send. This is exactly how RTX works if the endpoint is not = doing double so it is nice that it is the same. >>=20 >> Below I will list a few options that I considered but view as = significantly worse than the above proposal. >>=20 >> 1. Send RTX/FEC non authenticated, do the repair, and if the repair = packet validated, then consider it OK >>=20 >> 2. Send RTX/FEC on separate steam that did not not negotiate double >>=20 >> 3. When using RTX and double, create a new RTP header extension that = provides the Media Distributor with the OSN in the header extension. The = RTX packet would still have the OSN in it. >>=20 >> 4. Leave RTX out of the first version of PERC and solve it as an = extension to PERC later >>=20 >> 5. Some sequence o extracting an inserting packets half way through = the double transform. Among other problems with requires the endpoints = to significantly change their flow when using double and problem = involves updating many specs to have special text around double = handling. >>=20 >> 6. Simply use RTX in end to end way and not have the Media = Distributor participate in RTX. >>=20 >> 7. Do a new version of RTX that puts the OSN as a header extension = instead of as a payload extension. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Mon Apr 10 07:47:29 2017 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 C5E6C129505 for ; Mon, 10 Apr 2017 07:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmn39FIE0Nl7 for ; Mon, 10 Apr 2017 07:47:24 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75655129434 for ; Mon, 10 Apr 2017 07:47:24 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l28so21106445wre.0 for ; Mon, 10 Apr 2017 07:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dRvZyj1+7CpzEb1wahtbqEC+zlv0vYy5p26LupIRQpU=; b=JGaNajJIGojkie1HCgGeem8gonHQGNYGiiTcS6zaKP/PpvL25cUZOK3JePIgocJGIL TEPhu9BTLtudI60GyuEq52WHcLl22UtIVnpt8pCX8/1T9cojCpn7gT3LeDyqed4crFpM G73ejeWBmcMC4xcxVCO0R9mhjOmQ1OQiKYExm+vTLGU9JUjDKthZJt4A8UCnfpscrx9T jq/gHm/R7lj7phAVh8aGszNEJOMHrb9zErgZt4NS57g+x4mJEamw2VCQtnFE4GXtivJq tNrQYgMeDJszmQZZYticB3gRYm+nwb/yvvYLFGZO1kUmFrLhOh0CKOMAVwcrOj0f9QQh 4fEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dRvZyj1+7CpzEb1wahtbqEC+zlv0vYy5p26LupIRQpU=; b=B1T6VFOz50OmKzofEoX8DhjZk2M1UfhaDBixqg7tXKBxYFIpDEe6jHTr5s0A3Q0TZI unr7GKFKmcTz7nwIY/9DFAjskbVx1xGqRxkM4dvyktSJflgKayDbWF/Xutd64pr8TJPV 6XzaYKpq2XPPXQ8f/zWN2R7IYEd6G5uSoyIbgM07MZLRF7ybXmX6V2fH+jhLlVPXhnQD QSdroq8DA0kyu1Ly4/2rBnRC4eeAZCMhefIZK+VzEQ3BdHBiHN9Y3S425SzLVa5gKxeF wNaxMd8+RZjRnWGrnvPclYMXTbm8qVYbKCcp825qOqJ7Vv2tig8ngofg1q5Q/EDtn/0g d4qw== X-Gm-Message-State: AFeK/H0zUF+VW2I9Wo7p6BSySQDEUhLoyLBg8COhpUUWPsvfLuZuhDfjjYal6cxSrOe73w== X-Received: by 10.223.144.8 with SMTP id h8mr43885727wrh.45.1491835642845; Mon, 10 Apr 2017 07:47:22 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id 134sm10529170wmj.6.2017.04.10.07.47.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 07:47:21 -0700 (PDT) To: Cullen Jennings References: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> Date: Mon, 10 Apr 2017 16:47:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:47:27 -0000 Hi Cullen, I was in disagreement with your implementation details, so if we leave them out (or just keep it as informative discussion or on a different list), I am fine. If I understood the core of your proposal correctly, I think we are in agreement that FEC/RTX (how about RED?) and RTCP are HBH and only outer encrypted. I still have doubts about the usage of the OHB and the need of this flags as all the sender/receiver and MD already are able to differentiate FEC/RTC/RED/RTCP from media payloads and I don't see other scenarios in which we would want to use that flag in a more generic way. Best regards Sergio On 10/04/2017 16:25, Cullen Jennings wrote: > Obviously if implementations cache and encrypted version or non encrypted and then recreate is an implementation detail. Can you walk me through how you think RTX works in a direct call from A to B wth normal SRTP with no double and no PERC and no conference bridge? If we can get to the point where it is clear we both understand that, then it might be easier to have this discussion. > > As a side note, I think it would be good to have an implementors email list where we can help folks implementing this understand the existing RFC specifications without doing it on the same list where we try and develop new ones. > > >> On Apr 10, 2017, at 8:04 AM, Sergio Garcia Murillo wrote: >> >> Hi Cullen, >> >> One thing I don't agree with is that currently RTX sender does not store sent packets after applying the DTLS/SRTP transform, they store it in clear. When a retransmission is requested, it retrieves the raw packet, creates the RTX packet by appending the OSN and appending the raw media and applies the DTLS/SRTP crypto to it. >> >> In order to keep the same scheme in double, the RTX sender must keep the rtp packets after the inner crypto is applied but before the outer crypto is done. That way, when a retransmission is requested, it will create a rtp packet with the OSN and append the media of the "inner crypted" packet, and perform the outher crypto. >> >> Also, not sure why we need to add a flag to the OHB header when RTX and FEC packets are already defined by payload type, except if we want to allow RTX/FEC both HBH and E2E. For RTCP it is not possible at all. >> >> Best regards >> Sergio >> >> On 10/04/2017 15:35, Cullen Jennings wrote: >>> I've looked at a bunch of options for how we could approach this. Originally I planned to write them all up but the one that Nils (and others) was talking about seems like a clear best one to me so let me describe that then perhaps list some of the others ... >>> >>> The goal of this is to keep the basic flow of information in your average endpoint as close to possible as it is today and not need to substantial change any existing specification when using double vs when using other STLS-SRTP transforms. The goals is also not to just solve the problems of RTX and FEC used today, but also be compatible with more complex FEC schemes that might be done in the future which have far more state that can become corrupted by un authenticated packets. >>> >>> The basic approach is pretty simple. We add to the OBH block a flag that indicates if that double algorithm does normal crypto where the half the key is used for the inner encrypt, then 2nd half key used for outer, or, if the flag is set, it only does the outer part. This allows a packet that is meant for the Media Distributor, and does not contain a payload that has non encrypted user media, to effectively be marked for single, not double encryption. RTX, FEC, and RTCP packets would be marked this way. It keeps all the flow of processing the same as existing systems that are not using double. The reason the flag needs to be in the OBH is the system receiving the packets needs to know this information to be able to decrypt. >>> >>> I don't think that using RTX for creating wasted bandwidth via padding is a great idea but none the less, this would support that use of RTX. It also allows the Media Distributor, to look at the RTX payload to find the OSN (original Sequence Number) so that the Media Distributor, can do repair. A RTX sender would cache the packets it is sending (which are normal double encrypted) and when it got a request for a retransmission, it would take the cached packet to form the RTX packet to send. This is exactly how RTX works if the endpoint is not doing double so it is nice that it is the same. >>> >>> Below I will list a few options that I considered but view as significantly worse than the above proposal. >>> >>> 1. Send RTX/FEC non authenticated, do the repair, and if the repair packet validated, then consider it OK >>> >>> 2. Send RTX/FEC on separate steam that did not not negotiate double >>> >>> 3. When using RTX and double, create a new RTP header extension that provides the Media Distributor with the OSN in the header extension. The RTX packet would still have the OSN in it. >>> >>> 4. Leave RTX out of the first version of PERC and solve it as an extension to PERC later >>> >>> 5. Some sequence o extracting an inserting packets half way through the double transform. Among other problems with requires the endpoints to significantly change their flow when using double and problem involves updating many specs to have special text around double handling. >>> >>> 6. Simply use RTX in end to end way and not have the Media Distributor participate in RTX. >>> >>> 7. Do a new version of RTX that puts the OSN as a header extension instead of as a payload extension. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 From nobody Mon Apr 10 10:35:27 2017 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 BAA9A129A99 for ; Mon, 10 Apr 2017 10:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qbWf7CqoffGi for ; Mon, 10 Apr 2017 10:35:18 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 9AF70129AA6 for ; Mon, 10 Apr 2017 10:35:15 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id f22so26466512oib.2 for ; Mon, 10 Apr 2017 10:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TlKXLo8V7Kl9jGwh4cWVeQWM9Yoz1+itt/S5EKwc7Xw=; b=Os3EuBjn9HitTe4VLYqWrQlT52XNtEmU00DQwidcqTxlutaqaCyPH9+HbwwmbxpyAJ qB2TIKPcXZnZw75lABxbEJtnhuOVEKhay6oNcUWWNJRgVoV5zP4AxWaZzEseBi1d9OQm xE3MRts4woGqddI16tO0Bk2L+4UaIElKDUmriShDo7s+hx2Kvs4NCOkCKU2n1a246ln5 kLGnCBPvBlea0zggsG6kJYJq33LsrkdqIwj4UFrIcXzubUMmLBcxDd/MuPQGy7R3sBGT iQ7vO8bgTV0Sdv88HL3gjETW7eC1f0RmkLQAEyi4TPsyqY1bJLqyNw2PWClqnYUFoyxR hflQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TlKXLo8V7Kl9jGwh4cWVeQWM9Yoz1+itt/S5EKwc7Xw=; b=Dp4JLxSb/XJsOqOMAmh6A/Z9STnil2uLyr7wkMPmqocI3LqrRLwgdSYwLa9RTPFcTN NhOJwEu/fjF2LuGMAxMQIfodix0X4YvBTY0rp34Wr/ywWqT5TynisjMjwYuljJqzD+nc JB1cOwfRjSVpWGgGiXV23vrqZk7rzQRWrC++pGOhjNB/bymyxDQ/vhOQJZ9uGMjHgvVr yU9DcZX0STDdOck/nI879qKXNl8MjVfJw2E3DytUxeYKS1TDxrmRbNZeeJveonR2E1GM aPHWLKCUz1ZrpBXlS4uoeeDVCBaP9+oN1gl/5ugLi9k5UiecoIDqAud2K34pBHCwvC4w g8Yw== X-Gm-Message-State: AN3rC/7qCwCmbxbKkiiZ4ktNeuu6cEX4FoeIHMMkLGBt/1OVowiwVTXScxu+gf8TkuoVski9HQsSe7dOh3Fa1Q== X-Received: by 10.157.41.229 with SMTP id g34mr14145404otd.44.1491845714858; Mon, 10 Apr 2017 10:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Mon, 10 Apr 2017 10:35:14 -0700 (PDT) In-Reply-To: <89E57A5F-1C30-4346-AF9B-B58927C17F38@iii.ca> References: <9da7d462-9115-c608-6594-ef6a0df6a19a@gmail.com> <89E57A5F-1C30-4346-AF9B-B58927C17F38@iii.ca> From: Stephen Botzko Date: Mon, 10 Apr 2017 13:35:14 -0400 Message-ID: To: Cullen Jennings Cc: Sergio Garcia Murillo , perc@ietf.org Content-Type: multipart/alternative; boundary=001a114090ece4d951054cd36536 Archived-At: Subject: Re: [Perc] DTMF and Double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:35:22 -0000 --001a114090ece4d951054cd36536 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 10, 2017 at 9:28 AM, Cullen Jennings wrote: > > > On Apr 4, 2017, at 4:22 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > > > Hi all, > > > > Hate to ask this, but I have one more doubt when making changes to > libwertc to support double. Should DTMF be also double protected or we > should send it HBH? > > > > At least on webrtc, browsers are only meant to send DTMF, not receive > them, so it would make sense to end them at the SFU and not propagate it to > the other participants. > > > > Best regards > > > > Sergio > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > DTMF send in RTP should be treated just like any other media. There are > PERC use cases where we do want DTMF to get to the far end and be E2E > protected. Keep in mind PERC is meant to work with WebRTC but also with > things other than WebRTC. If and endpoint wants to signal things to the MD > ( like mute ), then there are much better ways than using DTMF to do that. > [sb]There are *always* much better ways than using DTMF for anything, including PERC e2e. So that sword cuts both ways. IMO there are use cases for both e2e and h2h. The OHB flag proposal actually enables both, if we wanted to allow it. Note I'm not saying we *should* allow it, just that we *could*. Supporting both ways in the same implementation would be difficult to explain clearly to users.[/sb] > > > > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a114090ece4d951054cd36536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 10, 2017 at 9:28 AM, Cullen Jennings <= fluffy@iii.ca> wrote:

> On Apr 4, 2017, at 4:22 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com= > wrote:
>
> Hi all,
>
> Hate to ask this, but I have one more doubt when making changes to lib= wertc to support double. Should DTMF be also double protected or we should = send it HBH?
>
> At least on webrtc, browsers are only meant to send DTMF, not receive = them, so it would make sense to end them at the SFU and not propagate it to= the other participants.
>
> Best regards
>
> Sergio
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
DTMF send in RTP should be treated just like any other media. T= here are PERC use cases where we do want DTMF to get to the far end and be = E2E protected. Keep in mind PERC is meant to work with WebRTC but also with= things other than WebRTC. If and endpoint wants to signal things to the MD= ( like mute ), then there are much better ways than using DTMF to do that.=
[sb]There are always much better ways than usi= ng DTMF for anything, including PERC e2e.=C2=A0 So that sword cuts both way= s.

IMO there are use cases for both e2e and h2h.= =C2=A0 The OHB flag proposal actually enables both, if we wanted to allow i= t.=C2=A0 Note I'm not saying we should allow it, just that we could.=C2=A0 Supporting both ways in the same implementation would be = difficult to explain clearly to users.[/sb]






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

--001a114090ece4d951054cd36536-- From nobody Mon Apr 10 15:25:59 2017 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 287691293E8 for ; Mon, 10 Apr 2017 15:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4msxLsOACBo for ; Mon, 10 Apr 2017 15:25:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A8E1293E4 for ; Mon, 10 Apr 2017 15:25:55 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3AMPp9J080146 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 10 Apr 2017 17:25:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Sergio Garcia Murillo , Cullen Jennings References: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> Cc: perc@ietf.org From: Adam Roach Message-ID: <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> Date: Mon, 10 Apr 2017 17:25:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 22:25:58 -0000 On 4/10/17 09:47, Sergio Garcia Murillo wrote: > If I understood the core of your proposal correctly, I think we are in > agreement that FEC/RTX (how about RED?) and RTCP are HBH and only > outer encrypted. I still have doubts about the usage of the OHB and > the need of this flags as all the sender/receiver and MD already are > able to differentiate FEC/RTC/RED/RTCP from media payloads and I don't > see other scenarios in which we would want to use that flag in a more > generic way. (a) Using the SDP-negotiated PT value to determine what kind of SRTP encryption and decryption to apply is really strange, from a layering perspective. It requires the code that receives packets to have a mapping of PT values to codecs, and I would not expect any libraries that do that kind of thing to already have a notion of PT-to-codec mapping already. Thinking through what it would take to add this, the additional plumbing to get the socket handling code or the SRTP code to understand PTs is pretty convoluted. (b) The use of a client-supplied bit in the OHB reduces questions like "should we double encrypt DTMF" to a policy question rather than a protocol question -- and this includes not just DTMF, but any kind of FEC/RTX/RED-type stuff that may be developed in the future. /a From nobody Tue Apr 11 01:03:36 2017 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 9C047129410 for ; Tue, 11 Apr 2017 01:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgdW5BHn6GoB for ; Tue, 11 Apr 2017 01:03:32 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 AE835129404 for ; Tue, 11 Apr 2017 01:03:19 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id z109so23346527wrb.1 for ; Tue, 11 Apr 2017 01:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=btm29x5LNbVcwgfcphP9MoO8y3ha4KxTcVRsa7r7kMo=; b=ufAQLyUR0jCH31AmKevac+5wqOC5dm8gcpmwv8E7bDIHCSA24towjEmLV08QFiWVsh HCmZnIXZcLNYzqBFcp2vQLsdRNrgSXIikeussBt3Rg3yvMpfenU4F4kbhSL9QlNmlR8C uD+9T+V5SgycANHPmQHvj4AxYF7fIhc17g2TqMHHSGLv3E0xUI+bHCj4mFKoFSw9Jglr c/DLcK16pBDKRNJvQg2qwcPRdbonTppPXKrJP2M6SB3yiWKnLvdEvvDNVzqAXJKDmnOy lXeccCfj+FMLg9tE3kCJBDr7R2BXpgRQiEZUTz0u/IsuVDWUNKMzxZ7rrTfvp3zuk8uz qbog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=btm29x5LNbVcwgfcphP9MoO8y3ha4KxTcVRsa7r7kMo=; b=nbBeV7b2ylQ35QKO4iq6lfE3PpZOD1D/axp1J2cW+JdyUI7BE9yDZAMIIce8tf1ADP kjrc9GrVx6E6IVof4gsjfISab7UsEtkrHPDeQTWfhSlmPKIRjaNqAUWDiQqtXrurk1+D how/Rbt/OCJfrstPUx/Z/Ex1AIA9MQmzmTyll3XXf7Mnjn2t7GegCu323yuygTrSCrer wOQepLziUX0GId1HuJoadkNJEI362Ju5t+ut77Qpsrv7lN6wqSlZItokfUKopv8cJj4w KH/C7gNHbJcWVZ/ikx4MUFoL3n1UtUrysrxh6FM3wBIk8ryG0PWQg37J5kauJlzop9yT yMZQ== X-Gm-Message-State: AFeK/H1z2WgkPQp/XhtRp3H2kfevlNF7tY73iirCRGj/d/3uzzMfFk3eaxWOWjx/eLBZLg== X-Received: by 10.223.142.143 with SMTP id q15mr28449471wrb.180.1491897797933; Tue, 11 Apr 2017 01:03:17 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id 75sm2429395wmp.2.2017.04.11.01.03.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 01:03:16 -0700 (PDT) To: Adam Roach , Cullen Jennings References: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <173821b1-a007-ba0f-a837-d51e71a5a33f@gmail.com> Date: Tue, 11 Apr 2017 10:03:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 08:03:35 -0000 On 11/04/2017 0:25, Adam Roach wrote: > On 4/10/17 09:47, Sergio Garcia Murillo wrote: >> If I understood the core of your proposal correctly, I think we are >> in agreement that FEC/RTX (how about RED?) and RTCP are HBH and only >> outer encrypted. I still have doubts about the usage of the OHB and >> the need of this flags as all the sender/receiver and MD already are >> able to differentiate FEC/RTC/RED/RTCP from media payloads and I >> don't see other scenarios in which we would want to use that flag in >> a more generic way. > > > (a) Using the SDP-negotiated PT value to determine what kind of SRTP > encryption and decryption to apply is really strange, from a layering > perspective. It requires the code that receives packets to have a > mapping of PT values to codecs, and I would not expect any libraries > that do that kind of thing to already have a notion of PT-to-codec > mapping already. Thinking through what it would take to add this, the > additional plumbing to get the socket handling code or the SRTP code > to understand PTs is pretty convoluted. > You are assuming that we enable both E2E and HBH for RTX, with IMHO is a bad idea (more on that later). If only HBH RTX is supported you don't even need to change a single line of code, as the inner crypto will be done after the RTX processing takes place, for both media and rtx packets. > (b) The use of a client-supplied bit in the OHB reduces questions like > "should we double encrypt DTMF" to a policy question rather than a > protocol question -- and this includes not just DTMF, but any kind of > FEC/RTX/RED-type stuff that may be developed in the future. Let's imagine that we support both HBH and E2E RTX modes, there are new several question raised. First, are those H2B or E2E RTX modes negotiated? Does NACK packet carries a new flag to indicate if it wants it to be HBH or E2E? An SFU requires it to be HBH, so leaving it to a sender only decision, it may make RTX unusable at all for conferencing. Also, if we leave it to a sender only decision, it will only send HBH RTX as it is the only sensible decision nowadays. Then, I assume that if "encrypted flag" is used on an RTX packet it just means that the inner crypto is used or not, but the RTX payload is still the same. That means that a double encrypted RTX packet will carry inner crypto payload from the original packet (if not we will be requiring developers to implement too different double encryption mechanisms and not just a "flag"). In that case, we need to carry the original OHB for the inner crypto original packet, and a second OHB for the RTX inner crytpo packet. The receiver will be then able two support two different header extensions for same id and I assume remove the latest OHB but keep the first OHB when reconstructing the original packet. Really, not sure if pushing this kind of complexity to developers is a good idea, especially as I have yet to see an use case in which E2E RTX makes sense. Best regard Sergio From nobody Tue Apr 11 11:00:35 2017 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 3FAB012EB59 for ; Tue, 11 Apr 2017 11:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 rwgDujorHxiX for ; Tue, 11 Apr 2017 11:00:31 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C9BF212EB32 for ; Tue, 11 Apr 2017 11:00:30 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id g204so5876315oib.1 for ; Tue, 11 Apr 2017 11:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z17AL1/CWzITDQGcxN7zAIT8A/c2v+KDhF51uxuDJFQ=; b=G9i2m3RQ5gh3cf78A7uJo70XRTpQXkkr7q6xbvQ3bHRXmY1TDzzbIPNgJUlxT6JHc/ lqkRQv83QEExSTwR3jCT8JxJKkFv4rNkccX+/qxgPp+lfkRxcrbZIL9abQ9NaJqkQup/ FnPSjW+XJW9oEFlN6rJRSq2R3Vdhns3yn06UoGbGu2SB+1OFt2aG7KsH4xJylLbHhbBA mzrbOwBONmVHUqRpqPJyBTvibOnXP4Xeeospu1mCIYnWEjp0PKa5vcQtg+ZnyePGWDM4 4FWITdoQpHu/AOQpyw4K8ET9vBn6vEnxO4evmIaEmOJb1oMdC/w368fsz4zeoDMiUUqW K7uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z17AL1/CWzITDQGcxN7zAIT8A/c2v+KDhF51uxuDJFQ=; b=UnV8Lhqu70wMG4IFOlOwkr+GoODVAGjuCdJ7aRiBR6rGZJkjk2QKcKegOWmVztnbx7 DDWqGsv5eVUOxRAIFUJ527Iif+tNuXrttXsZNB0gHJ5WfB1YbBn4beKusPSZ4eVO6A5O M/gYhWudimXlU8G7h4TblabRGb4L0NAVQ81dl4/Sc5tWM6bpnK9DXxy+nFsGDr3jlZ23 ilNgJ3UjBwhlOm8DXsEYSb7DGwmh6/gtYBbWCQSqacvU/3CBY7MR0lLj3I7Y9iirCzik vk6orYfp2SaQE2q+MkJY2HptDHLIWpv5oRvFl9bbqRSeZHpnXLdaRKOsUBfK9Cmd6RJ6 8FTA== X-Gm-Message-State: AN3rC/7hLjT4BXmNEKwjuBYh+yTBzIQhwqARC7Ul4QgmXhv3NntrsuDqGg5rNVuCEANXe0Rl660XPBZtUnt8dQ== X-Received: by 10.157.33.97 with SMTP id l30mr8843471otd.53.1491933630060; Tue, 11 Apr 2017 11:00:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Tue, 11 Apr 2017 11:00:29 -0700 (PDT) In-Reply-To: <173821b1-a007-ba0f-a837-d51e71a5a33f@gmail.com> References: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> <173821b1-a007-ba0f-a837-d51e71a5a33f@gmail.com> From: Stephen Botzko Date: Tue, 11 Apr 2017 14:00:29 -0400 Message-ID: To: Sergio Garcia Murillo Cc: Adam Roach , Cullen Jennings , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113b05060c6079054ce7de04 Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:00:33 -0000 --001a113b05060c6079054ce7de04 Content-Type: text/plain; charset=UTF-8 Per the minutes, there's supposed to be a focused call on how to handle repair streams. Is that scheduled yet? Stephen On Tue, Apr 11, 2017 at 4:03 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 11/04/2017 0:25, Adam Roach wrote: > >> On 4/10/17 09:47, Sergio Garcia Murillo wrote: >> >>> If I understood the core of your proposal correctly, I think we are in >>> agreement that FEC/RTX (how about RED?) and RTCP are HBH and only outer >>> encrypted. I still have doubts about the usage of the OHB and the need of >>> this flags as all the sender/receiver and MD already are able to >>> differentiate FEC/RTC/RED/RTCP from media payloads and I don't see other >>> scenarios in which we would want to use that flag in a more generic way. >>> >> >> >> (a) Using the SDP-negotiated PT value to determine what kind of SRTP >> encryption and decryption to apply is really strange, from a layering >> perspective. It requires the code that receives packets to have a mapping >> of PT values to codecs, and I would not expect any libraries that do that >> kind of thing to already have a notion of PT-to-codec mapping already. >> Thinking through what it would take to add this, the additional plumbing to >> get the socket handling code or the SRTP code to understand PTs is pretty >> convoluted. >> >> > You are assuming that we enable both E2E and HBH for RTX, with IMHO is a > bad idea (more on that later). If only HBH RTX is supported you don't even > need to change a single line of code, as the inner crypto will be done > after the RTX processing takes place, for both media and rtx packets. > > (b) The use of a client-supplied bit in the OHB reduces questions like >> "should we double encrypt DTMF" to a policy question rather than a protocol >> question -- and this includes not just DTMF, but any kind of >> FEC/RTX/RED-type stuff that may be developed in the future. >> > > Let's imagine that we support both HBH and E2E RTX modes, there are new > several question raised. First, are those H2B or E2E RTX modes negotiated? > Does NACK packet carries a new flag to indicate if it wants it to be HBH or > E2E? An SFU requires it to be HBH, so leaving it to a sender only decision, > it may make RTX unusable at all for conferencing. Also, if we leave it to > a sender only decision, it will only send HBH RTX as it is the only > sensible decision nowadays. > > Then, I assume that if "encrypted flag" is used on an RTX packet it just > means that the inner crypto is used or not, but the RTX payload is still > the same. That means that a double encrypted RTX packet will carry inner > crypto payload from the original packet (if not we will be requiring > developers to implement too different double encryption mechanisms and not > just a "flag"). > > In that case, we need to carry the original OHB for the inner crypto > original packet, and a second OHB for the RTX inner crytpo packet. The > receiver will be then able two support two different header extensions for > same id and I assume remove the latest OHB but keep the first OHB when > reconstructing the original packet. > > Really, not sure if pushing this kind of complexity to developers is a > good idea, especially as I have yet to see an use case in which E2E RTX > makes sense. > > Best regard > Sergio > > > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a113b05060c6079054ce7de04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per the minutes, there's supposed to be a focused call= on how to handle repair streams.=C2=A0 Is that scheduled yet?

Stephen

On Tue, Apr 11, 2017 at 4:03 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 11/04/2017 0:25, Adam Roach wrote:<= br>
On 4/10/17 09:47, Sergio Garcia Murillo wrote:
If I understood the core of your proposal correctly, I think we are in agre= ement that FEC/RTX (how about RED?) and RTCP are HBH and only outer encrypt= ed. I still have doubts about the usage of the OHB and the need of this fla= gs as all the sender/receiver and MD already are able to differentiate FEC/= RTC/RED/RTCP from media payloads and I don't see other scenarios in whi= ch we would want to use that flag in a more generic way.


(a) Using the SDP-negotiated PT value to determine what kind of SRTP encryp= tion and decryption to apply is really strange, from a layering perspective= . It requires the code that receives packets to have a mapping of PT values= to codecs, and I would not expect any libraries that do that kind of thing= to already have a notion of PT-to-codec mapping already. Thinking through = what it would take to add this, the additional plumbing to get the socket h= andling code or the SRTP code to understand PTs is pretty convoluted.


You are assuming that we enable both E2E and HBH for RTX, with IMHO is a ba= d idea (more on that later). If only HBH RTX is supported you don't eve= n need to change a single line of code, as the inner crypto will be done af= ter the RTX processing takes place, for both media and rtx packets.

(b) The use of a client-supplied bit in the OHB reduces questions like &quo= t;should we double encrypt DTMF" to a policy question rather than a pr= otocol question -- and this includes not just DTMF, but any kind of FEC/RTX= /RED-type stuff that may be developed in the future.

Let's imagine that we support both HBH and E2E RTX modes, there are new= several question raised. First, are those H2B or E2E RTX modes negotiated?= Does NACK packet carries a new flag to indicate if it wants it to be HBH o= r E2E? An SFU requires it to be HBH, so leaving it to a sender only decisio= n, it may make RTX unusable at all for conferencing.=C2=A0 Also, if we leav= e it to a sender only decision, it will only send HBH RTX as it is the only= sensible decision nowadays.

Then, I assume that if "encrypted flag" is used on an RTX packet = it just means that the inner crypto is used or not, but the RTX payload is = still the same. That means that a double encrypted RTX packet will carry in= ner crypto payload from the original packet (if not we will be requiring de= velopers to implement too different double encryption mechanisms and not ju= st a "flag").

In that case, we need to carry the original OHB for the inner crypto origin= al packet, and a second OHB for the RTX inner crytpo packet. The receiver w= ill be then able two support two different header extensions for same id an= d I assume remove the latest OHB but keep the first OHB when reconstructing= the original packet.

Really, not sure if pushing this kind of complexity to developers is a good= idea, especially as I have yet to see an use case in which E2E RTX makes s= ense.

Best regard
Sergio





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

--001a113b05060c6079054ce7de04-- From nobody Tue Apr 11 11:01:20 2017 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 75864129510 for ; Tue, 11 Apr 2017 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km_QZd7FAFdI for ; Tue, 11 Apr 2017 11:01:16 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 A3E2512957A for ; Tue, 11 Apr 2017 11:01:15 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id c55so2977395wrc.3 for ; Tue, 11 Apr 2017 11:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W1n10vKJFAyt8xJl8RRNaFu3beg0mF63jeMYqFUYNWs=; b=RKApjjuAnvhrvVdEnovyfYTp7Q2JNvETrQXaccL2UQlpuXrm4hocE8Y8tf1hkSI5pr Tiu78TUQX0V+3X+gBnHWFBwSLtXoiG+70R+RXGB8yZdbnbQGGQW6ZwytKmPozmPMN9tt jpm4FP+wVHqtypfbmMFF06uIq82Iu7JlNKeQK/HSU0Y10XGOFceWf45w1Z352iR/g8BN 16xk3mIvalN2EnfvY+PGp1YMN12v+Zet/HbJJsXMQy3PFuSkty9rxDT1/q8JXVwb1A2g D6zbC6BGpjuTf+LwkVzQunc93Y8NWsw1FELX4fSsK94PaM71zvIn5XKsIufqEiQTpiWu 3ybA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W1n10vKJFAyt8xJl8RRNaFu3beg0mF63jeMYqFUYNWs=; b=QXkEByGaejw/RUkFIUNFhD/84Z5Lue9Fc8Em6CPy7OA7rgU5AoOAwAyDugpOqQDc37 1R/zAK0Gjdw8YwnwCsHYJ0GQNiAJZf2scVgIZcFYLN3jF6JU0VkJ9URoV+XZOLIj3azC /tFeZm5GTiIHTW+SqqgyYq8qUequ1yB6B6md67elpOndD9LUDSBE0xntzJwg7I9gXzYw 6uyaTtm9g7ebDxsN7Pu4lgv81gWE+Y1ASexbM3CwfqBJ1GyIYzhz4BIVfqkp8Jgd6H+V 9ttT6X5SsMmSdA+UkpKQ7PO76773O+Hx3RJCHJYAU7fd71fqHIN+uFqN1RD9WJTd4GrT 8sUg== X-Gm-Message-State: AFeK/H2qjBzhhcCdV/oQ+QqqC5XyvO4zMn1aR+TX44CdotVLFqBo6Zcd5k5D9xrux8K9IgVWxPmXdfFc39pkEw== X-Received: by 10.223.142.143 with SMTP id q15mr31024028wrb.180.1491933673918; Tue, 11 Apr 2017 11:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Tue, 11 Apr 2017 11:01:13 -0700 (PDT) In-Reply-To: References: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> <173821b1-a007-ba0f-a837-d51e71a5a33f@gmail.com> From: Richard Barnes Date: Tue, 11 Apr 2017 14:01:13 -0400 Message-ID: To: Stephen Botzko Cc: Sergio Garcia Murillo , Adam Roach , perc@ietf.org, Cullen Jennings Content-Type: multipart/alternative; boundary=f403045f517ca9b796054ce7e01a Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:01:18 -0000 --f403045f517ca9b796054ce7e01a Content-Type: text/plain; charset=UTF-8 No. Suhas and I are gathering dates to propose. On Tue, Apr 11, 2017 at 2:00 PM, Stephen Botzko wrote: > Per the minutes, there's supposed to be a focused call on how to handle > repair streams. Is that scheduled yet? > > Stephen > > On Tue, Apr 11, 2017 at 4:03 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> On 11/04/2017 0:25, Adam Roach wrote: >> >>> On 4/10/17 09:47, Sergio Garcia Murillo wrote: >>> >>>> If I understood the core of your proposal correctly, I think we are in >>>> agreement that FEC/RTX (how about RED?) and RTCP are HBH and only outer >>>> encrypted. I still have doubts about the usage of the OHB and the need of >>>> this flags as all the sender/receiver and MD already are able to >>>> differentiate FEC/RTC/RED/RTCP from media payloads and I don't see other >>>> scenarios in which we would want to use that flag in a more generic way. >>>> >>> >>> >>> (a) Using the SDP-negotiated PT value to determine what kind of SRTP >>> encryption and decryption to apply is really strange, from a layering >>> perspective. It requires the code that receives packets to have a mapping >>> of PT values to codecs, and I would not expect any libraries that do that >>> kind of thing to already have a notion of PT-to-codec mapping already. >>> Thinking through what it would take to add this, the additional plumbing to >>> get the socket handling code or the SRTP code to understand PTs is pretty >>> convoluted. >>> >>> >> You are assuming that we enable both E2E and HBH for RTX, with IMHO is a >> bad idea (more on that later). If only HBH RTX is supported you don't even >> need to change a single line of code, as the inner crypto will be done >> after the RTX processing takes place, for both media and rtx packets. >> >> (b) The use of a client-supplied bit in the OHB reduces questions like >>> "should we double encrypt DTMF" to a policy question rather than a protocol >>> question -- and this includes not just DTMF, but any kind of >>> FEC/RTX/RED-type stuff that may be developed in the future. >>> >> >> Let's imagine that we support both HBH and E2E RTX modes, there are new >> several question raised. First, are those H2B or E2E RTX modes negotiated? >> Does NACK packet carries a new flag to indicate if it wants it to be HBH or >> E2E? An SFU requires it to be HBH, so leaving it to a sender only decision, >> it may make RTX unusable at all for conferencing. Also, if we leave it to >> a sender only decision, it will only send HBH RTX as it is the only >> sensible decision nowadays. >> >> Then, I assume that if "encrypted flag" is used on an RTX packet it just >> means that the inner crypto is used or not, but the RTX payload is still >> the same. That means that a double encrypted RTX packet will carry inner >> crypto payload from the original packet (if not we will be requiring >> developers to implement too different double encryption mechanisms and not >> just a "flag"). >> >> In that case, we need to carry the original OHB for the inner crypto >> original packet, and a second OHB for the RTX inner crytpo packet. The >> receiver will be then able two support two different header extensions for >> same id and I assume remove the latest OHB but keep the first OHB when >> reconstructing the original packet. >> >> Really, not sure if pushing this kind of complexity to developers is a >> good idea, especially as I have yet to see an use case in which E2E RTX >> makes sense. >> >> Best regard >> Sergio >> >> >> >> >> >> _______________________________________________ >> 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 > > --f403045f517ca9b796054ce7e01a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No.=C2=A0 Suhas and I are gathering dates to propose.
<= /div>

On Tue, Apr = 11, 2017 at 2:00 PM, Stephen Botzko <stephen.botzko@gmail.com&g= t; wrote:
Per the= minutes, there's supposed to be a focused call on how to handle repair= streams.=C2=A0 Is that scheduled yet?

Stephen

On Tue, Apr 11, 2017 at 4:03 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 11/04/2017 0:25, Adam Roach wrote:
On 4/10/17 09:47, Sergio Garcia Murillo wrote:
If I understood the core of your proposal correctly, I think we are in agre= ement that FEC/RTX (how about RED?) and RTCP are HBH and only outer encrypt= ed. I still have doubts about the usage of the OHB and the need of this fla= gs as all the sender/receiver and MD already are able to differentiate FEC/= RTC/RED/RTCP from media payloads and I don't see other scenarios in whi= ch we would want to use that flag in a more generic way.


(a) Using the SDP-negotiated PT value to determine what kind of SRTP encryp= tion and decryption to apply is really strange, from a layering perspective= . It requires the code that receives packets to have a mapping of PT values= to codecs, and I would not expect any libraries that do that kind of thing= to already have a notion of PT-to-codec mapping already. Thinking through = what it would take to add this, the additional plumbing to get the socket h= andling code or the SRTP code to understand PTs is pretty convoluted.


You are assuming that we enable both E2E and HBH for RTX, with IMHO is a ba= d idea (more on that later). If only HBH RTX is supported you don't eve= n need to change a single line of code, as the inner crypto will be done af= ter the RTX processing takes place, for both media and rtx packets.
(b) The use of a client-supplied bit in the OHB reduces questions like &quo= t;should we double encrypt DTMF" to a policy question rather than a pr= otocol question -- and this includes not just DTMF, but any kind of FEC/RTX= /RED-type stuff that may be developed in the future.

Let's imagine that we support both HBH and E2E RTX modes, there are new= several question raised. First, are those H2B or E2E RTX modes negotiated?= Does NACK packet carries a new flag to indicate if it wants it to be HBH o= r E2E? An SFU requires it to be HBH, so leaving it to a sender only decisio= n, it may make RTX unusable at all for conferencing.=C2=A0 Also, if we leav= e it to a sender only decision, it will only send HBH RTX as it is the only= sensible decision nowadays.

Then, I assume that if "encrypted flag" is used on an RTX packet = it just means that the inner crypto is used or not, but the RTX payload is = still the same. That means that a double encrypted RTX packet will carry in= ner crypto payload from the original packet (if not we will be requiring de= velopers to implement too different double encryption mechanisms and not ju= st a "flag").

In that case, we need to carry the original OHB for the inner crypto origin= al packet, and a second OHB for the RTX inner crytpo packet. The receiver w= ill be then able two support two different header extensions for same id an= d I assume remove the latest OHB but keep the first OHB when reconstructing= the original packet.

Really, not sure if pushing this kind of complexity to developers is a good= idea, especially as I have yet to see an use case in which E2E RTX makes s= ense.

Best regard
Sergio





_______________________________________________
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


--f403045f517ca9b796054ce7e01a-- From nobody Tue Apr 11 12:03:34 2017 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 3371412EB72 for ; Tue, 11 Apr 2017 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=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 c1T1TRUGwcui for ; Tue, 11 Apr 2017 12:03:31 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 5EDAE12EC34 for ; Tue, 11 Apr 2017 12:03:23 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w64so71265073wma.0 for ; Tue, 11 Apr 2017 12:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Da/Bm4btUH5bKNiPGjyPJpXMMg907qxZuH6/kKAFT6k=; b=OACtTuw0ZfK/C/Xi6/B9MjNvmdFRG+1m2L51YY0E5B/jNIW04lCNYdY4yyFcjSDl6R Q5fpaghZX+5L/MoBlFq2H7jMu3CyVDZalF8boA9znHmtC4fEdkrkuMfvMg0c/rmyJoYS LoINSpV+h8AS04/eJhXsY+ciw1aQ2KLpnIA9lepVUK6e+MybINPCbu7JUZT/nmepntFB LH/DE3Psgsoz0A89w/RyocbxMpAPOUrrrT/1bEPx489AaD1UeKi+YDrrzT2FZXS02RZM 2B82Y1QnnALcTspFLWxKNQLReWFlLmRmuU/39cBPPlei+OF6oguqA1LQ4GfVMaWL6/76 hIMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Da/Bm4btUH5bKNiPGjyPJpXMMg907qxZuH6/kKAFT6k=; b=UbTO1/3BYZTYDqxFz63op2xlyftS1XW6jZbqsdW2LmbNNKsTCCFhuRyvzJEXvLC4So 8/HdJJ+I6IJrOLK0kdifVH8PsC1ksixUNBkoCYNjEKeEFNDQw2/o7jdcuAFZtPLyDpE6 L6AZxPdfFA2+KEZx8VH6HgmUIwpwRU4kqvaVsksC2ZDomsgdOOB9uIkHMaWUmYjXMF49 1npvJ8spXjpHrztu/cn5WIIx/gXEfFEfcP+eLBfWeJgGiJgTt8EbdLT/A0v+7PsypKBS Qrv2QuS7VdlknJvrTjkpy+GsQdC7rb0IdeOuVB03Sk6ECwY0eSgSvnadkHEfuQ+uJRn0 BxXQ== X-Gm-Message-State: AN3rC/6lC/ABmlcvMb30SKRP3PRAHbVecLsdT4Xuq0z0M4I0Z9vUalFdLkqiMezYLy31irFlH0lay2F7A1vNqw== X-Received: by 10.28.21.210 with SMTP id 201mr16141792wmv.94.1491937401526; Tue, 11 Apr 2017 12:03:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.195.15 with HTTP; Tue, 11 Apr 2017 12:03:00 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Tue, 11 Apr 2017 14:03:00 -0500 Message-ID: To: Cullen Jennings Cc: perc@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:03:33 -0000 Before I respond I just wanted to check something: Was this sent on April 1st and it then got stuck in an outbox somewhere where it remained for 10 days? On Mon, Apr 10, 2017 at 8:35 AM, Cullen Jennings wrote: > > I've looked at a bunch of options for how we could approach this. Origina= lly I planned to write them all up but the one that Nils (and others) was t= alking about seems like a clear best one to me so let me describe that then= perhaps list some of the others ... > > The goal of this is to keep the basic flow of information in your average= endpoint as close to possible as it is today and not need to substantial = change any existing specification when using double vs when using other STL= S-SRTP transforms. The goals is also not to just solve the problems of RTX= and FEC used today, but also be compatible with more complex FEC schemes t= hat might be done in the future which have far more state that can become c= orrupted by un authenticated packets. > > The basic approach is pretty simple. We add to the OBH block a flag that = indicates if that double algorithm does normal crypto where the half the ke= y is used for the inner encrypt, then 2nd half key used for outer, or, if t= he flag is set, it only does the outer part. This allows a packet that is m= eant for the Media Distributor, and does not contain a payload that has non= encrypted user media, to effectively be marked for single, not double encr= yption. RTX, FEC, and RTCP packets would be marked this way. It keeps all t= he flow of processing the same as existing systems that are not using doubl= e. The reason the flag needs to be in the OBH is the system receiving the p= ackets needs to know this information to be able to decrypt. > > I don't think that using RTX for creating wasted bandwidth via padding is= a great idea but none the less, this would support that use of RTX. It als= o allows the Media Distributor, to look at the RTX payload to find the OSN = (original Sequence Number) so that the Media Distributor, can do repair. A = RTX sender would cache the packets it is sending (which are normal double e= ncrypted) and when it got a request for a retransmission, it would take the= cached packet to form the RTX packet to send. This is exactly how RTX work= s if the endpoint is not doing double so it is nice that it is the same. > > Below I will list a few options that I considered but view as significant= ly worse than the above proposal. > > 1. Send RTX/FEC non authenticated, do the repair, and if the repair pack= et validated, then consider it OK > > 2. Send RTX/FEC on separate steam that did not not negotiate double > > 3. When using RTX and double, create a new RTP header extension that prov= ides the Media Distributor with the OSN in the header extension. The RTX pa= cket would still have the OSN in it. > > 4. Leave RTX out of the first version of PERC and solve it as an extensio= n to PERC later > > 5. Some sequence o extracting an inserting packets half way through the d= ouble transform. Among other problems with requires the endpoints to signif= icantly change their flow when using double and problem involves updating m= any specs to have special text around double handling. > > 6. Simply use RTX in end to end way and not have the Media Distributor p= articipate in RTX. > > 7. Do a new version of RTX that puts the OSN as a header extension instea= d of as a payload extension. > > > > > > > > > > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --=20 https://jitsi.org From nobody Tue Apr 11 13:58:04 2017 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 B95A3129548 for ; Tue, 11 Apr 2017 13:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 XVJIRpPFnkMB for ; Tue, 11 Apr 2017 13:58:00 -0700 (PDT) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.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 9B3C5127601 for ; Tue, 11 Apr 2017 13:58:00 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B6319566C; Tue, 11 Apr 2017 16:57:59 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4936F5774; Tue, 11 Apr 2017 16:57:59 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 11 Apr 2017 16:57:59 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Tue, 11 Apr 2017 14:57:58 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A1746CD-5313-48EB-8555-A3EE18E686FD@iii.ca> References: To: Emil Ivov X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:58:03 -0000 I look forward to construct discussion on what parts of this don't work = and expect them to be well informed by existing RFC and conversation in = the WG.=20 > On Apr 11, 2017, at 1:03 PM, Emil Ivov wrote: >=20 > Before I respond I just wanted to check something: >=20 > Was this sent on April 1st and it then got stuck in an outbox > somewhere where it remained for 10 days? >=20 > On Mon, Apr 10, 2017 at 8:35 AM, Cullen Jennings = wrote: >>=20 >> I've looked at a bunch of options for how we could approach this. = Originally I planned to write them all up but the one that Nils (and = others) was talking about seems like a clear best one to me so let me = describe that then perhaps list some of the others ... >>=20 >> The goal of this is to keep the basic flow of information in your = average endpoint as close to possible as it is today and not need to = substantial change any existing specification when using double vs when = using other STLS-SRTP transforms. The goals is also not to just solve = the problems of RTX and FEC used today, but also be compatible with more = complex FEC schemes that might be done in the future which have far more = state that can become corrupted by un authenticated packets. >>=20 >> The basic approach is pretty simple. We add to the OBH block a flag = that indicates if that double algorithm does normal crypto where the = half the key is used for the inner encrypt, then 2nd half key used for = outer, or, if the flag is set, it only does the outer part. This allows = a packet that is meant for the Media Distributor, and does not contain a = payload that has non encrypted user media, to effectively be marked for = single, not double encryption. RTX, FEC, and RTCP packets would be = marked this way. It keeps all the flow of processing the same as = existing systems that are not using double. The reason the flag needs to = be in the OBH is the system receiving the packets needs to know this = information to be able to decrypt. >>=20 >> I don't think that using RTX for creating wasted bandwidth via = padding is a great idea but none the less, this would support that use = of RTX. It also allows the Media Distributor, to look at the RTX payload = to find the OSN (original Sequence Number) so that the Media = Distributor, can do repair. A RTX sender would cache the packets it is = sending (which are normal double encrypted) and when it got a request = for a retransmission, it would take the cached packet to form the RTX = packet to send. This is exactly how RTX works if the endpoint is not = doing double so it is nice that it is the same. >>=20 >> Below I will list a few options that I considered but view as = significantly worse than the above proposal. >>=20 >> 1. Send RTX/FEC non authenticated, do the repair, and if the repair = packet validated, then consider it OK >>=20 >> 2. Send RTX/FEC on separate steam that did not not negotiate double >>=20 >> 3. When using RTX and double, create a new RTP header extension that = provides the Media Distributor with the OSN in the header extension. The = RTX packet would still have the OSN in it. >>=20 >> 4. Leave RTX out of the first version of PERC and solve it as an = extension to PERC later >>=20 >> 5. Some sequence o extracting an inserting packets half way through = the double transform. Among other problems with requires the endpoints = to significantly change their flow when using double and problem = involves updating many specs to have special text around double = handling. >>=20 >> 6. Simply use RTX in end to end way and not have the Media = Distributor participate in RTX. >>=20 >> 7. Do a new version of RTX that puts the OSN as a header extension = instead of as a payload extension. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >=20 >=20 >=20 > --=20 > https://jitsi.org From nobody Tue Apr 11 15:10:43 2017 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 C26CF128C82 for ; Tue, 11 Apr 2017 15:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 15_y4t8d04pJ for ; Tue, 11 Apr 2017 15:10:39 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 8C159126C83 for ; Tue, 11 Apr 2017 15:10:39 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r203so12765777oib.3 for ; Tue, 11 Apr 2017 15:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uPkxobSXAUcUE713mohevxVFnYXE5LEjD9ouuSps3g8=; b=k9/aQ4GLpIQ9XeVh07UlNpxRxhvlRPAEwbU1m4P68Ndo5S5vlV+trlFHSINs2RSRfu EoiwJuxBEdkcupabqjvZFgBOuw51BZYLiK4hf1wNBUaGr+tMZjSVMYwd0syda503QIC2 Dv0AK42A8pe/5EOGnuvJTTimDdIpX6ZvYEsnFsVtHQeUZFWOpUH0cjuzDjObl2pUyKOT c5DUTjFS6Yg9fWlex/AwQWAOxo6/sTKl6fWkH37Aq3dcRmNFQLZz3dx1VnhSBthDAMVq 8d2d1ggjCCL3F0z/BGwdz0OIuXiauifQI+wzkqTrkGZ+xBUNza+y8SCeiChI9ltO8ycB LEhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uPkxobSXAUcUE713mohevxVFnYXE5LEjD9ouuSps3g8=; b=Cq/4d3+xvfY+rXLyqr5T4LFiPSGPg15tGpjdGLmpOOtP0Vws6qKnUTgwLpSdw7US8l Rm0lBvzwB0PpDhgpjSZP//oIDoe25DRNXzU0/H7NsOMyu7wW5hXK+yH2SApCi6DAORmF cxicxdkG5GF/bUHoKh6CURxS7N2F83e9I0ykJr0blu5bLG9AAkJPtzh7/VA8sBPXhQRx LF1A7/JxD9t4ecolrT3WYqAwsnYplR6dvP/jaa5pbZcyHKvaS4+7WoBHN1rBDoiKsL5O EYCBTalz1MgWz39eaz9//ZQ74mtfqeDaMYry3M5kt8N5hyP+SoFFZtI1GS6IBWZKvo2+ Lf5A== X-Gm-Message-State: AFeK/H2gm3eAT6Gi/t8ToQX5A435HJg8w+H8pzeTc6SplXE3lnhK0B8AI4u8MOjtPUWVnA== X-Received: by 10.157.14.202 with SMTP id 68mr26604533otj.62.1491948638621; Tue, 11 Apr 2017 15:10:38 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id r2sm8031704ota.1.2017.04.11.15.10.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 15:10:37 -0700 (PDT) To: Adam Roach , Sergio Garcia Murillo , Cullen Jennings References: <7E03D088-E1A7-4720-A4CE-FF01E9C347B8@iii.ca> <752007a7-ceb3-7874-6a5d-f16b484982c7@gmail.com> <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> Cc: perc@ietf.org From: Emil Ivov Message-ID: Date: Tue, 11 Apr 2017 17:09:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <75f58c97-bf06-4b14-54ea-2faa8c4f1d2f@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 22:10:42 -0000 To begin with, I assume none of that was said with an AD hat on? On 4/10/17 5:25 PM, Adam Roach wrote: > On 4/10/17 09:47, Sergio Garcia Murillo wrote: >> If I understood the core of your proposal correctly, I think we are in >> agreement that FEC/RTX (how about RED?) and RTCP are HBH and only >> outer encrypted. I still have doubts about the usage of the OHB and >> the need of this flags as all the sender/receiver and MD already are >> able to differentiate FEC/RTC/RED/RTCP from media payloads and I don't >> see other scenarios in which we would want to use that flag in a more >> generic way. > > > (a) Using the SDP-negotiated PT value to determine what kind of SRTP > encryption and decryption to apply is really strange, from a layering > perspective. It requires the code that receives packets to have a > mapping of PT values to codecs, and I would not expect any libraries > that do that kind of thing to already have a notion of PT-to-codec > mapping already. Thinking through what it would take to add this, the > additional plumbing to get the socket handling code or the SRTP code to > understand PTs is pretty convoluted. There seems to be this conflict of perceptions here, where some people try to look at double as a single atomic transform. Without considering the validity of such a perception I would like to point out that there is nothing in our charter that binds us to such a model. If you look at this from the perspective of double being two independent transforms, then none of the crypto processing is impacted by payload. You simply have payload dictating whether something (e.g. the RTX module) would process packets in between the two transforms, but the transforms themselves are always the same. Emil > (b) The use of a client-supplied bit in the OHB reduces questions like > "should we double encrypt DTMF" to a policy question rather than a > protocol question-- and this includes not just DTMF, but any kind of > FEC/RTX/RED-type stuff that may be developed in the future. > > > /a > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > . > -- https://jitsi.org From nobody Tue Apr 11 15:11:29 2017 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 26BC8126DEE for ; Tue, 11 Apr 2017 15:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 Y4Ra02t_Arjr for ; Tue, 11 Apr 2017 15:11:25 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 741721243FE for ; Tue, 11 Apr 2017 15:11:25 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id f22so12867096oib.2 for ; Tue, 11 Apr 2017 15:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/uBgIcNacuKAwgajGfRuak9ZFMSlgwdJEd+9dTJRCcg=; b=uMqtZzMAndhN3iG54L37fzxoXzLszX0zAjGIU3n/i/3eV3DSLy5Y6UZTfy4VaK3qfl ua/niuxW0hFs2r4m8630RN9r07xSX9iKS1iEJn+F0U557cvSllGzeP9onZlmM/tYBVjO oJNK7nTrMgKK0Gcz3fFw3iec1FSnPTtiBJQ0tvG7s8B7E8GX5zIh+nUyMIfhvGHwof/C Ea0lGVS1TnV8G/W0DJN9FhNKIR6XhZ84NikIBQpQq2cqAIzmILl2sBmArWLb/jxKIoeo UcIfK5ANCXfstw9uB2ochvmXeJfly0WUHwOQ3/7H/JvXqm9VYaplkwcCHXtIVEdjCuOW OvbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/uBgIcNacuKAwgajGfRuak9ZFMSlgwdJEd+9dTJRCcg=; b=ndVXwibMAKvh0E/o/ekrr7VBrLuXEBnilV2FMCOFZDwGZ0EGQUSTN/MmR2Hlyrvm8p z3c4ewdzjATaGZd/0KGekvRMPWHpbAG6ivsoY2MLBcJhHcfeRiEPeeN9yjdntTEVDZVN +lEzNLVLNF7PIJlQuD0MmJ6iw4SfbFQRYMBBp4aK6X2JvP5Sc3zonDyjnWs+tyI1cu90 1HAOWIUQ2ayqqDokPP1KR8UU/GMD7n1hx8VBx5rGYaVLZioXH3wFeo0Q2GhDGMJ/I2MP YLFiPZFwjblpsh7bbGHvVXMgibNkoVZXJIso+fHY/+CP0zDF8hwi6VLMPTWAdlf9wt4S vYow== X-Gm-Message-State: AN3rC/6xvVDECIwsuLyL6pXAQ5HjJb/8I8pY6oXT3Kni9+yZ3wxyEO5H9k7Z2XCVcs1QBA== X-Received: by 10.202.48.7 with SMTP id w7mr6499362oiw.87.1491948684637; Tue, 11 Apr 2017 15:11:24 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id e31sm2716591ote.42.2017.04.11.15.11.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 15:11:23 -0700 (PDT) To: Cullen Jennings , perc@ietf.org References: From: Emil Ivov Message-ID: <762a3882-5d09-d75c-ada1-3d8f7137d9ad@jitsi.org> Date: Tue, 11 Apr 2017 17:11:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 22:11:28 -0000 Oh ok ... so this was a serious proposal. Inline then: On 4/10/17 8:35 AM, Cullen Jennings wrote: > > I've looked at a bunch of options for how we could approach this. > Originally I planned to write them all up but the one that Nils (and > others) was talking about seems like a clear best one to me so let me > describe that then perhaps list some of the others ... > > The goal of this is to keep the basic flow of information in your > average endpoint as close to possible as it is today and not need to > substantial change any existing specification when using double vs > when using other STLS-SRTP transforms. This is NOT one of the objectives in our charter: https://datatracker.ietf.org/doc/charter-ietf-perc/ One reason it isn't is because the *internals* of implementation optimizations are a concern to *implementers* ... not to the IETF. Another reason it isn't is because the internals of your implementation are very different from mine. > The goals is also not to just > solve the problems of RTX and FEC used today, but also be compatible > with more complex FEC schemes that might be done in the future which > have far more state that can become corrupted by un authenticated > packets. > > The basic approach is pretty simple. We add to the OBH block a flag > that indicates if that double algorithm does normal crypto where the > half the key is used for the inner encrypt, then 2nd half key used > for outer, or, if the flag is set, it only does the outer part. I still can't believe you suggested this with a straight face. You seriously want this working group to add an on-the-wire flag in a standards track IETF RFC, that on-the-wire entities will NOT need ... only so that you can pass a param to your implementation ... I am speechless! :) > This > allows a packet that is meant for the Media Distributor, and does not > contain a payload that has non encrypted user media, to effectively > be marked for single, not double encryption. RTX, FEC, and RTCP > packets would be marked this way. It keeps all the flow of processing > the same as existing systems that are not using double. The reason > the flag needs to be in the OBH is the system receiving the packets > needs to know this information to be able to decrypt. > > I don't think that using RTX for creating wasted bandwidth via > padding is a great idea but none the less, this would support that > use of RTX. It also allows the Media Distributor, to look at the RTX > payload to find the OSN (original Sequence Number) so that the Media > Distributor, can do repair. A RTX sender would cache the packets it > is sending (which are normal double encrypted) and when it got a > request for a retransmission, it would take the cached packet to form > the RTX packet to send. This is exactly how RTX works if the endpoint > is not doing double so it is nice that it is the same. No. This is not at all how it works if the endpoint is doing double. Every 4588 implementation that I am aware of caches packets before the hop by hop encryption. The one PERC implementation that I know of also does this. > Below I will list a few options that I considered but view as > significantly worse than the above proposal. > > 1. Send RTX/FEC non authenticated, do the repair, and if the repair > packet validated, then consider it OK > > 2. Send RTX/FEC on separate steam that did not not negotiate double > > 3. When using RTX and double, create a new RTP header extension that > provides the Media Distributor with the OSN in the header extension. > The RTX packet would still have the OSN in it. > > 4. Leave RTX out of the first version of PERC and solve it as an > extension to PERC later > > 5. Some sequence o extracting an inserting packets half way through > the double transform. Among other problems with requires the > endpoints to significantly change their flow when using double and > problem involves updating many specs to have special text around > double handling. This is quite a misrepresentation. As it happens, this is the most reasonable approach to the problem. "the endpoints" in this world do not have some common issue with it. Yours might, and I sympathize if that is the problem but I don't want you muddying my on-the-wire traffic because of that anyway. Emil > 6. Simply use RTX in end to end way and not have the Media > Distributor participate in RTX. > > 7. Do a new version of RTX that puts the OSN as a header extension > instead of as a payload extension. > > > > > > > > > > > > > _______________________________________________ Perc mailing list > Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc > -- https://jitsi.org From nobody Tue Apr 11 15:19:52 2017 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 DB2F2128656 for ; Tue, 11 Apr 2017 15:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IqqI7D2ftdGH for ; Tue, 11 Apr 2017 15:19:48 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 2281B124D6C for ; Tue, 11 Apr 2017 15:19:48 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u2so11006452wmu.0 for ; Tue, 11 Apr 2017 15:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=xOWD6XMOOPdFwlTX7uUJTUyr2KF5bUrjFvWaIT1aOLg=; b=mBFKHS3O9IRcQ/L+cOT+h7KC3kkf/nya2uDoovkfbyrWwjEUroyO/sqq4fakbtC/mq mtCC5mZxcCdSEqYzzu70280nXKn7Pef/vBJVrPTgZqYfn6vWibdB5GIlL4EbCdwAyOie IeljJXEQCAuwuYBhA6umB+6WaB6NkM3uwP7d4ReyDW3qvks7Gg49haDyIJHYAsJNKTgw UFpDIQbXeYReBRDbz/9tR+C6w3H48txWK3cC/QBKW77ieaRm/xg9csICUIvTdADkpghu 5QobfO5Epz/rsOMV/YKwujaGD/AtIRh/qjyEUk/PFjW3qvNb8nilrY4erBzspvQRe+R8 cFAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xOWD6XMOOPdFwlTX7uUJTUyr2KF5bUrjFvWaIT1aOLg=; b=ndTEqeCBo9WntJirsatYMlZbgBDzqKQvElEHhixUVDFKD7hysuuhPutpuGPpBhxqJY W5/d+Sdwz/DMZXhSv1mXbEnRxyK4JxUfbMBNgUSEW4WGFhj1WgixOVVvgUSF8pEC2t9j kGkFuKDCrTWofCN8/3Uq1KmoECqbLtny4Ba8k1B+3s/M/6lzArkvrZ/mZ8OdsbCAQN/r ktd75aEP1OzcIknJGAcjpINznh199Q9ufFEc7yTu6AdrtvDWlC6TMtcb207wNWMLlvmT iurnuKMkl/povzpeCa8u5GMucwLlDJM00YwB7+aes3dtAi6NB6xxbwZkDrDJ1dENhq3H 64HQ== X-Gm-Message-State: AN3rC/4JOOo512JcWnP7tjOjU/czyXwVMwqSNWlFFFLy0p9f3WiXAXYe pzYa6ar2DI0Oecskk7o= X-Received: by 10.28.156.13 with SMTP id f13mr4381844wme.44.1491949186314; Tue, 11 Apr 2017 15:19:46 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id l132sm4142161wmd.10.2017.04.11.15.19.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 15:19:45 -0700 (PDT) To: perc@ietf.org References: <762a3882-5d09-d75c-ada1-3d8f7137d9ad@jitsi.org> From: Sergio Garcia Murillo Message-ID: <83b01ab4-6e96-f6a7-560b-b9432b3f3155@gmail.com> Date: Wed, 12 Apr 2017 00:19:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <762a3882-5d09-d75c-ada1-3d8f7137d9ad@jitsi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 22:19:51 -0000 On 12/04/2017 0:11, Emil Ivov wrote: > >> I don't think that using RTX for creating wasted bandwidth via >> padding is a great idea but none the less, this would support that >> use of RTX. It also allows the Media Distributor, to look at the RTX >> payload to find the OSN (original Sequence Number) so that the Media >> Distributor, can do repair. A RTX sender would cache the packets it >> is sending (which are normal double encrypted) and when it got a >> request for a retransmission, it would take the cached packet to form >> the RTX packet to send. This is exactly how RTX works if the endpoint >> is not doing double so it is nice that it is the same. > > No. This is not at all how it works if the endpoint is doing double. > Every 4588 implementation that I am aware of caches packets before the > hop by hop encryption. > > The one PERC implementation that I know of also does this. I am also not aware of a single SFU that uses E2E RTX/FEC, nor a single use case in which it make sense. So I would be deeply against defining a complex mechanism for something that is not used/usable at all. Best regards Sergio From nobody Tue Apr 11 15:33:23 2017 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 DB46B1287A5 for ; Tue, 11 Apr 2017 15:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sip-communicator-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 kEuuAF3quXo3 for ; Tue, 11 Apr 2017 15:33:20 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D96C126DEE for ; Tue, 11 Apr 2017 15:33:20 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id g204so13360349oib.1 for ; Tue, 11 Apr 2017 15:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sip-communicator-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:references:from:to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KCsQ6HXrJ7r0RIwm+CnD3ZLUmcePRcR+LWhbdUkX8cM=; b=f7zzfD5n+qLX2OyK3DbY2yLVzKR422tAIls6ncSHef89x2Z1GWAfujPGoun3qym+Ld +q6Hb1oluCXxNVXJzMvJUJH0xx++Zvsb5QBZL6i8GmbB+SjitblvIt3Ujl8zt4t422qR n+Ka4+JhCIdw+xqJ4098amor32rfrnp7gzi+7trU6JE+hGAr+ZWCe7S1Y5y3BRa/3SZQ 6NKYzuci0zR96ESVI7uTlzdFKl/YKUDFiWgIP1jvNiAe88w5y6rw/ztlCjqazvhL81fj KMTUhoGU0ba3YxgrLrG7ypo7nHZ3RYHxGsBPUkfIfEOp//B1fDgmkrq7UrYS4jyLGWPh K9Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:references:from:to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KCsQ6HXrJ7r0RIwm+CnD3ZLUmcePRcR+LWhbdUkX8cM=; b=JemIoqAuxFzQEBBofZoKgKKnc008ZnLEVB+sR4uA6DJBj5w22wSxNJ2q1V+aU3tueK JOl9qZLau5RfFRjhGpKHrzlJj6+bWMk8ilB5VECePkRFZBXnIoGT5bmlhKUgwTvIOm2X vrELBaMQNHjXgkfrUwGAztzp7es6BruAjHao6ihAcUmaNRUGTnKll9qXp+AtU7zoa952 7bEbYOFHztNKVuYxCjr2UMi8erCL+duvlZRTjySDHMMdWQy8+Zl8IEBiYeBPqv9N4Bou 0DqvsH5MHQ39jIVk8tjHE7K5FL40QlnzLXH3zAPWjCvo5bRPqfYet1ttsy6P2xo0/JDH 7j7w== X-Gm-Message-State: AN3rC/5BEr2n8D3ODOgceL8WzAYYfYcByzzDlvzZuf9pHImkVF7M2pLK4WMs/u+JAMHunQ== X-Received: by 10.157.73.155 with SMTP id g27mr2918805otf.22.1491949999245; Tue, 11 Apr 2017 15:33:19 -0700 (PDT) Received: from bgrozev.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.gmail.com with ESMTPSA id o12sm7839532otb.14.2017.04.11.15.33.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 15:33:18 -0700 (PDT) Sender: Boris Grozev References: From: Boris Grozev To: Cullen Jennings , perc@ietf.org Message-ID: Date: Tue, 11 Apr 2017 17:33:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 22:33:22 -0000 Hello Cullen, On 10/04/2017 08:35, Cullen Jennings wrote: > > I've looked at a bunch of options for how we could approach this. > Originally I planned to write them all up but the one that Nils (and > others) was talking about seems like a clear best one to me so let me > describe that then perhaps list some of the others ... > > The goal of this is to keep the basic flow of information in your > average endpoint as close to possible as it is today and not need to > substantial change any existing specification when using double vs > when using other STLS-SRTP transforms. The goals is also not to just > solve the problems of RTX and FEC used today, but also be compatible > with more complex FEC schemes that might be done in the future which > have far more state that can become corrupted by un authenticated > packets. > > The basic approach is pretty simple. We add to the OBH block a flag > that indicates if that double algorithm does normal crypto where the > half the key is used for the inner encrypt, then 2nd half key used > for outer, or, if the flag is set, it only does the outer part. This > allows a packet that is meant for the Media Distributor, and does not > contain a payload that has non encrypted user media, to effectively > be marked for single, not double encryption. RTX, FEC, and RTCP > packets would be marked this way. It keeps all the flow of processing > the same as existing systems that are not using double. The RTX format shares the RTP header extensions with the retransmitted packet. If we modify a flag in the OHB block of a packet after it has passed through SRTP, we need a way to restore the original value before decrypting the packet. > The reason > the flag needs to be in the OBH is the system receiving the packets > needs to know this information to be able to decrypt. Can you please elaborate this point? I don't understand why a receiving system needs this information. > > I don't think that using RTX for creating wasted bandwidth via > padding is a great idea but none the less, this would support that > use of RTX. It also allows the Media Distributor, to look at the RTX > payload to find the OSN (original Sequence Number) so that the Media > Distributor, can do repair. A RTX sender would cache the packets it > is sending (which are normal double encrypted) and when it got a > request for a retransmission, it would take the cached packet to form > the RTX packet to send. I am confused. After taking a double encrypted packet from the cache and applying RTX, would the RTX sender perform the outer SRTP transform again? If not, then this is option "1" from below. If yes, then the packet is effectively encrypted three times. A receiver would have to decrypt once, de-RTX, decrypt a second time (and if it is an endpoint then the second decryption will include the E2E decryption). If an RTX sender creates an RTX packet with payload which does not come from its cache (e.g. an MD forwarding a packet received in RTX), it would have to perform the HBH encryption twice. This is clearly over complicated, and requires changes to both endpoints and MDs. > This is exactly how RTX works if the endpoint > is not doing double so it is nice that it is the same. This is not how current webrtc implementations work. Packets are cached before the SRTP transformation, and RTX is applied before SRTP. > > Below I will list a few options that I considered but view as > significantly worse than the above proposal. > > 1. Send RTX/FEC non authenticated, do the repair, and if the repair > packet validated, then consider it OK > > 2. Send RTX/FEC on separate steam that did not not negotiate double > > 3. When using RTX and double, create a new RTP header extension that > provides the Media Distributor with the OSN in the header extension. > The RTX packet would still have the OSN in it. > > 4. Leave RTX out of the first version of PERC and solve it as an > extension to PERC later > > 5. Some sequence o extracting an inserting packets half way through > the double transform. Among other problems with requires the > endpoints to significantly change their flow when using double and > problem involves updating many specs to have special text around > double handling. > > 6. Simply use RTX in end to end way and not have the Media > Distributor participate in RTX. > > 7. Do a new version of RTX that puts the OSN as a header extension > instead of as a payload extension. What is missing from this list is the option proposed earlier of performing RTX (or FEC or anything defined in the future which needs to be handed HBH) after the E2E encryption, but before the HBH encryption. This requires no changes to MDs, and similar to your proposal requires a mechanism for senders to only perform the outer encryption. Implementors can choose to use an RTP header extension to signal to their library that E2E encryption is to not be performed for a specific packet, but I don't see a need for this to go over the wire. Regards, Boris From nobody Tue Apr 11 18:29:48 2017 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 79B7212426E for ; Tue, 11 Apr 2017 18:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jSHbQll5-Pt for ; Tue, 11 Apr 2017 18:29:45 -0700 (PDT) Received: from smtp85.ord1c.emailsrvr.com (smtp85.ord1c.emailsrvr.com [108.166.43.85]) (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 386F51242F5 for ; Tue, 11 Apr 2017 18:29:45 -0700 (PDT) Received: from smtp19.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 80F2FA03A6; Tue, 11 Apr 2017 21:29:42 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 22C09A03C9; Tue, 11 Apr 2017 21:29:42 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 11 Apr 2017 21:29:42 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Tue, 11 Apr 2017 19:29:40 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> References: To: Boris Grozev X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 01:29:46 -0000 Reading this whole email, I think there is probably come confusion about = a bunch of things which would likely best be cleared up with some slides = and WG conference calls rather than email. But let me try and answer one = of your questions inline=20 > On Apr 11, 2017, at 4:33 PM, Boris Grozev wrote: >=20 > Hello Cullen, >=20 ... snip ...=20 >=20 >> The reason >> the flag needs to be in the OBH is the system receiving the packets >> needs to know this information to be able to decrypt. >=20 >=20 > Can you please elaborate this point? I don't understand why a = receiving system needs this information. Take the DTMF example where it is a policy decision on sender if the MD = was going to be able to decrypt the DTMF of not. The sender encrypts it = one way or the other then send it to the MD and then the MD sends it to = the receiver. The receiver needs some way to know how the sender = encrypted it so that the receiver can correctly decode it. The receiver = would do the outer decrypt, then look at the flag to decide if the inner = decrypt should also be done.=20 Does that make sense ? From nobody Wed Apr 12 01:10:26 2017 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 C48E4129555 for ; Wed, 12 Apr 2017 01:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ex1DLHm6Ju8b for ; Wed, 12 Apr 2017 01:10:23 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 140C512947A for ; Wed, 12 Apr 2017 01:10:23 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id w64so81245497wma.0 for ; Wed, 12 Apr 2017 01:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=TEmBj20//OepZT1oHkHJTU+SZhI0sa+5h++Z1ZyRxzo=; b=YwEj52ZxAtzvADYzMkpYo0RkJrGQjNPl48WTFNz1FmeOq+1Q7kGE45BKUhpii+uso3 OqmplBJhIwLpHyscARUtY+Gn0OIobN7YDa2T0tLuyRCivGFobsN0HRHR+mr6wBowde4J WzWvA3g1tIpowEyPuFyjYGhk4KZWQ1/XjeUE2w+Lq3Ieynz0urXj7lYEr8IygwF6I0+b 7NYrk8vlaR3EbMVl6jlh/1LJEWjFNrTfpE3emDcIq/ohHX/dcCDsTs2A28AFOMN26TLV c+b00eeNW1ysdx5igOP6iEZF9QgxjubfIUYqogwkSEPtiJxTbhDqua9Ho/zIiGPVB+Yz 6mmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TEmBj20//OepZT1oHkHJTU+SZhI0sa+5h++Z1ZyRxzo=; b=WKmMmXaEO/pOweh2If27zkQd7PSnicnUjqmD3ETHc5UdxRbpqIOEw2lvRmyUb8ACsx CBB1IR/uc0ZHn2d2MJVQiOlBLmdQzj+Jlf7m5fzlPbOWXxgr1QzefrCWVLvpLKCmW2Qm RSJq7vwVyOGuN4d6w99A4p8J0r4KBTCOuSxC8OdFUldmxJ8hw5c3KaD66gz741lbK6ei naD+GbEdploKrGfzxIoJXk8IiGnc6I3ycUTyJ+NBbo0rFR74jkLiHvPCwHganEK4l8E8 bMW0ZcLqCLkkonhGQuzCOTadMN2mnA0XR6NQrt05jA+WEpg5GFQvAr6Gh3okE8hhE/Pu qTTw== X-Gm-Message-State: AN3rC/7JV3A7Dexfp5tL+YY/80vXhACgGzhrrX5C0XqJ2fpBUWsKkyek 0bE6jraVzi/95btI8uQ= X-Received: by 10.28.156.13 with SMTP id f13mr5965926wme.44.1491984621405; Wed, 12 Apr 2017 01:10:21 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id g15sm4708483wmc.14.2017.04.12.01.10.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 01:10:20 -0700 (PDT) To: perc@ietf.org References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> From: Sergio Garcia Murillo Message-ID: Date: Wed, 12 Apr 2017 10:10:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:10:25 -0000 On 12/04/2017 3:29, Cullen Jennings wrote: > > Take the DTMF example where it is a policy decision on sender if the MD was going to be able to decrypt the DTMF of not. The sender encrypts it one way or the other then send it to the MD and then the MD sends it to the receiver. The receiver needs some way to know how the sender encrypted it so that the receiver can correctly decode it. The receiver would do the outer decrypt, then look at the flag to decide if the inner decrypt should also be done. I should have never brought up the DTMF topic.. :) I think that the discussion is around the recover streams (RTX, ulpfec, RED and Flex Fec), which IMHO doesn't make sense at all to be E2E encrypted. If we keep them HBH nothing needs to be changed to the current specs/implementetions. So I would expect a very well supported argument in favor of E2E recover streams that justifies the need for any new mechanisms. Regarding the flag for media streams, I don't have a strong opinion yet, but I think it is better to keep both discussions separated. Best regards Sergio From nobody Wed Apr 12 02:29:23 2017 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 333501314D6 for ; Wed, 12 Apr 2017 02:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnMdfl_gFy1d for ; Wed, 12 Apr 2017 02:29:09 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 4EE361314E3 for ; Wed, 12 Apr 2017 02:28:59 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id c45so17455022qtb.1 for ; Wed, 12 Apr 2017 02:28:59 -0700 (PDT) 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; bh=wEXQB+J8SyQFpPBpzvlogsXbGTfYksnFXHYio8kdM2E=; b=ZWB0Hr+1JVG1wO1cPF1yxLpHtwom8uZ2bMKRWikfswry3bOJYszJHUN8A7ksWAnIiI ITxEfMU0H8lNtjL53noejGf+F3mYlgWbDAhSPe5DO1GVIbvOb5+dt3fc8/HiXwuIpPsb lSCyH/CKv1C3gerg/RjFLYs6cfRydvFIQSJTE3BZVNMxAblGhFdwssOfHejjJhzBXMIH NNj8wwePYhp6eTNuLT/gx9Vm3nN/EKubatgVk64hDvP04wmqoqJCauvsrvsf6lDzLmwC NvLUDqWiGjjeXFxP8foOth9umi74P9SfHmaUMHy3FBRAhQGSNAM4y0Ia98f0dqDFpm6I MrJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wEXQB+J8SyQFpPBpzvlogsXbGTfYksnFXHYio8kdM2E=; b=POjaGZAAI0R0n4xnJMJBRRJkPW+eTcOsbh2ZaVP24CV1HGkNbEd/RFmC16UPjzY11z DV118wTD+jRRG3cminrN9W+S6m5gwgDLaNzjXSkx89Fz4T9hCT0niIPkMcin1VepqYGj x1P8PkAf7FMhDD3EawQvJeA2/sqqIeFsiIbF/aT5x63FAOE0kPvww8gfcI/Pqm7ku62D fAf/OyqxWnuNxXNxwL9ZsAnKr9nQEVKKQij3WRgVlZ6Q0C0C4v6fBGLxM8KVw2aDydfd Wrszb9/hBkmK3p6eqF5/mCZ66hLjiaTDDSOPQnbrRecckE9tld5xPqHg5/sJC2MoQuh8 GNvA== X-Gm-Message-State: AN3rC/4xRUvziPOuCAh4RM06vHysNO0IhBHnoEKPFxL6geG+G3XEd6ATauf+oS9VL6SXZSrUloXrToSyN0h/ig== X-Received: by 10.200.53.65 with SMTP id z1mr16916160qtb.77.1491989338460; Wed, 12 Apr 2017 02:28:58 -0700 (PDT) MIME-Version: 1.0 References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> In-Reply-To: From: Suhas Nandakumar Date: Wed, 12 Apr 2017 09:28:47 +0000 Message-ID: To: Sergio Garcia Murillo , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113a13de872458054cf4d63c Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:29:11 -0000 --001a113a13de872458054cf4d63c Content-Type: text/plain; charset=UTF-8 On Wed, Apr 12, 2017 at 1:10 AM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 12/04/2017 3:29, Cullen Jennings wrote: > > > > Take the DTMF example where it is a policy decision on sender if the MD > was going to be able to decrypt the DTMF of not. The sender encrypts it one > way or the other then send it to the MD and then the MD sends it to the > receiver. The receiver needs some way to know how the sender encrypted it > so that the receiver can correctly decode it. The receiver would do the > outer decrypt, then look at the flag to decide if the inner decrypt should > also be done. > I should have never brought up the DTMF topic.. :) > > I think that the discussion is around the recover streams (RTX, ulpfec, > RED and Flex Fec), which IMHO doesn't make sense at all to be E2E > encrypted. If we keep them HBH nothing needs to be changed to the > current specs/implementetions. So I would expect a very well supported > argument in favor of E2E recover streams that justifies the need for any > new mechanisms. If I am not reading wrong, it looks like the original mail from Cullen meant these to be Scoped just to the media distributor and not e2e .. > > Regarding the flag for media streams, I don't have a strong opinion yet, > but I think it is better to keep both discussions separated. > > Best regards > Sergio > Regards Suhas (As individual ) > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a113a13de872458054cf4d63c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 12, 2017 at 1:10 AM Se= rgio Garcia Murillo <= sergio.garcia.murillo@gmail.com> wrote:
On 12/04/2017 3:29, Cullen Jennings wrote:
>
> Take the DTMF example where it is a policy decision on sender if the M= D was going to be able to decrypt the DTMF of not. The sender encrypts it o= ne way or the other then send it to the MD and then the MD sends it to the = receiver. The receiver needs some way to know how the sender encrypted it s= o that the receiver can correctly decode it. The receiver would do the oute= r decrypt, then look at the flag to decide if the inner decrypt should also= be done.
I should have never brought up the DTMF topic.. :)

I think that the discussion is around the recover streams (RTX, ulpfec,
RED and Flex Fec), which IMHO doesn't make sense at all to be E2E
encrypted. If we keep them HBH nothing needs to be changed to the
current specs/implementetions. So I would expect a very well supported
argument in favor of E2E recover streams that justifies the need for any new mechanisms.

If I am not reading wrong, = it looks like the original mail from Cullen meant these to be Scoped just t= o the media distributor and not e2e ..=C2=A0


<= /div>


Regarding the flag for media streams, I don't have a strong opinion yet= ,
but I think it is better to keep both discussions separated.

Best regards
Sergio

Regards
Suhas=C2=A0
(A= s individual )

_______________________________________________
Perc mailing list
Perc= @ietf.org
https://www.ietf.org/mailman/listinfo/= perc
--001a113a13de872458054cf4d63c-- From nobody Wed Apr 12 02:32:48 2017 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 A3ED812EAEB for ; Wed, 12 Apr 2017 02:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QawV_cGrQ5x6 for ; Wed, 12 Apr 2017 02:32:42 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 683581242EA for ; Wed, 12 Apr 2017 02:32:42 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id z109so13548194wrb.1 for ; Wed, 12 Apr 2017 02:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=6IiBqbI3pq3s0uQNbJB0nWT+kwZmS5ETfXBwNZZEBjs=; b=i3x7h2WbMFcr7GGW2mreskuUXaSwRk/p5C3BAd5wRa8RgF+2L3/nVXWs+PpAJDbLuO Cl3fr7BLVGePxqJz64zOyEZTIxFsx2J55dDNo+dDLL6sw3CYUnI46/Po7BQw9uadyaFQ sW96lezNeUj2VuEwZgmIFADPHnm91FDxk7iaY3ueTELpP9Zeux0bzAQ4Z3OrpLRb9Vpa TqsYGOZTie7SmRwpPon+2RlBUyScsq1HJ9SdeDaTgY82a2snPQWlZKy/xp3hEisy3AdH VX+KR/rxGVzk/RK6ZWu4QeDkUfzQp2cy9Fa383wdiqJRYB3/Jhgh9twAxEI6dIQM8t0P rnkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=6IiBqbI3pq3s0uQNbJB0nWT+kwZmS5ETfXBwNZZEBjs=; b=YnZEae4cTiVtFt0smEpWQiz6Dj/kSS3MsXudeHjmIvcfdUbRcYQwk2XM/TtCszN/2B mPePHQWy1VMHmnPGc6dP5Z8B9dVEwzZNN5+c/CM95lkGMhRE4XHZO7tbZqwdv4iwUvP+ ANTkLDv7XB8xlmNq6lW83TmvsfPYkZ+uyBqYmXrgbsoW1Y/Wwz13J7N0TOSTS0Q9m9U7 kWnJxFqZVbILyp8uVXa513Dt1fayKLBFHAYQ4Ob2GxZQ/ZnKQ1eXNhRDG3uXe5dOXPfc gyr9cDwnz3w3+dGb5gXVhpKavDoNjWaAfkjtToi3yCaYtkF3hR9CQZ4ZMQyxNXHv8Ij4 7xKg== X-Gm-Message-State: AN3rC/5nYjuwuIpFTTgEe7CRSTxgXAZHWZ4fV/zhae9l6kJqGZsPoFiUlfFZvs+Zg/Bh7w== X-Received: by 10.223.136.13 with SMTP id d13mr1926484wrd.168.1491989560897; Wed, 12 Apr 2017 02:32:40 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id l141sm5864321wma.32.2017.04.12.02.32.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 02:32:40 -0700 (PDT) To: Suhas Nandakumar , perc@ietf.org References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> From: Sergio Garcia Murillo Message-ID: <1cb63c17-c678-34d2-a41d-b27a4fc9a13e@gmail.com> Date: Wed, 12 Apr 2017 11:32:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ADA0904D0C82B2E85926BC29" Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:32:45 -0000 This is a multi-part message in MIME format. --------------ADA0904D0C82B2E85926BC29 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/04/2017 11:28, Suhas Nandakumar wrote: > > On Wed, Apr 12, 2017 at 1:10 AM Sergio Garcia Murillo > > wrote: > > On 12/04/2017 3:29, Cullen Jennings wrote: > > > > Take the DTMF example where it is a policy decision on sender if > the MD was going to be able to decrypt the DTMF of not. The sender > encrypts it one way or the other then send it to the MD and then > the MD sends it to the receiver. The receiver needs some way to > know how the sender encrypted it so that the receiver can > correctly decode it. The receiver would do the outer decrypt, then > look at the flag to decide if the inner decrypt should also be done. > I should have never brought up the DTMF topic.. :) > > I think that the discussion is around the recover streams (RTX, > ulpfec, > RED and Flex Fec), which IMHO doesn't make sense at all to be E2E > encrypted. If we keep them HBH nothing needs to be changed to the > current specs/implementetions. So I would expect a very well supported > argument in favor of E2E recover streams that justifies the need > for any > new mechanisms. > > > If I am not reading wrong, it looks like the original mail from Cullen > meant these to be Scoped just to the media distributor and not e2e .. No, the proposal allowed both modes, which means implementing it twice. Best regards Sergio --------------ADA0904D0C82B2E85926BC29 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/04/2017 11:28, Suhas Nandakumar wrote:

On Wed, Apr 12, 2017 at 1:10 AM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 12/04/2017 3:29, Cullen Jennings wrote:
>
> Take the DTMF example where it is a policy decision on sender if the MD was going to be able to decrypt the DTMF of not. The sender encrypts it one way or the other then send it to the MD and then the MD sends it to the receiver. The receiver needs some way to know how the sender encrypted it so that the receiver can correctly decode it. The receiver would do the outer decrypt, then look at the flag to decide if the inner decrypt should also be done.
I should have never brought up the DTMF topic.. :)

I think that the discussion is around the recover streams (RTX, ulpfec,
RED and Flex Fec), which IMHO doesn't make sense at all to be E2E
encrypted. If we keep them HBH nothing needs to be changed to the
current specs/implementetions. So I would expect a very well supported
argument in favor of E2E recover streams that justifies the need for any
new mechanisms.

If I am not reading wrong, it looks like the original mail from Cullen meant these to be Scoped just to the media distributor and not e2e .. 

No, the proposal allowed both modes, which means implementing it twice.

Best regards
Sergio
--------------ADA0904D0C82B2E85926BC29-- From nobody Wed Apr 12 10:27:45 2017 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 CCC4212EB1C for ; Wed, 12 Apr 2017 10:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osuHSJLZQfJj for ; Wed, 12 Apr 2017 10:27:43 -0700 (PDT) Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.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 81C2D129536 for ; Wed, 12 Apr 2017 10:27:43 -0700 (PDT) Received: from smtp9.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 63E63202AB; Wed, 12 Apr 2017 13:27:38 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F1D6720389; Wed, 12 Apr 2017 13:27:37 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.119] ([UNAVAILABLE]. [128.107.241.170]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 12 Apr 2017 13:27:38 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 12 Apr 2017 11:27:36 -0600 Message-Id: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> To: perc@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:27:45 -0000 To help explain the keys in perc, I put together some slides you can find at https://dl.dropboxusercontent.com/u/17089001/Perc/perc-explained_v3.pdf and https://vimeo.com/212949427 Cullen From nobody Wed Apr 12 12:02:20 2017 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 3E67B12EB42 for ; Wed, 12 Apr 2017 12:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 7vJum18me-Mz for ; Wed, 12 Apr 2017 12:02:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE41312EB66 for ; Wed, 12 Apr 2017 12:01:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 528FA300455 for ; Wed, 12 Apr 2017 15:01:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GMVErKg86u5T for ; Wed, 12 Apr 2017 15:01:07 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D6CAC300261; Wed, 12 Apr 2017 15:01:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> Date: Wed, 12 Apr 2017 15:01:06 -0400 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:02:18 -0000 Cullen: Thanks so much for sharing these. I have one question about slide 7. Do these packets flow directly from = Alice to Bob and vice versa? I was expecting to see the wrapped keys = sent via the Key Distributor. Russ > On Apr 12, 2017, at 1:27 PM, Cullen Jennings wrote: >=20 > To help explain the keys in perc, I put together some slides you can = find at=20 >=20 > = https://dl.dropboxusercontent.com/u/17089001/Perc/perc-explained_v3.pdf >=20 > and=20 >=20 > https://vimeo.com/212949427 >=20 > Cullen From nobody Wed Apr 12 14:59:06 2017 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 32351127599 for ; Wed, 12 Apr 2017 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA9-BmAlTQX3 for ; Wed, 12 Apr 2017 14:59:01 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 780391243F6 for ; Wed, 12 Apr 2017 14:59:01 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id x125so20861394pgb.0 for ; Wed, 12 Apr 2017 14:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oTBmzAmsNumfiBIVkB3WWienMoJgyZqlDgjn4rt3xMU=; b=FuIsmtQ81JSxuN4CZG5WzzI/L07EEp2eVDaFdkGzAqoa9CMqqPl1W2HyoCq1huby0R dRNZGid+rmPwAW5CCBrY5hFZqX1QTU7pe1HlJLlqnI0dcqUo0uroSc+/uxEYBqo4UOLk iRfcgSsGZ+YshKVyBbFMdMwHElNek+S84ujZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oTBmzAmsNumfiBIVkB3WWienMoJgyZqlDgjn4rt3xMU=; b=mHF32C6/7xY/RTdEgGREv4Ex3raMPqSMZVBUYfAtMhrr5x5rX1G4W2Ub0yfksxKEAV wyPYjFUzauS/uBZRX8Mwz9/8pA0lC8IH8c8wRKxfY68ed74+tEgcQ3V4l5qK29Dt+0nT rdCdWVna4//rjO0W0I89Sys01p77dNF4oyLmBi6VhP7rOLVp1oAvdLqBaCnxXt2kHUfv P/x2BIPDJFmg+ajKqms5GaPWD3jOaxao6/pE+F9wFe5T6N68G0bs3qgKvJmLQgtZEPbi 76KxFdoTb//SbrYxME/U0nmtgnnHK5bPdLU+rufaanRG/Ftn492Ub3MdYxlWA3EDJnCw cxRw== X-Gm-Message-State: AFeK/H34FlC8IqpKUr9vu8Lp2SXCnLrSzBdZKQUWs8Bqp8SKe6w+Y8IJSQYEALgqOVn3jQo5 X-Received: by 10.99.178.6 with SMTP id x6mr70861217pge.80.1492034341034; Wed, 12 Apr 2017 14:59:01 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:e401:669a:a07c:f6fb? ([2620:101:80fc:224:e401:669a:a07c:f6fb]) by smtp.gmail.com with ESMTPSA id s11sm38377547pgc.61.2017.04.12.14.58.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 14:58:59 -0700 (PDT) From: Nils Ohlmeier Message-Id: <344BC011-39FB-4613-A6A4-35CF323485DF@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F30D9C0E-0EDF-4CE8-8C0C-3A74FA8AAE72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 14:58:54 -0700 In-Reply-To: Cc: Cullen Jennings , perc@ietf.org To: Russ Housley References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:59:05 -0000 --Apple-Mail=_F30D9C0E-0EDF-4CE8-8C0C-3A74FA8AAE72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Russ, Yes the keys between Alice and Bob get exchanged directly between the = clients. (Note: the MD acts as relay on the IP layer for all of = Cullen=E2=80=99s =E2=80=98Big Picture=E2=80=99 slides, as the clients = don=E2=80=99t have any direct IP connection established among them, nor = with the Key Distributor.) The Key Distributor is basically left out of the picture once it has = distributed the shared key to all clients. I=E2=80=99m currently not = aware of any reason why the Key Distributor should actually know these = client keys. Best Nils Ohlmeier > On Apr 12, 2017, at 12:01, Russ Housley wrote: >=20 > Cullen: >=20 > Thanks so much for sharing these. >=20 > I have one question about slide 7. Do these packets flow directly = from Alice to Bob and vice versa? I was expecting to see the wrapped = keys sent via the Key Distributor. >=20 > Russ >=20 >=20 >> On Apr 12, 2017, at 1:27 PM, Cullen Jennings wrote: >>=20 >> To help explain the keys in perc, I put together some slides you can = find at >>=20 >> = https://dl.dropboxusercontent.com/u/17089001/Perc/perc-explained_v3.pdf >>=20 >> and >>=20 >> https://vimeo.com/212949427 >>=20 >> Cullen >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_F30D9C0E-0EDF-4CE8-8C0C-3A74FA8AAE72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY7qMfAAoJEJ3NnGfOORkky50QAIjDOaJ+0r8RHLBJ/D5L8jdT I44wQFQPoxRhy2Z3/iMbugt+DgMjGL/Yuop0wymWzVKB7tTPu5Kapj5kUDTdUpA1 2ekLMLdX24b9m3t08P4dxhbK58b4CY38tTYbrfKs9fa6xLVooo0YvApL8Pe8W1Ov wmo/Btp7yAx2/O3tHzTXFxfLcxOXPxIG5NLlZ6FUmYPHKrrp6FenNLJbSQITj9bx kTekjUxw94qXGgYQ0syFX1ZT0f6FU6/oAS8SBnT6Jek5LvcQHhOlPIvYu9UOQQ+k 8IpR2VzJwF5/Xv7MIwNgWmM0ZasoiwXWnfQJ/yQXdvh8PQ1VjR2DR7n3TXjANT1F SMLynxB/QywW1bKkan/lVOaXQxLx2rxhsvpFWtguM5C6zIyAXMx8lvF+UQK2O18t y0gyLOwpfLldSFNgIwvxrqQD9JQZA01bxLkr/72EdM8x1XldYtlG1gcow/IamRoZ zv/OvU8isOcFOOpgKpLGyYRkbgAnOIRARHn5zlDF63f62GxdhfQ2Txy2V6EXZBlo NvRv6zvJ48sQASS8mnZYr7bxCrjBEpmjUmRNP17B/bT3NWtG1ip17KkUKpVEvS7+ tiil2u68fXzN3TMq2S/7Wuz62z9AFVzOkXzqv1lq2OFcNR+xng+DHKAD8HU24l/0 wMqq4hhta1OgF8pMropV =5TDU -----END PGP SIGNATURE----- --Apple-Mail=_F30D9C0E-0EDF-4CE8-8C0C-3A74FA8AAE72-- From nobody Wed Apr 12 15:49:01 2017 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 5B8BD12EB64 for ; Wed, 12 Apr 2017 15:48:59 -0700 (PDT) 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] 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 kLAio8erMVr6 for ; Wed, 12 Apr 2017 15:48:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73D4128BBB for ; Wed, 12 Apr 2017 15:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1608D300455 for ; Wed, 12 Apr 2017 18:48:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3U6UYkcwhVK4 for ; Wed, 12 Apr 2017 18:48:55 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BA115300098; Wed, 12 Apr 2017 18:48:55 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_35BBAE4B-336A-431F-B267-74D1BBB2670D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 18:48:55 -0400 In-Reply-To: <344BC011-39FB-4613-A6A4-35CF323485DF@mozilla.com> Cc: perc@ietf.org To: Nils Ohlmeier , Cullen Jennings References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <344BC011-39FB-4613-A6A4-35CF323485DF@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 22:48:59 -0000 --Apple-Mail=_35BBAE4B-336A-431F-B267-74D1BBB2670D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nils: >=20 > The Key Distributor is basically left out of the picture once it has = distributed the shared key to all clients. I=E2=80=99m currently not = aware of any reason why the Key Distributor should actually know these = client keys. I am not suggesting that the Key Distributor ought to know the client = keys. Of course, it does have the key needed to decrypt if it ever got = the packets. I was thinking about the complexity associated with middleboxes, = especially NATs and firewalls. Alice and Bob already have = communications with the Key Distributor and the Media Distributor. = Sending the wrapped key via one of them could avoid a bunch of = complexity associated with the peer-to-peer communications. Russ --Apple-Mail=_35BBAE4B-336A-431F-B267-74D1BBB2670D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Nils:

The Key Distributor is basically = left out of the picture once it has distributed the shared key to all = clients. I=E2=80=99m currently not aware of any reason why the Key = Distributor should actually know these client keys.

I am not = suggesting that the Key Distributor ought to know the client keys. Of = course, it does have the key needed to decrypt if it ever got the = packets.

I was thinking about the = complexity associated with middleboxes, especially NATs and firewalls. =  Alice and Bob already have communications with the Key Distributor = and the Media Distributor.  Sending the wrapped key via one of them = could avoid a bunch of complexity associated with the peer-to-peer = communications.

Russ




= --Apple-Mail=_35BBAE4B-336A-431F-B267-74D1BBB2670D-- From nobody Wed Apr 12 16:06:11 2017 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 0873A127876 for ; Wed, 12 Apr 2017 16:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwGCj4moidIS for ; Wed, 12 Apr 2017 16:06:08 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3CB12EA98 for ; Wed, 12 Apr 2017 16:06:04 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c198so20132155pfc.1 for ; Wed, 12 Apr 2017 16:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Dv3eIDAkI5GN7mSAc29gZaVcI1JLWW3juRFGRtQU+MY=; b=OyBBaiWWzWSHl2oO4yIBUe+3vbzyt5MLfWRRNLGqCkHgJXy+OZWUOtIIltNJtLRPvS 831iRw8GP4UfOKYdtL5HVxO78oI4394wfg3L9YE1yPE2Jt65oBveIXJlLC5vD9aDVxpN NxgNYFfevoxysS+jAjkBJunwl2fnULd1CFkEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Dv3eIDAkI5GN7mSAc29gZaVcI1JLWW3juRFGRtQU+MY=; b=XmBj8NNKX+tJJqIoUrRQUatGn9hS1XK2pH56rNcZQozMceGN3Jpd7H7XO3UKdksnLI 9DXAIR7UyaJP2970lTQotfxnVvPdXb7lXEHjY7vZqDJwrpAG4LX2cei2NvUaaiB5VaS0 5zQe7m/lZPi363o2pKCmmVWe+wVop4DzhmfGx0UcQVEY1JEI+GcYIKEJu8d5leza9YQk +3OQBEgEVFjVvArNXQWzu+LW7dSgZqKRM/rrwniNt+0YNufqkSlr55I2vYNPgpBiDmZ+ h4OMFIdG/X11UmJVkIw5uv7e5XwyyRS+LqxYcpik2jShyfORwQqixuVQawanjO0MEwXQ VvzQ== X-Gm-Message-State: AN3rC/4Aeli7bIjUrbqtoFKgfFmUkCibWzBdX31iGPnZ45mZXiEGg4C2 kua5v4MOYTKrzK/aZkIxaQ== X-Received: by 10.99.101.135 with SMTP id z129mr150002pgb.164.1492038364034; Wed, 12 Apr 2017 16:06:04 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:e401:669a:a07c:f6fb? ([2620:101:80fc:224:e401:669a:a07c:f6fb]) by smtp.gmail.com with ESMTPSA id d3sm38502361pgc.37.2017.04.12.16.06.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 16:06:02 -0700 (PDT) From: Nils Ohlmeier Message-Id: <39EA789B-F1A1-4D30-B68E-F1B6B6EC1EA6@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_51348903-E690-48B6-97FA-36F08FC982C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 16:05:59 -0700 In-Reply-To: Cc: Cullen Jennings , perc@ietf.org To: Russ Housley References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <344BC011-39FB-4613-A6A4-35CF323485DF@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 23:06:10 -0000 --Apple-Mail=_51348903-E690-48B6-97FA-36F08FC982C7 Content-Type: multipart/alternative; boundary="Apple-Mail=_5C79223D-F555-4399-9824-F45FE6D415D4" --Apple-Mail=_5C79223D-F555-4399-9824-F45FE6D415D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Russ, > On Apr 12, 2017, at 15:48, Russ Housley wrote: >=20 > Nils: >>=20 >> The Key Distributor is basically left out of the picture once it has = distributed the shared key to all clients. I=E2=80=99m currently not = aware of any reason why the Key Distributor should actually know these = client keys. >=20 > I am not suggesting that the Key Distributor ought to know the client = keys. Of course, it does have the key needed to decrypt if it ever got = the packets. While the Key Distributor obviously knows the shared yellow key, you = will notice that it does not know the red keys. > I was thinking about the complexity associated with middleboxes, = especially NATs and firewalls. Alice and Bob already have = communications with the Key Distributor and the Media Distributor. = Sending the wrapped key via one of them could avoid a bunch of = complexity associated with the peer-to-peer communications. The =E2=80=98Big Picture=E2=80=99 slides up to slide 7 do not take IP = layer connections into account. Both endpoints, Alice and Bob, will have = IP connections to the MD. So the key exchange on slide seven gets = relayed on the IP layer through the MD. You can see that on slide 14 and = 15. Sure both endpoints also maintain their DTLS connection to the KD, but = since these connection are relayed on the IP layer through the MD again, = exchanging the red sending keys through the KD would only add extra = delays. I fact I think that in case of the =E2=80=9Ccloud KD=E2=80=9D on slide = 12 Bob does not even have to have a connection to the KD. I would expect = that arrow #0 goes to WebEx box, which then chooses a KD and talks to it = in the name of Bob. But that is probably a detail of how people want to = deploy this. Best Nils Ohlmeier --Apple-Mail=_5C79223D-F555-4399-9824-F45FE6D415D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Russ,

On Apr 12, 2017, at 15:48, Russ = Housley <housley@vigilsec.com> wrote:

Nils:

The Key Distributor is basically = left out of the picture once it has distributed the shared key to all = clients. I=E2=80=99m currently not aware of any reason why the Key = Distributor should actually know these client keys.

I am = not suggesting that the Key Distributor ought to know the client keys. = Of course, it does have the key needed to decrypt if it ever got the = packets.

While = the Key Distributor obviously knows the shared yellow key, you will = notice that it does not know the red keys.

I was = thinking about the complexity associated with middleboxes, especially = NATs and firewalls.  Alice and Bob already have communications with = the Key Distributor and the Media Distributor.  Sending the wrapped = key via one of them could avoid a bunch of complexity associated with = the peer-to-peer communications.

The =E2=80=98Big Picture=E2=80=99 slides up to = slide 7 do not take IP layer connections into account. Both endpoints, = Alice and Bob, will have IP connections to the MD. So the key exchange = on slide seven gets relayed on the IP layer through the MD. You can see = that on slide 14 and 15.
Sure both endpoints also maintain = their DTLS connection to the KD, but since these connection are relayed = on the IP layer through the MD again, exchanging the red sending keys = through the KD would only add extra delays.

I fact I think that in case of the =E2=80=9Ccloud = KD=E2=80=9D on slide 12 Bob does not even have to have a connection to = the KD. I would expect that arrow #0 goes to WebEx box, which then = chooses a KD and talks to it in the name of Bob. But that is probably a = detail of how people want to deploy this.

Best
  Nils Ohlmeier

= --Apple-Mail=_5C79223D-F555-4399-9824-F45FE6D415D4-- --Apple-Mail=_51348903-E690-48B6-97FA-36F08FC982C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY7rLXAAoJEJ3NnGfOORkk6WkP+wQ81DIYf7hizis3lkY/kHUE DJAHj8zQKhInjzsoXhyAmANoWH13dzRoXtw+Mc5fkAMVlRydtX4rhj7wCQ/01+NR GrjU/73fGlbv96oWlz3rd2k126mOioJSMstjr+2ZddhZV3ghItGOxDj3kfTdtw+O 5Kr7T8ptaT8YP103pDUKrDoVCgJQyI4VFlGnyaDhI9QFzM7h8d3IZI1fqtOCS9Z3 36vhfrEbEGCglNXT+Wb4K4ADmHM08H9PjXPxstDIjokrVcA0+semp2RmRnhVFd1Q gL4xn/FwiXPTX237zmc78u51kyTOC1xhT01Z5od9RCIDm/NHwVBO5caHUkpTrOV5 wlnWqNarM12VTTJQTopBjQ25ZU26JAXjDYQuSHgxoqfDSnzteaXrUe3GBR2y/mQ6 fjq+JeJZchw5Xtojw/YnLHrSyAf6YdeexRcI2NZ9GB53RU4uuUCvUi5ujdhUWt9w 4vvUAqr15ciL4rSsU0xdmXZ3mC1p+7hAaigoi21vUzBo/vsYIFIyNJbup580GaEg vIsm/fETgEUIUklpBxnPWUcPcbZBNlvviL1MI/n2dmqz18/85wQ5h/PDFrOW11P8 6vUbsgd5STBif7oHQNB5ittxgDC1NZzB5TN/Erh6HeVAe1FubZGshnMSLulpHbgl YbVMVH7AfE0YDZ+l5TdA =/loX -----END PGP SIGNATURE----- --Apple-Mail=_51348903-E690-48B6-97FA-36F08FC982C7-- From nobody Wed Apr 12 17:10:18 2017 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 CBAD912786A for ; Wed, 12 Apr 2017 17:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su9DnhbU6DyQ for ; Wed, 12 Apr 2017 17:10:15 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 22BE0127599 for ; Wed, 12 Apr 2017 17:10:15 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id t189so35581860wmt.1 for ; Wed, 12 Apr 2017 17:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EbkoI3hBlT++1P8TUr5025UgCzDvQDXKjLslCffTIPs=; b=le7+Mx8GAYCObjwdTM0UTeDybrBylJHgHgWpYN45M9K/IyQPUVwK6IXXzVGIWlaY9a qlOZaGX4nyY84GOFkYW9i9OsqlQbxMGstOESeKxvcwi30LncGOuqXYWz8F5iU8S2bKr7 XBcesGNHXFo0GjYJnrrSGtxtbNKkspRq6Vdsp4oeg21vnWttg4VMfNgcxrJ+FBKA3QwY q6gChZrSUD3ylAmShL9l6hMvhYzCpPVOjWwO2qZJGDMHvEaXGD5wc3aH3ukDZd7ANtR0 4tgqI5OTHL25/28aX6QEk0bKXyR80MGdLCEhSIoGoD8OasoGB7vHgsENuSYxPDKZUjze XY7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EbkoI3hBlT++1P8TUr5025UgCzDvQDXKjLslCffTIPs=; b=IrU3hd4Mpy8E1f0jap9/i/0tvMdg9XZp018QlmjHfVEljKkLXldWAB99pdyQ96MzpN NUcZZET0dROrGYiSppnwlhjCdtLLfYLQwEWO3uCoBOSYpeSiCxdkoGl4PifO6IOcKcDz bSS0/M7BiMP34BIAmUuOuEDl39OgrntAggnDZoLftbAy9R/k/dXtDMttGtYUTosx3fMh 8dqwt1ZiNnQwxC0TtEo0NqIFb/QvGNZhatuSgI7NlUrTab+dkbgfM+CsEOozm69iPEbe JZQCK4x7yHyo9iWAflk3JbyXpMu5gAJSLZZ/gJihoNvE08Vlce/kYZRIXyA7WBPGe98t 35/g== X-Gm-Message-State: AN3rC/4TXUoW5TkDTJoH8CMzWCfhZuG1dsNmtduI/9svn0Ri5Hc9D+sA ebRvdUehYaahukHXUvFTPn6sZbIL4uKE X-Received: by 10.28.10.70 with SMTP id 67mr22572024wmk.131.1492042213481; Wed, 12 Apr 2017 17:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Wed, 12 Apr 2017 17:10:12 -0700 (PDT) In-Reply-To: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> From: Richard Barnes Date: Wed, 12 Apr 2017 20:10:12 -0400 Message-ID: To: Cullen Jennings Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114416301ff82e054d012689 Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 00:10:17 -0000 --001a114416301ff82e054d012689 Content-Type: text/plain; charset=UTF-8 It's really not clear to me how these slides map to the mechanisms we have on the table. Could someone explain how you accomplish what's in these slides with DTLS-SRTP and EKT? On Wed, Apr 12, 2017 at 1:27 PM, Cullen Jennings wrote: > To help explain the keys in perc, I put together some slides you can find > at > > https://dl.dropboxusercontent.com/u/17089001/Perc/perc-explained_v3.pdf > > and > > https://vimeo.com/212949427 > > Cullen > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a114416301ff82e054d012689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's really not clear to me how these slides map to th= e mechanisms we have on the table.=C2=A0 Could someone explain how you acco= mplish what's in these slides with DTLS-SRTP and EKT?


On Wed, Ap= r 12, 2017 at 1:27 PM, Cullen Jennings <fluffy@iii.ca> wrote:
To help explain the keys in perc, I put tog= ether some slides you can find at

https://dl.dropboxusercontent= .com/u/17089001/Perc/perc-explained_v3.pdf

and

https://vimeo.com/212949427

Cullen


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

--001a114416301ff82e054d012689-- From nobody Thu Apr 13 12:45:21 2017 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 80B27131613 for ; Thu, 13 Apr 2017 12:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 MB6T0oCTGEss for ; Thu, 13 Apr 2017 12:45:17 -0700 (PDT) Received: from smtp117.iad3a.emailsrvr.com (smtp117.iad3a.emailsrvr.com [173.203.187.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0397A12945C for ; Thu, 13 Apr 2017 12:45:16 -0700 (PDT) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6E51B25216; Thu, 13 Apr 2017 15:45:13 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id DF6E825291; Thu, 13 Apr 2017 15:45:12 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 13 Apr 2017 15:45:13 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <39EA789B-F1A1-4D30-B68E-F1B6B6EC1EA6@mozilla.com> Date: Thu, 13 Apr 2017 13:45:11 -0600 Cc: perc@ietf.org, Nils Ohlmeier Content-Transfer-Encoding: quoted-printable Message-Id: <3FA50EC2-6360-4A9B-BF2B-FC7D0387B5A2@iii.ca> References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <344BC011-39FB-4613-A6A4-35CF323485DF@mozilla.com> <39EA789B-F1A1-4D30-B68E-F1B6B6EC1EA6@mozilla.com> To: Russ Housley X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:45:18 -0000 Russ,=20 I'll update these slides to show the arrows going thought the Media = Distributor - I think that will make it clearer that all the packets = flowing from Alice to Media Distributor to Bob.=20 Thanks.=20 > On Apr 12, 2017, at 5:05 PM, Nils Ohlmeier = wrote: >=20 > Russ, >=20 >> On Apr 12, 2017, at 15:48, Russ Housley wrote: >>=20 >> Nils: >>>=20 >>> The Key Distributor is basically left out of the picture once it has = distributed the shared key to all clients. I=E2=80=99m currently not = aware of any reason why the Key Distributor should actually know these = client keys. >>=20 >> I am not suggesting that the Key Distributor ought to know the client = keys. Of course, it does have the key needed to decrypt if it ever got = the packets. >=20 > While the Key Distributor obviously knows the shared yellow key, you = will notice that it does not know the red keys. >=20 >> I was thinking about the complexity associated with middleboxes, = especially NATs and firewalls. Alice and Bob already have = communications with the Key Distributor and the Media Distributor. = Sending the wrapped key via one of them could avoid a bunch of = complexity associated with the peer-to-peer communications. >=20 > The =E2=80=98Big Picture=E2=80=99 slides up to slide 7 do not take IP = layer connections into account. Both endpoints, Alice and Bob, will have = IP connections to the MD. So the key exchange on slide seven gets = relayed on the IP layer through the MD. You can see that on slide 14 and = 15. > Sure both endpoints also maintain their DTLS connection to the KD, but = since these connection are relayed on the IP layer through the MD again, = exchanging the red sending keys through the KD would only add extra = delays. >=20 > I fact I think that in case of the =E2=80=9Ccloud KD=E2=80=9D on slide = 12 Bob does not even have to have a connection to the KD. I would expect = that arrow #0 goes to WebEx box, which then chooses a KD and talks to it = in the name of Bob. But that is probably a detail of how people want to = deploy this. >=20 > Best > Nils Ohlmeier >=20 From nobody Thu Apr 13 12:54:34 2017 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 0B623131622 for ; Thu, 13 Apr 2017 12:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bLKRQJpNoaC for ; Thu, 13 Apr 2017 12:54:31 -0700 (PDT) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEAE13161C for ; Thu, 13 Apr 2017 12:54:30 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 10F165833; Thu, 13 Apr 2017 15:54:30 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 95A0658B7; Thu, 13 Apr 2017 15:54:29 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 13 Apr 2017 15:54:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 13 Apr 2017 13:54:28 -0600 Cc: perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:54:33 -0000 > On Apr 12, 2017, at 2:10 AM, Sergio Garcia Murillo = wrote: >=20 > On 12/04/2017 3:29, Cullen Jennings wrote: >>=20 >> Take the DTMF example where it is a policy decision on sender if the = MD was going to be able to decrypt the DTMF of not. The sender encrypts = it one way or the other then send it to the MD and then the MD sends it = to the receiver. The receiver needs some way to know how the sender = encrypted it so that the receiver can correctly decode it. The receiver = would do the outer decrypt, then look at the flag to decide if the inner = decrypt should also be done. > I should have never brought up the DTMF topic.. :) >=20 > I think that the discussion is around the recover streams (RTX, = ulpfec, RED and Flex Fec), which IMHO doesn't make sense at all to be = E2E encrypted. If we keep them HBH nothing needs to be changed to the = current specs/implementetions. So I would expect a very well supported = argument in favor of E2E recover streams that justifies the need for any = new mechanisms. I'm certainly not arguing for things like RTX to be done end to end. I = think any repair algorithm is better HBH. 100% agree that with no changes to any of the existing drafts you can = clearly do HBH repair using RTX in the mode where the RTX is on a = separate RTP stream that does not use double. That works fine - I don't = understand what concern Emil had with doing that but the main reason I = proposed this was to try and find something that addressed Emil's = problem. However, it seem that I have no clue what that problem is so I = may stop trying until the actual problem is clearer.=20 >=20 > Regarding the flag for media streams, I don't have a strong opinion = yet, but I think it is better to keep both discussions separated. From nobody Thu Apr 13 13:12:11 2017 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 C833D129A9B for ; Thu, 13 Apr 2017 13:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=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 FETNHIgXLnYW for ; Thu, 13 Apr 2017 13:12:08 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 5917C1296CF for ; Thu, 13 Apr 2017 13:12:08 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id o81so119011083wmb.1 for ; Thu, 13 Apr 2017 13:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U8XTC+nrZCs9jzm1XLPG5EM93rqcV0q1lZvr03S0fYE=; b=VjWwjywuGyjuDgSBM0q6DA+Y89kcW+NO2h3nTTiW7V4Jt4+vfZtqfDEUhXaZH0q0Rj qvIyrWTSpI8r6wqjUcNd7F8nXhNuBNIlUazy/X9lBYeWKS4G/vJDOT5ESjYrkiTvHaN0 po/O2/dRTB75/DnUeLgJXpnMEokdtt3I24Ux7sAtJG+oKW6uluP6CGlRDgtSTsC1OUoG DQ/+8dD1RBa+GGlLHPvlTdEGNvfpdVa0Os3GLZDHUfhYT4Uw+jAQ66EKCZLjhgWHqQmZ 2Lkw+oRjeYw/uotn/q/QUx3ay1gkClWgoc7dAz8Sp5rd6LCfJ9MJsIgp2hNx8fcrhnUc uJvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U8XTC+nrZCs9jzm1XLPG5EM93rqcV0q1lZvr03S0fYE=; b=GQ2HS5qYn6GUHqR1wuIHODyYBYptMakykJaqvW1BDrxztY0uLFnS5vInWkDjlGp1v/ AwalIO3klPodJqvPeRwMbYAZxG4MT3MraKtKVCB0hU0EO0QCWpsB+ggg1qiwmWEhIexp 0sqPwTDqwBZKy7p/h1kcW9JyZh/4UGDaGGV234cWuboU8Px9cxYB6zT8yp3L7cPEFCah acczyLyYIqGJgWsBzLPOtqqn28Cyvdenp2U91f7Hl2zmgwE1n3mv0/S++bSsdK20kAwX QVE5kDXAtlPL+zShF2sglWM2gChFOnMvNyP1QLrSlBBp8EIKoA0W7aertNNp1RJiv2kp bqQQ== X-Gm-Message-State: AN3rC/6iECqCSU0JRzqvHgCVlYzUx0v0zCcB7eS2d+Zv56XDus36Nur5 XnA+YuoVBW+SO9eWeDz77XdewMlj3A== X-Received: by 10.28.236.135 with SMTP id h7mr24838021wmi.74.1492114325692; Thu, 13 Apr 2017 13:12:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.195.15 with HTTP; Thu, 13 Apr 2017 13:11:44 -0700 (PDT) In-Reply-To: References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> From: Emil Ivov Date: Thu, 13 Apr 2017 15:11:44 -0500 Message-ID: To: Cullen Jennings Cc: Sergio Garcia Murillo , perc@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:12:11 -0000 On Thu, Apr 13, 2017 at 2:54 PM, Cullen Jennings wrote: > >> On Apr 12, 2017, at 2:10 AM, Sergio Garcia Murillo wrote: >> >> On 12/04/2017 3:29, Cullen Jennings wrote: >>> >>> Take the DTMF example where it is a policy decision on sender if the MD= was going to be able to decrypt the DTMF of not. The sender encrypts it on= e way or the other then send it to the MD and then the MD sends it to the r= eceiver. The receiver needs some way to know how the sender encrypted it so= that the receiver can correctly decode it. The receiver would do the outer= decrypt, then look at the flag to decide if the inner decrypt should also = be done. >> I should have never brought up the DTMF topic.. :) >> >> I think that the discussion is around the recover streams (RTX, ulpfec, = RED and Flex Fec), which IMHO doesn't make sense at all to be E2E encrypted= . If we keep them HBH nothing needs to be changed to the current specs/impl= ementetions. So I would expect a very well supported argument in favor of E= 2E recover streams that justifies the need for any new mechanisms. > > I'm certainly not arguing for things like RTX to be done end to end. I th= ink any repair algorithm is better HBH. > > 100% agree that with no changes to any of the existing drafts you can cle= arly do HBH repair using RTX in the mode where the RTX is on a separate RTP= stream that does not use double. Are you now suggesting that RTX should be *only* HBH protected? Or do you mean triple protection? > That works fine - I don't understand what concern Emil had with doing tha= t but the main reason I proposed this was to try and find something that ad= dressed Emil's problem. However, it seem that I have no clue what that prob= lem is so I may stop trying until the actual problem is clearer. I really have no problem. There is only one reasonable way to do RTX with double, which consists in doing RTX and in between the two layers of protection and I am perfectly fine with that. You seem to have an issue with this, that I believe goes beyond implementation specifics, and I think you can certainly solve it somehow if you tried. Emil --=20 https://jitsi.org From nobody Thu Apr 13 14:27:35 2017 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 A12751296B0 for ; Thu, 13 Apr 2017 14:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 j4cQPUm9VccB for ; Thu, 13 Apr 2017 14:27:30 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3A6127843 for ; Thu, 13 Apr 2017 14:27:30 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l28so42653090wre.0 for ; Thu, 13 Apr 2017 14:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8jMpDE7wadwY+4tN5xMU1v0mXyFce4dochS1BduMYLE=; b=JF71Tm9FLel0lXv/pJdXB0YLE2s9JDcbms7PZzHZxH94rnjYlZ/j+jN6EuG0cVt2Ng aFSj3s4eg8JH7bkX4dQRMMbQP5gUWTxSQgQVFLTI+ui+Ad44EMU2UEOO4QYlGGe0iR6p w1d+erVQqN/Qm7X7Jm9Lgqxls/DtSj+L7dWX8/qHrRKyjR/wIsjXsTsUJC9mNd5xOE8Q h4yHQOIEBU2M1VSAfIAQpC4XoSqVK/b5hbTaVAKhElmabtf4iiAl4xoNZ8SvDEz5pMb7 7OlUJaaM8FF6PVhmkk2zqaCC2VMQh8IrWDRLAgyr7AeELr/9T6eEs2R++PIm/YpS75Zv bCWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8jMpDE7wadwY+4tN5xMU1v0mXyFce4dochS1BduMYLE=; b=iT0b27joCMKJX4a+WyanwN734VOObJ1WFsPDlkvCAqDZoPPyHOXCUS3UctwNcqXv6z 9b/wKUHs4GFFDlq1AeKwE8KfOIDGDfWSWUP7kRXJuW82zFhPSX/eU3j1WWz+g/KPml09 a3Z8nWAPA5JUhKKYgeGGFj4qDCixavlPcXE1KBYRYMmcXICgXWMR5oH0fUR0z4/fKSs9 uNma8IpNwjclcfDWCox8/g86gUpzCr6TRAYsxFcnpAy3kHdpVXlFD2VUDxQV9L4nJ+G4 7omvjilEqo4YItx2rL/7wyFPcw93y6TGU+pyq3GkwshNj1uvmxQrzs0ctHuc1Px2HdFg Txfg== X-Gm-Message-State: AN3rC/6amh1CuXwRPLcDHtPHuhIaRtzPXMSY1H6XM+X8T69Z4BqrnUoJ fzqW1vvm8tn0waeFyAWdUVCcvNaFiyWb X-Received: by 10.223.153.18 with SMTP id x18mr4628868wrb.55.1492118848951; Thu, 13 Apr 2017 14:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.195.15 with HTTP; Thu, 13 Apr 2017 14:27:08 -0700 (PDT) In-Reply-To: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> From: Emil Ivov Date: Thu, 13 Apr 2017 16:27:08 -0500 Message-ID: To: Cullen Jennings Cc: perc@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 21:27:33 -0000 This is very helpful! Thanks for putting it together! Emil On Wed, Apr 12, 2017 at 12:27 PM, Cullen Jennings wrote: > To help explain the keys in perc, I put together some slides you can find at > > https://dl.dropboxusercontent.com/u/17089001/Perc/perc-explained_v3.pdf > > and > > https://vimeo.com/212949427 > > Cullen > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc -- https://jitsi.org From nobody Thu Apr 13 16:08:39 2017 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 B56D4126DC2 for ; Thu, 13 Apr 2017 16:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 nnziw5UAmoBe for ; Thu, 13 Apr 2017 16:08:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4173A1204DA for ; Thu, 13 Apr 2017 16:08:36 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3DN8Ygp039089 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 13 Apr 2017 18:08:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Richard Barnes , Cullen Jennings Cc: perc@ietf.org References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> From: Adam Roach Message-ID: <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> Date: Thu, 13 Apr 2017 18:08:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 23:08:38 -0000 On 4/12/17 19:10, Richard Barnes wrote: > It's really not clear to me how these slides map to the mechanisms we > have on the table. Could someone explain how you accomplish what's in > these slides with DTLS-SRTP and EKT? Cullen's slides expand on the key exchange that I used to illustrate. As far as I know, the DTLS-SRTP and EKT handling has not changed since I created that older deck. I believe that the final three slides of that deck should answer your question. /a From nobody Thu Apr 13 19:12:09 2017 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 CE22A126BF7 for ; Thu, 13 Apr 2017 19:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6rNvK77l4Du for ; Thu, 13 Apr 2017 19:12:04 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 66D6F1200C5 for ; Thu, 13 Apr 2017 19:12:04 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id z109so44784804wrb.1 for ; Thu, 13 Apr 2017 19:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=obcynZwb8+Usebnrss5vE0UPs1/X9PlQqf8YWPv5tOs=; b=OoRcFQsiQV3+6hfo65WdfYMwsJvTHTPLUZE8VGuphIQYzkbOcqrRpwfVpAHZIruamn UTeMBVng9FHWjSj7p7qVrSAWfSpC2Bf0w60uk8+1IhrWEOgky2yNffcLtKItnBpDQTLd 7Djzoz1z842Nq9WbH9A+GdrbybQ01e+XXutAzB8NpZQsTFmL3VbTJYQAkAZ5QgMKo+3Y 9D+8dxg5Ulc9ei75+5sQvyfLp8AKwFwdPOttW1Si5/ZFAGpj8acc1Emk/hZJj7B0ek9k 0pDc0nknSh6fMq1E+cq1nsY4bJyddbAVFISO2A5zQ7W3PgSvtAGLKZYcLslsKgg/635B jbBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=obcynZwb8+Usebnrss5vE0UPs1/X9PlQqf8YWPv5tOs=; b=aogSK3s1xvRcqMmZLAnH2MZ+kjxsmpkHeFQAUY9hrVbxPvOT0FynmFyNJxRXkqPwIp jP1z2w0KaA6zSiTRIKz+XOgUhJqAYdzhzAFjwX/NDgGFr0DEq7fCPY3Chgh02PnK6stC YIiqXuHeNwMQs5lwpdsMc4llIJKFu8JLUW+2wRtI95TasweHntjweBRpReGRWlO5oY0l bPQ219AQ5eC13XWzayQhTdWtkPmS1B+O4wlQhMm8lYK/TrnC+s4/c2UXs+VRfCy7agPI CaLR5P+R2bpeo0LjsZRDZ9hlkhGf0Tb/DgpJp+BMd758bRnIAx2Jnpn6NbW6hHl0SKYY DIpg== X-Gm-Message-State: AN3rC/4eiFHNt2HDPGhmvBDRGjr8wSLXa0MiXPYN0duXFP6fUogg1J3p TT/Qc9Pc2dYLtNRgMcA6khzCiciwAQ== X-Received: by 10.223.136.246 with SMTP id g51mr5094312wrg.187.1492135922605; Thu, 13 Apr 2017 19:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Thu, 13 Apr 2017 19:12:01 -0700 (PDT) In-Reply-To: <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> From: Richard Barnes Date: Thu, 13 Apr 2017 22:12:01 -0400 Message-ID: To: Adam Roach Cc: Cullen Jennings , perc@ietf.org Content-Type: multipart/alternative; boundary=001a11491b609fc448054d16f713 Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:12:07 -0000 --001a11491b609fc448054d16f713 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach wrote: > On 4/12/17 19:10, Richard Barnes wrote: > >> It's really not clear to me how these slides map to the mechanisms we >> have on the table. Could someone explain how you accomplish what's in >> these slides with DTLS-SRTP and EKT? >> > > Cullen's slides expand on the key exchange that I used < > https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to > illustrate. As far as I know, the DTLS-SRTP and EKT handling has not > changed since I created that older deck. I believe that the final three > slides of that deck should answer your question. Here's where you're losing me, though: These entities called "HBH key" and "E2E key" don't actually exist; they're internal to the double transform. >From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's twice the length of an AES key. So you never send around an "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH halves. When participant A sends an EKT message to participant B when B joins, it sets both the HBH and E2E keys that B will use to decrypt packets from A's SSRC. This implies that there's no need for the MD to do re-encryption HBH unless it wants to change something. Here's the story as I understand it at this point: - Each endpoint establishes an HBH+E2E key from the DTLS handshake that it uses for transmission - The KD tells the MD the HBH half of each of these keys - The KD tells each endpoint an EKTKey in an ekt_key message (encrypted under some key derived from the DTLS handshake) - On join, each endpoint sends an EKTCiphertext message with its HBH+E2E transmission key, encrypted with the EKTKey In colorful slides (with apologies to the red/green colorblind in the audience): https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing Does this seem correct to folks? --Richard > > > /a > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a11491b609fc448054d16f713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/17 19:10, Richard Barnes wrote:
It's really not clear to me how these slides map to the mechanisms we h= ave on the table.=C2=A0 Could someone explain how you accomplish what's= in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/s= lides-95-perc-4.pdf> to illustrate. As far as I know, the DTLS-= SRTP and EKT handling has not changed since I created that older deck. I be= lieve that the final three slides of that deck should answer your question.=

Here's where you're losing me, tho= ugh: These entities called "HBH key" and "E2E key" don&= #39;t actually exist; they're internal to the double transform.=C2=A0 F= rom every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that= 's twice the length of an AES key.=C2=A0 So you never send around an &q= uot;E2E key" or an "HBH" key, you send around one big key th= at has E2E and HBH halves.

When participant A send= s an EKT message to participant B when B joins, it sets both the HBH and E2= E keys that B will use to decrypt packets from A's SSRC.=C2=A0 This imp= lies that there's no need for the MD to do re-encryption HBH unless it = wants to change something.

Here's the story as= I understand it at this point:

- Each endpoint es= tablishes an HBH+E2E key from the DTLS handshake that it uses for transmiss= ion
- The KD tells the MD the HBH half of each of these keys
- The KD tells each endpoint an EKTKey in an ekt_key message (encrypt= ed under some key derived from the DTLS handshake)
- On join, eac= h endpoint sends an EKTCiphertext message with its HBH+E2E transmission key= , encrypted with the EKTKey

In colorful slides (wi= th apologies to the red/green colorblind in the audience):
--Richard

=C2=A0


/a


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

--001a11491b609fc448054d16f713-- From nobody Thu Apr 13 21:42:52 2017 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 543AD124D37 for ; Thu, 13 Apr 2017 21:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9dlUmoUrUN9 for ; Thu, 13 Apr 2017 21:42:48 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 EB9F71200C5 for ; Thu, 13 Apr 2017 21:42:47 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 21so39432458pgg.1 for ; Thu, 13 Apr 2017 21:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s5woZ1nudFcXZMxnrM4YvAsayrNcGMy3L9wTpySXFOk=; b=FVjLdxd2PxElDrDjDwtsBOuAo0qKc2Wzw4Gpfy/SDWyW6auKbqNJeloMTbqEPi/1ZW r+XJAcDSRVlsE0nXm3EJ5deLZ7Fv9p8/RY5HcW66JaphbZR2KVGLCxe3CIgU5fgM+USr j4TfhDT2E+HBxPgkUyjzLSBPDO0t+jKcZQEcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s5woZ1nudFcXZMxnrM4YvAsayrNcGMy3L9wTpySXFOk=; b=YyZfZzSN98O4mCGOlJvHiswjobKbVzzvNVsY0PPckAufcNITnbReARTLFvgAvitnxv EZFQGhdQIJhVgzvzAk/Zq2l20y/1Hz2mUXKDcXZicRMlqxXsmu9AhIiVRxM3DLLU/Ql9 VcZSAhciwCU9fzZYtPgUAhcVHX0sENXAux8P1+loCfsn0IE6PtEtPGEtC4cQquSueBTp coOOv+Vj7qfbooLwukzYmie4asFPn8St0RCRw+zoC6t09WKPpZBVshg8XUmc8M+jYKMK ROCyMSJby7Absey7w6z8Nw2kMvJEoAo34ZixExqxqFEhsHOzGxBD8UTkQZyuSeek08oG 3JYA== X-Gm-Message-State: AN3rC/4b0FX+Ib91ckBiwTFj2EOaQZZECpvHf02WKsPNffMtWtguwLoy hWBo1mbzu5tZrlx8 X-Received: by 10.98.8.143 with SMTP id 15mr5247492pfi.268.1492144967216; Thu, 13 Apr 2017 21:42:47 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:2467:e607:c03f:df61? ([2601:647:4601:ec84:2467:e607:c03f:df61]) by smtp.gmail.com with ESMTPSA id l68sm886649pfl.37.2017.04.13.21.42.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 21:42:46 -0700 (PDT) From: Nils Ohlmeier Message-Id: <8C448941-12A3-4339-8379-07EF9D4BB15D@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BA178607-FB55-47C3-89D3-930159974501"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Apr 2017 21:42:44 -0700 In-Reply-To: Cc: Adam Roach , perc@ietf.org, Cullen Jennings To: Richard Barnes References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 04:42:50 -0000 --Apple-Mail=_BA178607-FB55-47C3-89D3-930159974501 Content-Type: multipart/alternative; boundary="Apple-Mail=_47FA23C0-F8A5-451A-94FF-1B6461BECA42" --Apple-Mail=_47FA23C0-F8A5-451A-94FF-1B6461BECA42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 13, 2017, at 19:12, Richard Barnes wrote: > Here's where you're losing me, though: These entities called "HBH key" = and "E2E key" don't actually exist; they're internal to the double = transform. =46rom every other perspective -- DTLS-SRTP, EKT, etc -- = there is one key that's twice the length of an AES key. So you never = send around an "E2E key" or an "HBH" key, you send around one big key = that has E2E and HBH halves. >=20 > When participant A sends an EKT message to participant B when B joins, = it sets both the HBH and E2E keys that B will use to decrypt packets = from A's SSRC. This implies that there's no need for the MD to do = re-encryption HBH unless it wants to change something. >=20 > Here's the story as I understand it at this point: >=20 > - Each endpoint establishes an HBH+E2E key from the DTLS handshake = that it uses for transmission > - The KD tells the MD the HBH half of each of these keys > - The KD tells each endpoint an EKTKey in an ekt_key message = (encrypted under some key derived from the DTLS handshake) > - On join, each endpoint sends an EKTCiphertext message with its = HBH+E2E transmission key, encrypted with the EKTKey >=20 > In colorful slides (with apologies to the red/green colorblind in the = audience): >=20 > = https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h= 1znahWajg/edit?usp=3Dsharing = >=20 > Does this seem correct to folks? I see you point here. And it start to dawn on me why there are sometimes = discussions about one or two crypto contexts. The part which I don=E2=80=99t get though is what you haven=E2=80=99t = documented in your slides when endpoints start to send RTP: - A uses the red EH key to encrypt its RTP packet and sends it to the MD - Now you seem to suggest the MD could work in two different modes: - #1: it just takes the unmodified packet and forwards its to B (and C = & D), so its operating in a 1:N relay mode (similar to a TURN relay not = paying attention to the packet, but relaying 1:N instead of 1:1 like = your normal TURN relay) - #2: it needs to re-write the PT for example: - so it decrypts the outer encryption with the red H key - replaces the PT value and inserts (or replaces) the OHB extension = header - now it needs to encrypt the packet again. Which H key does it use? For me natural choice at this point would be to use the green H key, = because that is the key the MD shares with participant B. But then how = would B know if it needs to use the red or the green H key to decrypt = the outer encryption. So it looks to me like it needs to use the red H key instead again to = encrypt. Which looks strange because then it appears as if the MD is = impersonating A at this point. Clarification on how an MD which wants to re-write packets under your = description works would be appreciated. Thanks Nils Ohlmeier --Apple-Mail=_47FA23C0-F8A5-451A-94FF-1B6461BECA42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 13, 2017, at 19:12, Richard Barnes <rlb@ipv.sx> = wrote:
Here's = where you're losing me, though: These entities called "HBH key" and "E2E = key" don't actually exist; they're internal to the double = transform.  =46rom every other perspective -- DTLS-SRTP, EKT, etc = -- there is one key that's twice the length of an AES key.  So you = never send around an "E2E key" or an "HBH" key, you send around one big = key that has E2E and HBH halves.

When participant A sends an EKT message = to participant B when B joins, it sets both the HBH and E2E keys that B = will use to decrypt packets from A's SSRC.  This implies that = there's no need for the MD to do re-encryption HBH unless it wants to = change something.

Here's the story as I understand it at this point:

- Each endpoint = establishes an HBH+E2E key from the DTLS handshake that it uses for = transmission
- The KD tells the MD the HBH half of = each of these keys
- The KD tells each endpoint an = EKTKey in an ekt_key message (encrypted under some key derived from the = DTLS handshake)
- On join, each endpoint sends an = EKTCiphertext message with its HBH+E2E transmission key, encrypted with = the EKTKey

In = colorful slides (with apologies to the red/green colorblind in the = audience):


Does this seem correct = to folks?

I see you point here. And it start to dawn on me = why there are sometimes discussions about one or two crypto = contexts.

The part which I don=E2=80=99= t get though is what you haven=E2=80=99t documented in your slides when = endpoints start to send RTP:
- A uses the red EH key to = encrypt its RTP packet and sends it to the MD
- Now you seem = to suggest the MD could work in two different modes:
  - = #1: it just takes the unmodified packet and forwards its to B (and C = & D), so its operating in a 1:N relay mode (similar to a TURN relay = not paying attention to the packet, but relaying 1:N instead of 1:1 like = your normal TURN relay)
  - #2: it needs to re-write the = PT for example:
    - so it decrypts the outer = encryption with the red H key
    - replaces the PT = value and inserts (or replaces) the OHB extension = header
    - now it needs to encrypt the packet = again. Which H key does it use?

For = me natural choice at this point would be to use the green H key, because = that is the key the MD shares with participant B. But then how would B = know if it needs to use the red or the green H key to decrypt the outer = encryption.
So it looks to me like it needs to use the red H = key instead again to encrypt. Which looks strange because then it = appears as if the MD is impersonating A at this point.

Clarification on how an MD which wants to = re-write packets under your description works would be = appreciated.

Thanks
 Nils Ohlmeier

= --Apple-Mail=_47FA23C0-F8A5-451A-94FF-1B6461BECA42-- --Apple-Mail=_BA178607-FB55-47C3-89D3-930159974501 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY8FNFAAoJEJ3NnGfOORkkBNkP/jpMhV9dzwQpCQF2kBNWWzoG BpRznbo4pUUBDG7tO6CGWKX/FZgldEnAGKUxHjeic3q6DY8ttYFhJDeYj/CIuHPu Ci/tifIWKX00KLBJVwCuqdnz5miin4Zk+BdW0qr2Xje+LttH1gS9SMCtqeL9zfjL CdB/BMfwE5ekGwKKQXeiKta1Nkx4Cq0CKsA8Bt2VMlpg9IqRHG0APdf776afpJt4 12A1G9ILUi8p3CQ5HVFEdtV6FwpSm3M7kfRzoCpeJe8dCQiQlRPItKO6Jrabi/FE C50Bz7AyuO2i09TiCyDXJWUGbSBBn9fya1C84rojDagWHdTRDWKvo1rDs2d1Oqwq n1P5EV21n0tYOaVnWRCfvJlmb2tGhyQDUFeeAbZU5kzxk+B9pUAKknPnr5Yq1WsM V1R2ygJery3qASWjcTXzrKd0M5N9o8BXMLp6mm3181gaUHUo5kyS5DwCJy0yJh5d YUZYyDyJLdtxGOXPZrUG0AdazdrWLYyPMXaZGhEChrS6VD6tTUMNtSbZcJOMrMS3 0y11s7csAQONYCOOo7qU8Dq8B0wY4dwoRiUggi+DY1nclk4hQKQAmfZzDLN9QVjH F4wBrcEWXq3LkEg2+WIXxbOul8ORNJuPmIgz255ynQVmhsRWkZocE9qN7TZ59PoB JMHFk3gJf1gguDRUmTW6 =/cnc -----END PGP SIGNATURE----- --Apple-Mail=_BA178607-FB55-47C3-89D3-930159974501-- From nobody Fri Apr 14 00:06:53 2017 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 730F812947F for ; Fri, 14 Apr 2017 00:06:51 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 iySAwrVdphCz for ; Fri, 14 Apr 2017 00:06:49 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 0EE2C127011 for ; Fri, 14 Apr 2017 00:06:49 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id z109so46855758wrb.1 for ; Fri, 14 Apr 2017 00:06:48 -0700 (PDT) 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=kF5xTJUzXwjZeGdtSeAquy5x+QkOf21F2dMHRAGWB6Q=; b=sQvjbg9Qvf9Qz3Yt4QAQ24GDkaw91TGBb9AuHrK8hIA6QzXgQ9CK929tmmVivwcC7A yNxIkqvH2bXcLoCzqX/IYx2ubIs50hPeTUEHZlF+LVHgZVp9319NqZopuL5i1K8eBq9Y uQKgVCcTeE42wo5PZQAqjvfqeOwxP+3Tnw3xUOjpJqDGp6if7KtZspKuU3SPdbzvATpY 6sr0noKllIwLS8gd6g2/j9mWFfvxohnVpvIWzbYyZNxEhp9UlI2tpgswxlGktI64+yEK 3+da05LoR18lXBrgQnCxkfOU2WbeAR8h1Sa8RrgbS3qVCCq1V3IT0v9tJNpazac8c8On z3zw== 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=kF5xTJUzXwjZeGdtSeAquy5x+QkOf21F2dMHRAGWB6Q=; b=mMyp4KaWzn5hQt/rdMwVTSTafHJjpdlnwOSVnWZp8FlB9hK6j4QjiR+SVZeeVyaJzL c92Nm+DOT7yxSoiFwqZaVTQ1vrzhQrykY69f4SbcI4afEsjn0J02tLBbp4ThjAiQWWp6 /spM7g9SmuijUoi/u0tecUay6x121/YvfHPXgPzYv+HgBbik+NJ+wGpdMBcZ9V46NBQG 0uISSR3M8QPEN56r1STQG1X7GCL7+mM8dA0Kr+PQL1DM2lqIrW0qu27T1BZs3UICzkLH vk1KFCOrBGUVlOmp0JLpECYaPe2IlyC9eEZH+lrvEYWY/FWllAsJZGO8FNe0gRlE0fqf pxTQ== X-Gm-Message-State: AN3rC/58fPFSQ9jQzactsQ0+cJAXrPN1yZaRh2vPNF1QTc2p+nszbvo/ xHQc2+ntPAssrQjaoOGlYnZqoAqA+Q== X-Received: by 10.223.150.121 with SMTP id c54mr5974293wra.202.1492153607098; Fri, 14 Apr 2017 00:06:47 -0700 (PDT) MIME-Version: 1.0 References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> In-Reply-To: From: Emil Ivov Date: Fri, 14 Apr 2017 07:06:36 +0000 Message-ID: To: Adam Roach , Richard Barnes Cc: Cullen Jennings , perc@ietf.org Content-Type: multipart/alternative; boundary=001a11477ff0b3bebb054d1b1507 Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 07:06:51 -0000 --001a11477ff0b3bebb054d1b1507 Content-Type: text/plain; charset=UTF-8 On Thu, 13 Apr 2017 at 21:12, Richard Barnes wrote: > On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach wrote: > >> On 4/12/17 19:10, Richard Barnes wrote: >> >>> It's really not clear to me how these slides map to the mechanisms we >>> have on the table. Could someone explain how you accomplish what's in >>> these slides with DTLS-SRTP and EKT? >>> >> >> Cullen's slides expand on the key exchange that I used < >> https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to >> illustrate. As far as I know, the DTLS-SRTP and EKT handling has not >> changed since I created that older deck. I believe that the final three >> slides of that deck should answer your question. > > > Here's where you're losing me, though: These entities called "HBH key" and > "E2E key" don't actually exist; they're internal to the double transform. > From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key > that's twice the length of an AES key. So you never send around an "E2E > key" or an "HBH" key, you send around one big key that has E2E and HBH > halves. > I think that this view of the situation is probably the reason for a big part of the disagreements in the working group. I do see the appeal here but looking at this as a single key adds way too many unnecessary constraints. This is certainly not how our implementation works. Emil > When participant A sends an EKT message to participant B when B joins, it > sets both the HBH and E2E keys that B will use to decrypt packets from A's > SSRC. This implies that there's no need for the MD to do re-encryption HBH > unless it wants to change something. > > Here's the story as I understand it at this point: > > - Each endpoint establishes an HBH+E2E key from the DTLS handshake that it > uses for transmission > - The KD tells the MD the HBH half of each of these keys > - The KD tells each endpoint an EKTKey in an ekt_key message (encrypted > under some key derived from the DTLS handshake) > - On join, each endpoint sends an EKTCiphertext message with its HBH+E2E > transmission key, encrypted with the EKTKey > > In colorful slides (with apologies to the red/green colorblind in the > audience): > > > https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing > > Does this seem correct to folks? > > --Richard > > > >> >> >> /a >> >> >> _______________________________________________ >> 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 --001a11477ff0b3bebb054d1b1507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, 13 Apr 2017 at 21:12, Richard Barnes <rlb@ipv.sx> wrote:=
On Thu, Apr 13, 2017 at 7:08 = PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/1= 7 19:10, Richard Barnes wrote:
It's really not clear to me how these slides map to the mechanisms we h= ave on the table.=C2=A0 Could someone explain how you accomplish what's= in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/slides= -95-perc-4.pdf> to illustrate. As far as I know, the DTLS-SRTP and E= KT handling has not changed since I created that older deck. I believe that= the final three slides of that deck should answer your question.

Here's where you're losing me, though: The= se entities called "HBH key" and "E2E key" don't ac= tually exist; they're internal to the double transform.=C2=A0 From ever= y other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's t= wice the length of an AES key.=C2=A0 So you never send around an "E2E = key" or an "HBH" key, you send around one big key that has E= 2E and HBH halves.

= I think that this view of the situation is probably the reason for a big pa= rt of the disagreements in the working group.

I do= see the appeal here but looking at this as a single key adds way too many = unnecessary constraints.

This is certainly not how= our implementation works.

Emil


When participant A sends an= EKT message to participant B when B joins, it sets both the HBH and E2E ke= ys that B will use to decrypt packets from A's SSRC.=C2=A0 This implies= that there's no need for the MD to do re-encryption HBH unless it want= s to change something.

Here's the story as I u= nderstand it at this point:

- Each endpoint establ= ishes an HBH+E2E key from the DTLS handshake that it uses for transmission<= /div>
- The KD tells the MD the HBH half of each of these keys
- The KD tells each endpoint an EKTKey in an ekt_key message (encrypted u= nder some key derived from the DTLS handshake)
- On join, each en= dpoint sends an EKTCiphertext message with its HBH+E2E transmission key, en= crypted with the EKTKey

In colorful slides (with a= pologies to the red/green colorblind in the audience):

=

Does this seem correct to = folks?

--Richard

=C2= =A0


/a


_______________________________________________
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
--001a11477ff0b3bebb054d1b1507-- From nobody Fri Apr 14 00:14:21 2017 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 A71CD12762F for ; Fri, 14 Apr 2017 00:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 FXeY2_dJ90-8 for ; Fri, 14 Apr 2017 00:14:17 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 46CB012704B for ; Fri, 14 Apr 2017 00:14:17 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u2so60344970wmu.0 for ; Fri, 14 Apr 2017 00:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Ocl9YeqEpEEwzTg835rSERS2NC5DNIR/GvzfuQIfdRU=; b=biNMg1YIdfH8UVnGiVwvxE9iWpUaC8lnnH8BHg1H83xtFf6Nkeoc2MoT0YS13lEW7x 8MJ1x6NQoRcVjLKSE5T7xNKWpC/2AeKMpSvjh1iYD5PBgsAKbrk8hSLqXqIDn61RWHxb kgVMx2TwHcWmH51ghWokp07uy/e4U6orycWUOZqQww5jXqVXitEKFDfF0AxTpUB1qCjS eyYWjOUzbFMoKtjOwa/irY7u6VESOhUJzD+X66Os4ODZ3yDh1COpSoQ6OqN8HF3HoXHf /TQUvBJLSg+xT+80HBjW7TrKxoWKtUfzHsskOek4jBYNSGqE8U0LsBpB8R8DJRYj3JEh YsNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Ocl9YeqEpEEwzTg835rSERS2NC5DNIR/GvzfuQIfdRU=; b=BM7vKfND3ZGrTHasY73KwL0GHE2u55hYwbXb1Dl3v6oFV6axFcpsKG+Lc6LSXd6YbR VMIsd8/537k6pe11qKkyWuwwS+mOD9ZbS1//2bWAVXfTC0xJsomYxBF+dvDfcsIIQ18J PoMELhZ0pJZa8727cLaw9z0juC/E/6/7Bchi5BXh7moXX2vKHtKGvK8w+jwkkzWHOw84 KFySU1dKcMuNBx/SKdx9Rq6bCk3YEjPA4dBiNJ18SjaYFdmZ9Bhf77grDDF5afCoEuaY CjhbwPf7o5LjfdTWUJHZBFA119rhP349KWZ3rmNJKsMQMKVpislYsr/mL161iGb2b2XT tubA== X-Gm-Message-State: AN3rC/5b5M2niXAXHlY3k2smOt0CZgYTupMnNT+GXHrzxQ/bDEBMqcc/ TFCXS3VIq7I7A7UtJiM= X-Received: by 10.28.197.135 with SMTP id v129mr22752146wmf.55.1492154055441; Fri, 14 Apr 2017 00:14:15 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id f135sm1680058wmd.7.2017.04.14.00.14.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 00:14:14 -0700 (PDT) To: perc@ietf.org References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> From: Sergio Garcia Murillo Message-ID: <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> Date: Fri, 14 Apr 2017 09:14:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------41D3F1E116879286401846C0" Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 07:14:20 -0000 This is a multi-part message in MIME format. --------------41D3F1E116879286401846C0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 14/04/2017 9:06, Emil Ivov wrote: > On Thu, 13 Apr 2017 at 21:12, Richard Barnes wrote: > > On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach > wrote: > > On 4/12/17 19:10, Richard Barnes wrote: > > It's really not clear to me how these slides map to the > mechanisms we have on the table. Could someone explain > how you accomplish what's in these slides with DTLS-SRTP > and EKT? > > > Cullen's slides expand on the key exchange that I used > > to illustrate. As far as I know, the DTLS-SRTP and EKT > handling has not changed since I created that older deck. I > believe that the final three slides of that deck should answer > your question. > > > Here's where you're losing me, though: These entities called "HBH > key" and "E2E key" don't actually exist; they're internal to the > double transform. From every other perspective -- DTLS-SRTP, EKT, > etc -- there is one key that's twice the length of an AES key. So > you never send around an "E2E key" or an "HBH" key, you send > around one big key that has E2E and HBH halves. > > > I think that this view of the situation is probably the reason for a > big part of the disagreements in the working group. > > I do see the appeal here but looking at this as a single key adds way > too many unnecessary constraints. > > This is certainly not how our implementation works. I agree, and IMHO saying that there is "only one key that is the result of concatenation of two keys" is an artificial construct. The truth is that there is a pair of keys as Cullen slides show, wether they are transfer and set in a single blob or not is irrelevant. Best regards Sergio --------------41D3F1E116879286401846C0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 14/04/2017 9:06, Emil Ivov wrote:
On Thu, 13 Apr 2017 at 21:12, Richard Barnes <rlb@ipv.sx> wrote:
On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/17 19:10, Richard Barnes wrote:
It's really not clear to me how these slides map to the mechanisms we have on the table. Could someone explain how you accomplish what's in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to illustrate. As far as I know, the DTLS-SRTP and EKT handling has not changed since I created that older deck. I believe that the final three slides of that deck should answer your question.

Here's where you're losing me, though: These entities called "HBH key" and "E2E key" don't actually exist; they're internal to the double transform. From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's twice the length of an AES key. So you never send around an "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH halves.

I think that this view of the situation is probably the reason for a big part of the disagreements in the working group.

I do see the appeal here but looking at this as a single key adds way too many unnecessary constraints.

This is certainly not how our implementation works.

I agree, and IMHO saying that there is "only one key that is the result of concatenation of two keys" is an artificial construct. The truth is that there is a pair of keys as Cullen slides show, wether they are transfer and set in a single blob or not is irrelevant.

Best regards
Sergio
--------------41D3F1E116879286401846C0-- From nobody Fri Apr 14 00:22:57 2017 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 82242126BFD for ; Fri, 14 Apr 2017 00:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a7CjtGDW2Zx for ; Fri, 14 Apr 2017 00:22:53 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB908124234 for ; Fri, 14 Apr 2017 00:22:52 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id i5so38159511pfc.2 for ; Fri, 14 Apr 2017 00:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ChIXyVccRNcjXCdyHLHGdBWibrMPNzjVrn6rLGUlhtk=; b=NmN0qZlOWFJmMi9YQQVXerhf+Brq9CWjpAY5r0XAC9oI1UU/UCwzW0HtE7f8IzlDSC O2cLV+FDmf1VA25iCjmVmjjWWVKUs/mgFvy2qpwD49lffq7LSbO3LBgdG7OZRIN2czZj M8K/eabvPodEUzXyo3yJ1rlAf6G6ybEwcEuZ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ChIXyVccRNcjXCdyHLHGdBWibrMPNzjVrn6rLGUlhtk=; b=UPFk/yWIpvhP4xsjF4/eWEKfovTROgGE/C8WgYb0jbG/yaBhHTzFuVyIf4kg0GZvLv 8C4BT4gWZFhi8eI4kQM7SN+6Xw/P0qJXSHnLQWT9LERKQJwF4+vIEt/XXsxp20VuboGa QAcemY0Kg8IudrPMlwT2Ae6c2sWDl6/fHy0n6lU2wCuuCNTtbPfNehEZdEK15YA28DES Zk0zH8bDXZe0uqC99DwrsVcv2Zfkwba5HiyyQEl8/T82Q+o21HhrSmnF8AxfXmSs4eSM niYJ9+hNNDcJp63F73NpqMQHMHamT1ET8EvDI48yoX3NvDyGdolIZuuwGvveFYtBOqVo YsDg== X-Gm-Message-State: AN3rC/4bhA+nm1kbscSG1ZPAo1f3YE9QXN5Efj/DYU/P+ubeiu2DcrQD mvKoo7OIUqBZzP6V X-Received: by 10.84.175.67 with SMTP id s61mr6990247plb.126.1492154572317; Fri, 14 Apr 2017 00:22:52 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:2467:e607:c03f:df61? ([2601:647:4601:ec84:2467:e607:c03f:df61]) by smtp.gmail.com with ESMTPSA id e67sm1713815pfe.64.2017.04.14.00.22.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 00:22:51 -0700 (PDT) From: Nils Ohlmeier Message-Id: <23A9AE73-D241-452F-98C9-93941A2CC7F6@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E4BCAEE8-0E4E-419B-93E2-BC7956B6F9D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 00:22:48 -0700 In-Reply-To: <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> Cc: perc@ietf.org To: Sergio Garcia Murillo References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 07:22:55 -0000 --Apple-Mail=_E4BCAEE8-0E4E-419B-93E2-BC7956B6F9D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 14, 2017, at 00:14, Sergio Garcia Murillo = wrote: >=20 > I agree, and IMHO saying that there is "only one key that is the = result of concatenation of two keys" is an artificial construct. The = truth is that there is a pair of keys as Cullen slides show, wether they = are transfer and set in a single blob or not is irrelevant. In Richard=E2=80=99s scenario the whole double key is derived from the = DTLS connection. So the KD also knows the full key, but throws away half = of it (and only sends the other half to the MD). In Cullen=E2=80=99s slide 6 it says the endpoints =E2=80=9Chas=E2=80=9D = an end-to-end key. I assume that means it either generates a new key for = every call. Or could this key be administrated to be the same one for = all calls? To me Cullen=E2=80=99s scenario makes more sense from the point of = distributing only the minimum amount of keys. Nils --Apple-Mail=_E4BCAEE8-0E4E-419B-93E2-BC7956B6F9D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY8HjJAAoJEJ3NnGfOORkkapUP/0B8plkFLCE3+OGOPsB7dZ4l nmV63+SxH30gEdE+cB1GJ6RO/IPU9LVXtGxhv79MWpSL43uxNVp3MUS1/gdcKZ+j t+COK5zKE3MHqCzFWd0x/1K/8nLwkM022NOc6kaJ3magbnYFHmJvfwQ0hkFYiic/ ZNgNO+hytb0LuctaHxRt/RJmbXCbzwMjvnr/4grTYXXhHyqoV4wQbfgwxY5JBExb j/q3QgMMfD82DJNoMvawDiwr/9OmB9TcElP60r2AI6tCoO603h+6yL/Bi/A2ZH6h F3nWeVXhPvs1Vg5ZQyG0Rkenxs0kxnbec1KygSmt1M2pDc3Hdv44sBnE0vPeD+8o rT9Q3se5OboCaIpU3LYRaEiPW+sBSkYrRLM2cAumRjMhBsAaAftIf7OlejGXydkk iEGv5MFkGaNSo/Aft2aRQGeQ/U5S+QdcSQuKe5GE6vDwRCLuZJ2nu5QQg4PyMRan QFqhLKXYmEMossp2ViuNZbu0lel8QQM31KtVkOzUzz6z9T4Sd6KD1dFNubu9SLud yw+z6b9sdOg2YiqKp6njyDLVm+CO9bHgnvbE24VTZudf/qMGRh5GsNF/c/R5T7+N AmoOPTncG6Cj2RfuHSGUmgqEf8oCZ6Lj59VRjo+sTvY3Mvmb86HHU3iWZjxWCCAh 2DRGams/KjNd79yDu9mt =xQtL -----END PGP SIGNATURE----- --Apple-Mail=_E4BCAEE8-0E4E-419B-93E2-BC7956B6F9D9-- From nobody Fri Apr 14 00:25:57 2017 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 AF60E126BFD for ; Fri, 14 Apr 2017 00:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZsVxLG1-HnBK for ; Fri, 14 Apr 2017 00:25:54 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 CC56F124234 for ; Fri, 14 Apr 2017 00:25:53 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id y18so510657wmh.0 for ; Fri, 14 Apr 2017 00:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=CFnqlqqBTOh7I2mF1KWlNWxO0QAQhc+cietcWA2L9hc=; b=b4YNTaLSP5BkQ1p79CuXT8E/M9AL0k7KFQQutUPqLBbPIXuC2endlTIDobCtJnZPx0 tLjI2+w1HVg0ulOdxsqwQp+ucW9Ql526pFUsQYs8bLBeLEIvA8wxv50cuTuvQ8C/9Upy UQHDkaZoE7ooqBgxPcAD+TGk+I8Q8Gosp3OA/xEbA5MAjZEvJCr7dObOt/SsK/CRXcL6 TLty5zjZl/4RHD8nJoR7jVwVyVnIlHQO3sDjjgJ1Pn6Yn463kphxAuyuSGI0y1gvUujA F/2G+1cQ/+klcCLtsmoINAgeVEaparUI8C6hGdYnrh49gR6xQ8Ifu9768o67TH620D67 ba8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CFnqlqqBTOh7I2mF1KWlNWxO0QAQhc+cietcWA2L9hc=; b=EAhVtLXMCEiNX/h75um74honG/suYFYXspdX544WQM3hzYx+vBteIM82L20A0w2wsm P/xjjYT0MOVe7hgko1uMaaeG4Ycd3Yse5+01DBRtkAgYwgDLQ4WsE2L4AsHlpIz+iiV/ lidzcMDuHF/H7sVF4+KoOH+H3aep2CWl0wQyKHDkoxX8Mcqc97KVheheT6pMYoym1Hox TfHHnLpnfraTPQ7QObPRUi6yrtQSUy8ZhBBL2oGSEryLxXMQ4rP8XN3yrrSh+8IZ76g+ dqxkTrIo7PZkGQYkePfowEuD3WpuZtgrPitkJySVk5CkQzdHHGql/wwcT6bwT7VyhQgm 2kew== X-Gm-Message-State: AN3rC/52Z0DtM8DtRWFSElSPC3mDznaK4bSkMSSckO9xahl6guAAKXV5 pD8XtZX6wY7Dxg== X-Received: by 10.28.127.196 with SMTP id a187mr27543467wmd.119.1492154752375; Fri, 14 Apr 2017 00:25:52 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id q131sm1715982wmd.0.2017.04.14.00.25.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 00:25:51 -0700 (PDT) To: Emil Ivov , Cullen Jennings References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Fri, 14 Apr 2017 09:25:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 07:25:56 -0000 On 13/04/2017 22:11, Emil Ivov wrote: > On Thu, Apr 13, 2017 at 2:54 PM, Cullen Jennings wrote: > >> That works fine - I don't understand what concern Emil had with doing that but the main reason I proposed this was to try and find something that addressed Emil's problem. However, it seem that I have no clue what that problem is so I may stop trying until the actual problem is clearer. > I really have no problem. There is only one reasonable way to do RTX > with double, which consists in doing RTX and in between the two layers > of protection and I am perfectly fine with that. > > You seem to have an issue with this, that I believe goes beyond > implementation specifics, and I think you can certainly solve it > somehow if you tried. Seems that there has been a misunderstanding then. Are we in agreement then that RTX/FEC (or any other reconstruction streams) will be done *ONLY HBH*? Best regards Sergio From nobody Fri Apr 14 06:44:50 2017 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 83FD812F265 for ; Fri, 14 Apr 2017 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fBX1gOglr6w for ; Fri, 14 Apr 2017 06:44:48 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E3112F258 for ; Fri, 14 Apr 2017 06:44:47 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id w64so131220330wma.0 for ; Fri, 14 Apr 2017 06:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xjT7gwxK28pXq1ulEZm3WExMqtWEwP5kGpSJhqtBUys=; b=AvLWZ4x5r1OJ1LjHKuSm8dP4X0oqFiGdrPiqfuyczes/v745fk/WslZKEsslGSgz+W 3LmAewbuntkDkp/xb2nqnFwDf2gain2UIBalMehOooIqqPa6zuFZlmePCvLuicQXfDDG cJXYH0Zr9T+wgE1Vi72NS5OlAHl26JUK5PnhJiSF5Nqx/b4m9vbF5cobxTSg1+Xt4GzZ Zk/qSNrDGtp6j4GO/l4w8sfhqGuS9j2z0fGazTyi9CceZklV7vNIiOIW41o2Lmxu44LV HCd/jLgiGotRKVSshTCSD41c/HekST7SVEfH+jh9M0IiUn7T/whmUVdZNmlV8/hZxCUW mK9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xjT7gwxK28pXq1ulEZm3WExMqtWEwP5kGpSJhqtBUys=; b=AAoD4JjBvKkFjwgIRsOzhykCveccq6ynUqBveDBEOl8dZUY8FrTHYQMEPsGzaGazOO BDFGcKS0D6CkObBz0tw+JgV5Ei4wr3lTccqXYr6bVBF//gOrExHdl18YOIQ6QN5ql6v4 /o4GrByn3HQmS71oWHareZXvhq+YCcVp20HAy1BL2FwVE5iQLP11MiyRSlNtFfG7OGWj aZBI7d9OxyRPgTCkejTH914G5qcit5Lzz7P6zD3GuOdWyKoOazeSYaWWI8uyVQosew/p zlZ/tCfq1RPGZQNrApCVMfzNyws+oK5cg72WrsHX9yoAsdf86meEriE7ByRWQuy5qwXb uHhA== X-Gm-Message-State: AN3rC/5vadiopYtc1pv2Gx8taoeUUwW3z7sB0ADiYlEhl3WjMD2kviAA rB8uJfK1QHIFMaTQmb7TJlL+cebEOro6 X-Received: by 10.28.66.74 with SMTP id p71mr7953314wma.131.1492177485643; Fri, 14 Apr 2017 06:44:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Fri, 14 Apr 2017 06:44:45 -0700 (PDT) In-Reply-To: <8C448941-12A3-4339-8379-07EF9D4BB15D@mozilla.com> References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> <8C448941-12A3-4339-8379-07EF9D4BB15D@mozilla.com> From: Richard Barnes Date: Fri, 14 Apr 2017 09:44:45 -0400 Message-ID: To: Nils Ohlmeier Cc: Adam Roach , perc@ietf.org, Cullen Jennings Content-Type: multipart/alternative; boundary=94eb2c074aaaf98b36054d20a43b Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 13:44:49 -0000 --94eb2c074aaaf98b36054d20a43b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 14, 2017 at 12:42 AM, Nils Ohlmeier wrote: > > On Apr 13, 2017, at 19:12, Richard Barnes wrote: > Here's where you're losing me, though: These entities called "HBH key" an= d > "E2E key" don't actually exist; they're internal to the double transform. > From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key > that's twice the length of an AES key. So you never send around an "E2E > key" or an "HBH" key, you send around one big key that has E2E and HBH > halves. > > When participant A sends an EKT message to participant B when B joins, it > sets both the HBH and E2E keys that B will use to decrypt packets from A'= s > SSRC. This implies that there's no need for the MD to do re-encryption H= BH > unless it wants to change something. > > Here's the story as I understand it at this point: > > - Each endpoint establishes an HBH+E2E key from the DTLS handshake that i= t > uses for transmission > - The KD tells the MD the HBH half of each of these keys > - The KD tells each endpoint an EKTKey in an ekt_key message (encrypted > under some key derived from the DTLS handshake) > - On join, each endpoint sends an EKTCiphertext message with its HBH+E2E > transmission key, encrypted with the EKTKey > > In colorful slides (with apologies to the red/green colorblind in the > audience): > > https://docs.google.com/presentation/d/1LpKZSN_ > 7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=3Dsharing > > Does this seem correct to folks? > > > I see you point here. And it start to dawn on me why there are sometimes > discussions about one or two crypto contexts. > > The part which I don=E2=80=99t get though is what you haven=E2=80=99t doc= umented in your > slides when endpoints start to send RTP: > - A uses the red EH key to encrypt its RTP packet and sends it to the MD > - Now you seem to suggest the MD could work in two different modes: > - #1: it just takes the unmodified packet and forwards its to B (and C = & > D), so its operating in a 1:N relay mode (similar to a TURN relay not > paying attention to the packet, but relaying 1:N instead of 1:1 like your > normal TURN relay) > - #2: it needs to re-write the PT for example: > - so it decrypts the outer encryption with the red H key > - replaces the PT value and inserts (or replaces) the OHB extension > header > - now it needs to encrypt the packet again. Which H key does it use? > If I'm understanding everything correctly, it uses the red H key. EKT sets the encryption key for an SSRC, so when A sent the red EH key to B in EKT, B learned that it needs to use the red EH key to decrypt what it receives from A's SSRC. So the MD needs to use the red H key to re-do the HBH transform. In other words, the same E2E and HBH keys are always used together. If you have two pairs (E1, H1) and (E2, H2), then E1 is used for the inner transform if and only if H1 is used for the outer transform, and likewise for E2/H2. --Richard > > For me natural choice at this point would be to use the green H key, > because that is the key the MD shares with participant B. But then how > would B know if it needs to use the red or the green H key to decrypt the > outer encryption. > So it looks to me like it needs to use the red H key instead again to > encrypt. Which looks strange because then it appears as if the MD is > impersonating A at this point. > > Clarification on how an MD which wants to re-write packets under your > description works would be appreciated. > > Thanks > Nils Ohlmeier > > --94eb2c074aaaf98b36054d20a43b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 14, 2017 at 12:42 AM, Nils Ohlmeier <<= a href=3D"mailto:nohlmeier@mozilla.com" target=3D"_blank">nohlmeier@mozilla= .com> wrote:

<= div>On Apr 13, 2017, at 19:12, Richard Barnes <rlb@ipv.sx> wrote:
Here's wher= e you're losing me, though: These entities called "HBH key" a= nd "E2E key" don't actually exist; they're internal to th= e double transform.=C2=A0 From every other perspective -- DTLS-SRTP, EKT, e= tc -- there is one key that's twice the length of an AES key.=C2=A0 So = you never send around an "E2E key" or an "HBH" key, you= send around one big key that has E2E and HBH halves.

<= div>When participant A sends an EKT message to participant B when B joins, = it sets both the HBH and E2E keys that B will use to decrypt packets from A= 's SSRC.=C2=A0 This implies that there's no need for the MD to do r= e-encryption HBH unless it wants to change something.

<= div>Here's the story as I understand it at this point:

- Each endpoint establishes an HBH+E2E key from the DTLS handshake= that it uses for transmission
- The KD tells the MD the HBH half= of each of these keys
- The KD tells each endpoint an EKTKey in = an ekt_key message (encrypted under some key derived from the DTLS handshak= e)
- On join, each endpoint sends an EKTCiphertext message with i= ts HBH+E2E transmission key, encrypted with the EKTKey

=
In colorful slides (with apologies to the red/green colorblind in the = audience):

=

Does this seem correct to folks?

I see you point here. And it star= t to dawn on me why there are sometimes discussions about one or two crypto= contexts.

The part which I don=E2=80=99t get thou= gh is what you haven=E2=80=99t documented in your slides when endpoints sta= rt to send RTP:
- A uses the red EH key to encrypt its RTP packet= and sends it to the MD
- Now you seem to suggest the MD could wo= rk in two different modes:
=C2=A0 - #1: it just takes the unmodif= ied packet and forwards its to B (and C & D), so its operating in a 1:N= relay mode (similar to a TURN relay not paying attention to the packet, bu= t relaying 1:N instead of 1:1 like your normal TURN relay)
=C2=A0= - #2: it needs to re-write the PT for example:
=C2=A0 =C2=A0 - s= o it decrypts the outer encryption with the red H key
=C2=A0 =C2= =A0 - replaces the PT value and inserts (or replaces) the OHB extension hea= der
=C2=A0 =C2=A0 - now it needs to encrypt the packet again. Whi= ch H key does it use?

If I'= m understanding everything correctly, it uses the red H key.

=
EKT sets the encryption key for an SSRC, so when A sent the red = EH key to B in EKT, B learned that it needs to use the red EH key to decryp= t what it receives from A's SSRC.=C2=A0 So the MD needs to use the red = H key to re-do the HBH transform.

In other wor= ds, the same E2E and HBH keys are always used together.=C2=A0 If you have t= wo pairs (E1, H1) and (E2, H2), then E1 is used for the inner transform if = and only if H1 is used for the outer transform, and likewise for E2/H2.

--Richard

=C2=A0

For me natural choice at this point would be to use the green H key, = because that is the key the MD shares with participant B. But then how woul= d B know if it needs to use the red or the green H key to decrypt the outer= encryption.
So it looks to me like it needs to use the red H key= instead again to encrypt. Which looks strange because then it appears as i= f the MD is impersonating A at this point.

Clarification on h= ow an MD which wants to re-write packets under your description works would= be appreciated.

Thanks
=C2=A0Nils Ohlmeier


--94eb2c074aaaf98b36054d20a43b-- From nobody Fri Apr 14 06:50:34 2017 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 D10C312F265 for ; Fri, 14 Apr 2017 06:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dexaFCs9H6Kj for ; Fri, 14 Apr 2017 06:50:25 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 21E3112F287 for ; Fri, 14 Apr 2017 06:50:25 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id t189so65737938wmt.1 for ; Fri, 14 Apr 2017 06:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1LHJpWULEXWEY0Y3I9DVr6Rt+my5ljFC+W9D6AnJ0Vg=; b=yT6nQQlkbAe8LXY4v4cQ6RJHmInjJ7caLlSNgsLVdHbWVSIHRTwM7BczKCVDWv0Dl1 5eXHktTDKCmT7+Y/bu17bCXFsrzX62OkTX2JcOH0fdYUv4OLn4RVoxA2rRYtMEBVCkWH fmSS5gA1XEYIW3l5f1zeC1syGydxgnDN0UsIPEKVJiXqdKIQ7mo6yw7FAYWgTaDo5/qA Xqr3gYLDhNzwTnol8H+e3T4++n7igLaTnRXW8SE289vQ1JeQ1WfnnAOBNS40wqjeNnzn yztSU9WeG8cJRgv1jGy5Pf+DocY/eq8Mp4Keq8QKtalig2cCYw2K3osut69UAeYigXri 5ujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1LHJpWULEXWEY0Y3I9DVr6Rt+my5ljFC+W9D6AnJ0Vg=; b=oH8AVN73OD7oAoIqkdOsUMsGkdgXs4/1w/5UDEsUeOnnb9CuipzuUbH/ij07xwUl9H Z3FnhPBVmrdQPEkNXmagmQbTqKNQt5R7KlzdCqrZ3KlASDGa2uCLdn4jkP6i+rdNqXUM gy5Fnb1R9V1afZBQkV72jiESavXzCSslmGpAMqGVTLLoF+mHgEuiKa+vY4WjO0opIZBz ZrMQ6xedNM3cXKAu82we0kRJAHtD4kJ2qC9dzw8oerJ10xRsHPafsHq6opuLh87K89iW 6QKC4/ZCEzF4ETYyDixNWaLoc1tA+drYQgdEEvnPsHPVqw+Ws+V2ZMTRW0SQXBX5RKcl WFOg== X-Gm-Message-State: AN3rC/5LJY68p8Eb3ALguYdTkjzMCjT/7RbeuIP0ivQNvhs4hhCVcOCW G4Xdsxi0gNQC9Hspp24ZcxqcmcUAnWyz X-Received: by 10.28.66.74 with SMTP id p71mr7970507wma.131.1492177823460; Fri, 14 Apr 2017 06:50:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Fri, 14 Apr 2017 06:50:22 -0700 (PDT) In-Reply-To: <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> From: Richard Barnes Date: Fri, 14 Apr 2017 09:50:22 -0400 Message-ID: To: Sergio Garcia Murillo Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c074aaa1bf171054d20b9ff Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 13:50:32 -0000 --94eb2c074aaa1bf171054d20b9ff Content-Type: text/plain; charset=UTF-8 On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 14/04/2017 9:06, Emil Ivov wrote: > > On Thu, 13 Apr 2017 at 21:12, Richard Barnes > wrote: > >> On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach wrote: >> >>> On 4/12/17 19:10, Richard Barnes wrote: >>> >>>> It's really not clear to me how these slides map to the mechanisms we >>>> have on the table. Could someone explain how you accomplish what's in >>>> these slides with DTLS-SRTP and EKT? >>>> >>> >>> Cullen's slides expand on the key exchange that I used < >>> https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to >>> illustrate. As far as I know, the DTLS-SRTP and EKT handling has not >>> changed since I created that older deck. I believe that the final three >>> slides of that deck should answer your question. >> >> >> Here's where you're losing me, though: These entities called "HBH key" >> and "E2E key" don't actually exist; they're internal to the double >> transform. From every other perspective -- DTLS-SRTP, EKT, etc -- there is >> one key that's twice the length of an AES key. So you never send around an >> "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH >> halves. >> > > I think that this view of the situation is probably the reason for a big > part of the disagreements in the working group. > > I do see the appeal here but looking at this as a single key adds way too > many unnecessary constraints. > > This is certainly not how our implementation works. > > > I agree, and IMHO saying that there is "only one key that is the result of > concatenation of two keys" is an artificial construct. > Well, at a certain level, everything we do here is an artificial construct :) There's nothing natural about the Internet. I'm not saying that there's one key because I like the aesthetics. I'm saying that because that's the semantic that's available from the protocols we're depending on here, namely DTLS-SRTP and EKT. If we want the specifications to work in terms of pairs of keys with independent halves, we'll need to patch those specifications, or require that they be used in special ways. For example, if you wanted to have the HBH key be the same for all endpoints, we would have to define how it gets synchronized; there's nothing else that's going to do that for you. Personally, I think it's cleaner to deal in terms of one key (except where we give half a key to the MD). It makes the media layer look basically the same as non-PERC for everyone but the MD, and the only cost to the MD is that it has to keep a table of HBH instead of a single one -- but of course pre-PERC, it had whole independent DTLS state per client, so that doesn't seem like a big deal. --Richard > The truth is that there is a pair of keys as Cullen slides show, wether > they are transfer and set in a single blob or not is irrelevant. > > Best regards > Sergio > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --94eb2c074aaa1bf171054d20b9ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo <= sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
On 14/04/2017 9:06,= Emil Ivov wrote:
On Thu, 13 Apr 2017 at 21:12, Richard Barnes <rlb@ipv.sx> wrote:
On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/17 19:10, Richard Barnes wrote:
It's really not clear to me how these slides ma= p to the mechanisms we have on the table.=C2=A0 Could someone explain how you accomplish what's in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://= www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to illustrate. As far as I know, the DTLS-SRTP and EKT handling has not changed since I created that older deck. I believe that the final three slides of that deck should answer your question.

Here's where you're losing me, though: These entities called "HBH key" and "E2E key&q= uot; don't actually exist; they're internal to the double transform.=C2=A0 From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's twic= e the length of an AES key.=C2=A0 So you never send aroun= d an "E2E key" or an "HBH" key, you s= end around one big key that has E2E and HBH halves.

I think that this view of the situation is probably the reason for a big part of the disagreements in the working group.

I do see the appeal here but looking at this as a single key adds way too many unnecessary constraints.

This is certainly not how our implementation works.

I agree, and IMHO saying that there is "only one key that is the result of concatenation of two keys" is an artificial construct. <= /div>

Well, at a certain level, everything = we do here is an artificial construct :)=C2=A0 There's nothing natural = about the Internet.

I'm not saying that there&= #39;s one key because I like the aesthetics.=C2=A0 I'm saying that beca= use that's the semantic that's available from the protocols we'= re depending on here, namely DTLS-SRTP and EKT.=C2=A0 If we want the specif= ications to work in terms of pairs of keys with independent halves, we'= ll need to patch those specifications, or require that they be used in spec= ial ways.=C2=A0 For example, if you wanted to have the HBH key be the same = for all endpoints, we would have to define how it gets synchronized; there&= #39;s nothing else that's going to do that for you.

<= /div>
Personally, I think it's cleaner to deal in terms of one key = (except where we give half a key to the MD).=C2=A0 It makes the media layer= look basically the same as non-PERC for everyone but the MD, and the only = cost to the MD is that it has to keep a table of HBH instead of a single on= e -- but of course pre-PERC, it had whole independent DTLS state per client= , so that doesn't seem like a big deal.

--Rich= ard

=C2=A0
The truth is that there is a pair of keys as Cullen slides show, wether they are transfer and set in a single blob or not is irrelevant.

Best regards
Sergio

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


--94eb2c074aaa1bf171054d20b9ff-- From nobody Fri Apr 14 07:37:38 2017 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 ED70412FEE1 for ; Fri, 14 Apr 2017 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 7HUYXLt704BF for ; Fri, 14 Apr 2017 07:37:35 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D101300CF for ; Fri, 14 Apr 2017 07:37:34 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x184so5734985oia.1 for ; Fri, 14 Apr 2017 07:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nrlNiIRz5QsewtrX/WlZdzpxbwQSHcDZJprGk6m9DMc=; b=VnsO7Ec4mqXlKo71VPMQ8VckH5yZ+Mkj5SV6yPkF8nOV3TFSLEYKtw5MCRw+llIbY2 N28xyoR55NPtIyBAtmD2QMH+F1pnLQ/OpZMw6vIp5ZlEmTUxDJ3/lnUmO/hGxdnhglDI dNxUbEXzQ+jXaUxZAmc5rqeFH518EJevXDAqkznb14AmVEsp0AKslKpW6PYQuz9W76CV 7eEsAu/np6JKuR6yJl6SjFAe+hwzGMWZiui50Wl2pdR+1FonI9XMcXDxNq4CpAyk6YGd /5h8IpKhQ6Y/c74z9Epm93Kpu1VFQe+rCAZXi1B+PhcAjemsyqtSZ3sU2kAsvbJEYQYb byXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nrlNiIRz5QsewtrX/WlZdzpxbwQSHcDZJprGk6m9DMc=; b=t272oBHIKBpx1WbqYa/oSUKnBpWrQHpj5SPqmLYWlClHK+a95elk+vDGRZVrh+CqCZ OXDaWq+/tST9BbMjlixeOMyTJ29fuyr29ob+2CaipEmQsCkORhMOAp3txXaXK3VVXlkj I4EVAVL699WKK9yw2Qv0rFXV++G9RjYg8hZsG07srF3zSnmXSXKJOnrLuJwQtG0mM35G rf+UcNNnFlHt8lP26VtVhQNnB8uyC+6lw8Ky4dzdurzLZ2rZVqXfjPLo3pTaEqPRLsYx I62XCbeOpHCHq/f4mPqW9ntrHxkrKmhz8+cbhYqY4bWDrucZ0mXAGdwm5Kj8fvM/Xenh Ovpg== X-Gm-Message-State: AN3rC/7FtKQ2V1BKBlCb+4KMXU1D5fJlESyh9tyzrn0kr0qDVRq5yB9B NT3wW+2+vn6keVjn/02uR9C9Rkd8ZA== X-Received: by 10.202.231.210 with SMTP id e201mr4908189oih.23.1492180654169; Fri, 14 Apr 2017 07:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Fri, 14 Apr 2017 07:37:33 -0700 (PDT) In-Reply-To: References: <2FE6CB0A-766C-4849-8398-A8112A08132E@iii.ca> From: Stephen Botzko Date: Fri, 14 Apr 2017 10:37:33 -0400 Message-ID: To: Sergio Garcia Murillo Cc: Emil Ivov , Cullen Jennings , perc@ietf.org Content-Type: multipart/alternative; boundary=001a11409526d52552054d216138 Archived-At: Subject: Re: [Perc] Proposal for RTX and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 14:37:37 -0000 --001a11409526d52552054d216138 Content-Type: text/plain; charset=UTF-8 >>>Are we in agreement then that RTX/FEC (or any other reconstruction streams) will be done *ONLY HBH*? In the case of FEC it is best if the stream is repaired HBH. It is also desirable to tailor the transmitted FEC to fit the loss characteristics of the hop. But I don't think that precludes pass-through of received FEC source packets by the MD (decrypting the inbound HBH, and re-encrypting the outbound HBH). If there's a technical reason why that has to be precluded, it'd be useful to understand it better. For me it is important that the FEC and RTX packets be authenticated HBH before being used for repair. While in some specific cases, it might be enough to authenticate the output of the reconstruction, it doesn't work for all cases. I believe that's also the motivation behind Emil's "one reasonable way". I'd like to know if there is agreement on the authentication aspect. Stephen On Fri, Apr 14, 2017 at 3:25 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 13/04/2017 22:11, Emil Ivov wrote: > >> On Thu, Apr 13, 2017 at 2:54 PM, Cullen Jennings wrote: >> >> That works fine - I don't understand what concern Emil had with doing >>> that but the main reason I proposed this was to try and find something that >>> addressed Emil's problem. However, it seem that I have no clue what that >>> problem is so I may stop trying until the actual problem is clearer. >>> >> I really have no problem. There is only one reasonable way to do RTX >> with double, which consists in doing RTX and in between the two layers >> of protection and I am perfectly fine with that. >> >> You seem to have an issue with this, that I believe goes beyond >> implementation specifics, and I think you can certainly solve it >> somehow if you tried. >> > > Seems that there has been a misunderstanding then. > > Are we in agreement then that RTX/FEC (or any other reconstruction > streams) will be done *ONLY HBH*? > > Best regards > Sergio > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a11409526d52552054d216138 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>>Are we in agr= eement then that RTX/FEC (or any other reconstruction streams) will be done= *ONLY HBH*?
In the case of FEC it is best if the stream is repaired HBH.= =C2=A0 It is also desirable to tailor the transmitted FEC to fit the loss c= haracteristics of the hop.

But I don't th= ink that precludes pass-through of received FEC source packets by the MD (d= ecrypting the inbound HBH, and re-encrypting the outbound HBH).=C2=A0 If th= ere's a technical reason why that has to be precluded, it'd be usef= ul to understand it better.


=
For me it is important that the FEC a= nd RTX packets be authenticated HBH before being used for repair.=C2=A0 Whi= le in some specific cases, it might be enough to authenticate the output of= the reconstruction, it doesn't work for all cases.=C2=A0 I believe tha= t's also the motivation behind Emil's "one reasonable way"= ;.=C2=A0 I'd like to know if there is agreement on the authentication a= spect.

Ste= phen


On Fri, Apr 14= , 2017 at 3:25 AM, Sergio Garcia Murillo <sergio.garcia.muri= llo@gmail.com> wrote:
On 13/04/2017 22:11, Emil Ivov wrote:
On Thu, Apr 13, 2017 at 2:54 PM, Cullen Jennings <fluffy@iii.ca> wrote:

That works fine - I don't understand what concern Emil had with doing t= hat but the main reason I proposed this was to try and find something that = addressed Emil's problem. However, it seem that I have no clue what tha= t problem is so I may stop trying until the actual problem is clearer.
I really have no problem. There is only one reasonable way to do RTX
with double, which consists in doing RTX and in between the two layers
of protection and I am perfectly fine with that.

You seem to have an issue with this, that I believe goes beyond
implementation specifics, and I think you can certainly solve it
somehow if you tried.

Seems that there has been a misunderstanding then.

Are we in agreement then that RTX/FEC (or any other reconstruction streams)= will be done *ONLY HBH*?

Best regards
Sergio


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

--001a11409526d52552054d216138-- From nobody Fri Apr 14 11:36:07 2017 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 67CAB12953F for ; Fri, 14 Apr 2017 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 YQ6ofLZ40Pk3 for ; Fri, 14 Apr 2017 11:36:02 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B2912953E for ; Fri, 14 Apr 2017 11:36:02 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id u2so69229557wmu.0 for ; Fri, 14 Apr 2017 11:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=y+MqfJn+bG8rj15JmUyi23ul17TkO5+hNNIqdfQOl0k=; b=PFlvwfW3nbsRdYaHRO9pDyRiIpONOiLzzX7jGeAu+bxHL59Mu0NcQwhffBEbQPdjX+ Yd7xWVIii5NCVw1Dkcz30iYX4+eDqw4mvpFfGRuRrIHvhZzlsedeKuLjnOpaV0weOdNi ItG4dcefWcQM50rB73bVUTz1F2D0W3qddCf4CiTWMTdylOYaBwRyDJtGzwvx0JPChVjV HsRsT/nHcMQzYES/Ai1SB7Gyj0d6jS/8ZjOfVwvi73jBsGEdu1lvQJok2zrMFJ9AIgGO mNP9z10MlqXOxmP4fqwFZc+DZxZ0d9KF4K7WHwy6yOK2RMEVH9UiniNAfOmoZcACQY7H 24fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=y+MqfJn+bG8rj15JmUyi23ul17TkO5+hNNIqdfQOl0k=; b=qoNnUU/+jh3ozFOxpTPAnD0FEQ7vC8G5f7CkGOo8/y+b/qgPwvdmRl6Db0VvRn3gFw O4qhiaseN+pkIqGHZxC+vB+zclMziv1etjmBQ0FbjCShA6cftjj8eP/CLF4LZszxMEY9 +TudnSddLxjJldJ7DjS21Wjym/syFRzSVxkUzSosD7WYndgKUW44uWPcI4NsLfTLE8El OtTxGQ6S6zVGuE+zI6BYLJ2R5tw9lVPDPFV6TEEc7CqAkN7zP8bvp3cUbZFEjKijEBM1 qj2kAnEClaR60GuzYszSnKzoWYE7Xaz5s/WxAyVxf0gkb8NaSQXL0VsmBsJtngPlKiW/ cVYA== X-Gm-Message-State: AN3rC/4NYn78JqSincMU6qYa8tddKL/30NrYA6t5wptfXCr6jGZGsM6J SmAgDN5V9R8nxXIeygk= X-Received: by 10.28.31.200 with SMTP id f191mr186706wmf.63.1492194960634; Fri, 14 Apr 2017 11:36:00 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id u145sm15385247wmu.1.2017.04.14.11.35.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 11:35:59 -0700 (PDT) To: Richard Barnes References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <5745f282-f886-f251-bbfe-5190e9333098@gmail.com> Date: Fri, 14 Apr 2017 20:36:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E1D7ED7CB56AE63393E9A32D" Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:36:05 -0000 This is a multi-part message in MIME format. --------------E1D7ED7CB56AE63393E9A32D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 14/04/2017 15:50, Richard Barnes wrote: > > > On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo > > wrote: > > On 14/04/2017 9:06, Emil Ivov wrote: >> On Thu, 13 Apr 2017 at 21:12, Richard Barnes >> wrote: >> >> On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach > > wrote: >> >> On 4/12/17 19:10, Richard Barnes wrote: >> >> It's really not clear to me how these slides map to >> the mechanisms we have on the table. Could someone >> explain how you accomplish what's in these slides >> with DTLS-SRTP and EKT? >> >> >> Cullen's slides expand on the key exchange that I used >> > > >> to illustrate. As far as I know, the DTLS-SRTP and EKT >> handling has not changed since I created that older deck. >> I believe that the final three slides of that deck should >> answer your question. >> >> >> Here's where you're losing me, though: These entities called >> "HBH key" and "E2E key" don't actually exist; they're >> internal to the double transform. From every other >> perspective -- DTLS-SRTP, EKT, etc -- there is one key that's >> twice the length of an AES key. So you never send around an >> "E2E key" or an "HBH" key, you send around one big key that >> has E2E and HBH halves. >> >> >> I think that this view of the situation is probably the reason >> for a big part of the disagreements in the working group. >> >> I do see the appeal here but looking at this as a single key adds >> way too many unnecessary constraints. >> >> This is certainly not how our implementation works. > > I agree, and IMHO saying that there is "only one key that is the > result of concatenation of two keys" is an artificial construct. > > > Well, at a certain level, everything we do here is an artificial > construct :) There's nothing natural about the Internet. > > I'm not saying that there's one key because I like the aesthetics. > I'm saying that because that's the semantic that's available from the > protocols we're depending on here, namely DTLS-SRTP and EKT. If we > want the specifications to work in terms of pairs of keys with > independent halves, we'll need to patch those specifications, or > require that they be used in special ways. For example, if you wanted > to have the HBH key be the same for all endpoints, we would have to > define how it gets synchronized; there's nothing else that's going to > do that for you. > > Personally, I think it's cleaner to deal in terms of one key (except > where we give half a key to the MD). It makes the media layer look > basically the same as non-PERC for everyone but the MD, and the only > cost to the MD is that it has to keep a table of HBH instead of a > single one -- but of course pre-PERC, it had whole independent DTLS > state per client, so that doesn't seem like a big deal. > Well, I have a completely different view, and I think this is the root of all misunderstandings with double encryption. The reality is that we have two crypto keys one for the HBH and one shared for the E2E. The E2E encryption would work even if we didn't used DTLS/SRTP for HBH and we just sent it in plain RTP. So while some people see it as "DTLS/SRTP with double encryption" others (at least me) start to see it as "E2E media encryption using SRTP shared key sent over DTLS/SRTP". Best regards Sergio --------------E1D7ED7CB56AE63393E9A32D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 14/04/2017 15:50, Richard Barnes wrote:


On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 14/04/2017 9:06, Emil Ivov wrote:
On Thu, 13 Apr 2017 at 21:12, Richard Barnes <rlb@ipv.sx> wrote:
On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/17 19:10, Richard Barnes wrote:
It's really not clear to me how these slides map to the mechanisms we have on the table.  Could someone explain how you accomplish what's in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to illustrate. As far as I know, the DTLS-SRTP and EKT handling has not changed since I created that older deck. I believe that the final three slides of that deck should answer your question.

Here's where you're losing me, though: These entities called "HBH key" and "E2E key" don't actually exist; they're internal to the double transform.  From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's twice the length of an AES key.  So you never send around an "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH halves.

I think that this view of the situation is probably the reason for a big part of the disagreements in the working group.

I do see the appeal here but looking at this as a single key adds way too many unnecessary constraints.

This is certainly not how our implementation works.

I agree, and IMHO saying that there is "only one key that is the result of concatenation of two keys" is an artificial construct.

Well, at a certain level, everything we do here is an artificial construct :)  There's nothing natural about the Internet.

I'm not saying that there's one key because I like the aesthetics.  I'm saying that because that's the semantic that's available from the protocols we're depending on here, namely DTLS-SRTP and EKT.  If we want the specifications to work in terms of pairs of keys with independent halves, we'll need to patch those specifications, or require that they be used in special ways.  For example, if you wanted to have the HBH key be the same for all endpoints, we would have to define how it gets synchronized; there's nothing else that's going to do that for you.

Personally, I think it's cleaner to deal in terms of one key (except where we give half a key to the MD).  It makes the media layer look basically the same as non-PERC for everyone but the MD, and the only cost to the MD is that it has to keep a table of HBH instead of a single one -- but of course pre-PERC, it had whole independent DTLS state per client, so that doesn't seem like a big deal.


Well, I have a completely different view, and I think this is the root of all misunderstandings with double encryption.

The reality is that we have two crypto keys one for the HBH and one shared for the E2E. The E2E encryption would work even if we didn't used DTLS/SRTP for HBH and we just sent it in plain RTP. So while some people see it as "DTLS/SRTP with double encryption" others (at least me) start to see it as "E2E media encryption using SRTP shared key sent over DTLS/SRTP".

Best regards
Sergio

--------------E1D7ED7CB56AE63393E9A32D-- From nobody Fri Apr 14 11:57:16 2017 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 9822F126DDF for ; Fri, 14 Apr 2017 11:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 zmKjuwxA4_tC for ; Fri, 14 Apr 2017 11:57:12 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 45CA71275C5 for ; Fri, 14 Apr 2017 11:57:12 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id b187so98934577oif.0 for ; Fri, 14 Apr 2017 11:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WNmModvO0IUsAwVYJwgZO7aGOOLftd3GG8iNPwx96So=; b=tp1Vcx1k9G3GJwirW5VZcO8yGLPONe0tvq0AKbRkFErjIx6LKIx/vQPfy7YRJE9UTK EX6F+EJPfxayzqzWOFURUk49HDtgPJheZwjIFGXKzwZlso5C/cEY/pww2xX/W9kj4Pks EnSXL16vXJVqS83WN9qnPy6mxO2IMZoYA04x9bOUcktRiBpd0gokMx3q+TP3PYgIRlY8 lLn4K13pC0MK/ys9bAurkxavKm2c5HqsXiW+ERo6up/Ofr2oq68oz7VFtxPodMWH7B55 VUWHERTK6z43p75oF6FuS3iAGzJE4mJ89Qw6e2o7ysFiaZ/F6F+5PzGny5yby7BW4MGT NayA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WNmModvO0IUsAwVYJwgZO7aGOOLftd3GG8iNPwx96So=; b=N+wPurMYk4q19yrWenGle1YoSr/LSvW2tc01kLu61kh0yk3JKcgc2OI2DKUy8961Em Ey6BKiRsmjnwdP/o3UCoGDDpqE/HkJYaaj+64Q3WkF+eYKV6z9yilhVss5+PBiPZDX85 evsjbjYEU17nteMDxUdNsdBB6vihrwkm6Z6pfQCsG+ZtGaQdT7I7xpkT13KQwXnuTHDz Xp9Nx2v164IR37/yLlW14HKPIM9rofFM64kDVik8RE8W2J4K4GMEXM4+jte6An/HIMTI 1gabheMq60W80Cb6CMJN7g4GILV0X8rcSTx/rykVy4YnGNmedi9AGiDMsm7H23VFRXOP A/UA== X-Gm-Message-State: AN3rC/7fRx3+5JzxGYseECYvZAp/lw1uafyyLZJszL+wOwc3dNo7Ieuj yiU1pWJnpe85zAQghW1I6WsptOyAdQ== X-Received: by 10.157.15.177 with SMTP id d46mr6040653otd.136.1492196231503; Fri, 14 Apr 2017 11:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.117.21 with HTTP; Fri, 14 Apr 2017 11:57:11 -0700 (PDT) In-Reply-To: References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> <63e34c13-d5b0-162e-991a-9dea147f835a@gmail.com> From: Stephen Botzko Date: Fri, 14 Apr 2017 14:57:11 -0400 Message-ID: To: Richard Barnes Cc: Sergio Garcia Murillo , perc@ietf.org Content-Type: multipart/alternative; boundary=001a113de8f050645e054d25028e Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:57:14 -0000 --001a113de8f050645e054d25028e Content-Type: text/plain; charset=UTF-8 On Fri, Apr 14, 2017 at 9:50 AM, Richard Barnes wrote: > > > On Fri, Apr 14, 2017 at 3:14 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> On 14/04/2017 9:06, Emil Ivov wrote: >> >> On Thu, 13 Apr 2017 at 21:12, Richard Barnes >> wrote: >> >>> On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach wrote: >>> >>>> On 4/12/17 19:10, Richard Barnes wrote: >>>> >>>>> It's really not clear to me how these slides map to the mechanisms we >>>>> have on the table. Could someone explain how you accomplish what's in >>>>> these slides with DTLS-SRTP and EKT? >>>>> >>>> >>>> Cullen's slides expand on the key exchange that I used < >>>> https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to >>>> illustrate. As far as I know, the DTLS-SRTP and EKT handling has not >>>> changed since I created that older deck. I believe that the final three >>>> slides of that deck should answer your question. >>> >>> >>> Here's where you're losing me, though: These entities called "HBH key" >>> and "E2E key" don't actually exist; they're internal to the double >>> transform. From every other perspective -- DTLS-SRTP, EKT, etc -- there is >>> one key that's twice the length of an AES key. So you never send around an >>> "E2E key" or an "HBH" key, you send around one big key that has E2E and HBH >>> halves. >>> >> >> I think that this view of the situation is probably the reason for a big >> part of the disagreements in the working group. >> >> I do see the appeal here but looking at this as a single key adds way too >> many unnecessary constraints. >> >> This is certainly not how our implementation works. >> >> >> I agree, and IMHO saying that there is "only one key that is the result >> of concatenation of two keys" is an artificial construct. >> > > Well, at a certain level, everything we do here is an artificial construct > :) There's nothing natural about the Internet. > > I'm not saying that there's one key because I like the aesthetics. I'm > saying that because that's the semantic that's available from the protocols > we're depending on here, namely DTLS-SRTP and EKT. If we want the > specifications to work in terms of pairs of keys with independent halves, > we'll need to patch those specifications, or require that they be used in > special ways. For example, if you wanted to have the HBH key be the same > for all endpoints, we would have to define how it gets synchronized; > there's nothing else that's going to do that for you. > > Personally, I think it's cleaner to deal in terms of one key (except where > we give half a key to the MD). It makes the media layer look basically the > same as non-PERC for everyone but the MD, and the only cost to the MD is > that it has to keep a table of HBH instead of a single one -- but of course > pre-PERC, it had whole independent DTLS state per client, so that doesn't > seem like a big deal. > [sb] Until you try to make RTX and FEC repair flows work properly - and they have work properly for PERC to be viable. "Work properly" includes the ability of the endpoints to authenticate the repair flows, so it is not just about the MD implementation. [/sb] > > --Richard > > > > --001a113de8f050645e054d25028e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 14, 2017 at 9:50 AM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wr= ote:


On Fri, Apr 14,= 2017 at 3:14 AM, Sergio Garcia Murillo <sergio.garcia.muril= lo@gmail.com> wrote:
=20 =20 =20
On 14/04/2017 9:06, Emil Ivov wrote:
On Thu, 13 Apr 2017 at 21:12, Richard Barnes <rlb@ipv.sx> wrote:
On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/17 19:10, Richard Barnes wrote:
It's really not clear to me how these slides ma= p to the mechanisms we have on the table.=C2=A0 Could someone explain how you accomplish what's in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://= www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to illustrate. As far as I know, the DTLS-SRTP and EKT handling has not changed since I created that older deck. I believe that the final three slides of that deck should answer your question.

Here's where you're losing me, though: These entities called "HBH key" and "E2E key&q= uot; don't actually exist; they're internal to the double transform.=C2=A0 From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that's twic= e the length of an AES key.=C2=A0 So you never send aroun= d an "E2E key" or an "HBH" key, you s= end around one big key that has E2E and HBH halves.

I think that this view of the situation is probably the reason for a big part of the disagreements in the working group.

I do see the appeal here but looking at this as a single key adds way too many unnecessary constraints.

This is certainly not how our implementation works.

I agree, and IMHO saying that there is "only one key that is the result of concatenation of two keys" is an artificial construct. <= /div>

Well, at a certain level, ever= ything we do here is an artificial construct :)=C2=A0 There's nothing n= atural about the Internet.

I'm not saying that= there's one key because I like the aesthetics.=C2=A0 I'm saying th= at because that's the semantic that's available from the protocols = we're depending on here, namely DTLS-SRTP and EKT.=C2=A0 If we want the= specifications to work in terms of pairs of keys with independent halves, = we'll need to patch those specifications, or require that they be used = in special ways.=C2=A0 For example, if you wanted to have the HBH key be th= e same for all endpoints, we would have to define how it gets synchronized;= there's nothing else that's going to do that for you.

Personally, I think it's cleaner to deal in terms of o= ne key (except where we give half a key to the MD).=C2=A0 It makes the medi= a layer look basically the same as non-PERC for everyone but the MD, and th= e only cost to the MD is that it has to keep a table of HBH instead of a si= ngle one -- but of course pre-PERC, it had whole independent DTLS state per= client, so that doesn't seem like a big deal.
<= /blockquote>

[sb] Until you try to make RTX and FEC repa= ir flows work properly - and they have work properly for PERC to be viable.= =C2=A0"Work properly" includes the ability of the endpoints to a= uthenticate the repair flows, so it is not just about the MD implementation= . [/sb]=C2=A0

--Richard

=C2=A0


--001a113de8f050645e054d25028e-- From nobody Mon Apr 17 14:38:00 2017 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 BCB8913154C for ; Mon, 17 Apr 2017 14:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 tZazhqS-zH5P for ; Mon, 17 Apr 2017 14:37:57 -0700 (PDT) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D16C128BA2 for ; Mon, 17 Apr 2017 14:37:57 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C60E058E0; Mon, 17 Apr 2017 17:37:53 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4F7E857DF; Mon, 17 Apr 2017 17:37:53 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.109.110] (184-23-135-130.dedicated.static.sonic.net [184.23.135.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 17 Apr 2017 17:37:53 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_17BC937E-DE95-4C33-8AB7-9799DFECD7EE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 17 Apr 2017 14:37:52 -0700 Cc: Adam Roach , perc@ietf.org Message-Id: References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> To: Richard Barnes X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:37:59 -0000 --Apple-Mail=_17BC937E-DE95-4C33-8AB7-9799DFECD7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 13, 2017, at 7:12 PM, Richard Barnes wrote: >=20 >=20 > On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach > wrote: > On 4/12/17 19:10, Richard Barnes wrote: > It's really not clear to me how these slides map to the mechanisms we = have on the table. Could someone explain how you accomplish what's in = these slides with DTLS-SRTP and EKT? >=20 > Cullen's slides expand on the key exchange that I used = > to = illustrate. As far as I know, the DTLS-SRTP and EKT handling has not = changed since I created that older deck. I believe that the final three = slides of that deck should answer your question. >=20 > Here's where you're losing me, though: These entities called "HBH key" = and "E2E key" don't actually exist; they're internal to the double = transform. =46rom every other perspective -- DTLS-SRTP, EKT, etc -- = there is one key that's twice the length of an AES key. So you never = send around an "E2E key" or an "HBH" key, you send around one big key = that has E2E and HBH halves. >=20 > When participant A sends an EKT message to participant B when B joins, = it sets both the HBH and E2E keys that B will use to decrypt packets = from A's SSRC. This implies that there's no need for the MD to do = re-encryption HBH unless it wants to change something. >=20 > Here's the story as I understand it at this point: >=20 > - Each endpoint establishes an HBH+E2E key from the DTLS handshake = that it uses for transmission > - The KD tells the MD the HBH half of each of these keys > - The KD tells each endpoint an EKTKey in an ekt_key message = (encrypted under some key derived from the DTLS handshake) > - On join, each endpoint sends an EKTCiphertext message with its = HBH+E2E transmission key, encrypted with the EKTKey >=20 > In colorful slides (with apologies to the red/green colorblind in the = audience): >=20 > = https://docs.google.com/presentation/d/1LpKZSN_7mKzN0C0gllsT8Znb3YnaikLa0h= 1znahWajg/edit?usp=3Dsharing = >=20 > Does this seem correct to folks? >=20 > --Richard >=20 > =20 That's roughly what I have had in my mind for a long time but is = slightly different than what is in framework. The slight differences = being if all the participants have own HBH key is effectively shared = across all to all participants. I think the protocols support both = (basically difference is if EKT shares half or full key double key ). I = don't care too much but we would need to update framework slightly to = reflect this.=20 --Apple-Mail=_17BC937E-DE95-4C33-8AB7-9799DFECD7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 13, 2017, at 7:12 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach <adam@nostrum.com> wrote:
On 4/12/17 19:10, Richard Barnes wrote:
It's really not clear to me how these slides map to the mechanisms we = have on the table.  Could someone explain how you accomplish what's = in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to = illustrate. As far as I know, the DTLS-SRTP and EKT handling has not = changed since I created that older deck. I believe that the final three = slides of that deck should answer your question.

Here's where you're = losing me, though: These entities called "HBH key" and "E2E key" don't = actually exist; they're internal to the double transform.  =46rom = every other perspective -- DTLS-SRTP, EKT, etc -- there is one key = that's twice the length of an AES key.  So you never send around an = "E2E key" or an "HBH" key, you send around one big key that has E2E and = HBH halves.

When= participant A sends an EKT message to participant B when B joins, it = sets both the HBH and E2E keys that B will use to decrypt packets from = A's SSRC.  This implies that there's no need for the MD to do = re-encryption HBH unless it wants to change something.

Here's the story as I = understand it at this point:

- Each endpoint establishes an HBH+E2E = key from the DTLS handshake that it uses for transmission
- The KD tells the MD the HBH half of each of these = keys
- The KD tells each endpoint an EKTKey in an = ekt_key message (encrypted under some key derived from the DTLS = handshake)
- On join, each endpoint sends an = EKTCiphertext message with its HBH+E2E transmission key, encrypted with = the EKTKey

In = colorful slides (with apologies to the red/green colorblind in the = audience):


Does this seem correct = to folks?

--Richard

 

That's roughly what I have had in my mind for a = long time but is slightly different than what is in framework. The = slight differences being if all the participants have own HBH key is = effectively shared across all to all participants. I think the protocols = support both (basically difference is if EKT shares half or full key = double key ). I don't care too much but we would need to update = framework slightly to reflect this. 


= --Apple-Mail=_17BC937E-DE95-4C33-8AB7-9799DFECD7EE-- From nobody Mon Apr 17 15:05:09 2017 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 4FED513158A for ; Mon, 17 Apr 2017 15:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al3UafaJXwov for ; Mon, 17 Apr 2017 15:05:06 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 2F6271242F7 for ; Mon, 17 Apr 2017 15:05:06 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r190so568245wme.1 for ; Mon, 17 Apr 2017 15:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mKJyQi76rsgFe/Yl82VUs7nq3XgSBiB8w3+DtzYYg8U=; b=TEx6nfS0AJ3oBptzUusTEtG+W/tQqBqHWw9BckPE5cX/WXsdraqjpPeDR6cLkxXnDL 5/jf7AKuas3O1qWRzm255Bpkl4pXnEL8aP4tNnhOshS5FNuBfRgpG3h8khqwdWFw81+3 9aNWy7bUHkBsWufCHFXSBpBRZZAHTp4lDwo1WUo6FcWNln8TMV64cr4PgmQ9majsQwe5 RXLYt6CecxGhXZI4dUlRCTmJgHtdk6kzl+A14e/GQm0rdBJwR6SXvbX7fwgVcVAd600/ Y0tRYZwI0R7rnqdpsTAu+cq6HlTQqsuwGlqmxCL1NogdLuZOa/IVztl2XltV/o138onQ HNlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mKJyQi76rsgFe/Yl82VUs7nq3XgSBiB8w3+DtzYYg8U=; b=B7MMAwH29YDEFjqAWodDkNy7o7nj+HFTPRau/GBNJDlk6LX91J3lNCjZri60FIZka7 Sd+Xiyyg4f24LdOV3SrdahlMMxRebU1eQeXFYzdIwyNbl7nAALX75TcVLt4QUBBTo4Nv DRhusPPArmYY13p5WwjcE+IiMg3s3hw338phLTH6jl/XX7p1QxKdAJjqbM/siVcxAbJX /r0t7MeajotuVtDMsJ7ol0d9mh6YcK7jkS5lYX5osXCkFPOdH+Ux6RmibR+Cnvr4vpHN 7cnMYBswN7lKpmfhRE6/euJSmxbvKpMeqBg8JNNdpneAO7GeSBKRdetdiTdWthYdeQ7i g1rQ== X-Gm-Message-State: AN3rC/4/+10D7f8HFNJJE74q3QIRcuX1J0/9lk6Do56ETOQzt8cXa/nX IjbkhJj1xzA6g7V3rim89p4JWgfTBDid X-Received: by 10.28.100.137 with SMTP id y131mr10699294wmb.76.1492466704238; Mon, 17 Apr 2017 15:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Mon, 17 Apr 2017 15:05:03 -0700 (PDT) In-Reply-To: References: <4F4AFE1A-16B1-4BA1-8B25-74813CC25179@iii.ca> <84d1e04b-eecc-4453-4934-689587900352@nostrum.com> From: Richard Barnes Date: Mon, 17 Apr 2017 18:05:03 -0400 Message-ID: To: Cullen Jennings Cc: Adam Roach , perc@ietf.org Content-Type: multipart/alternative; boundary=001a114b8258beecdd054d63fbbb Archived-At: Subject: Re: [Perc] Quick tutorial on PERC keys X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:05:08 -0000 --001a114b8258beecdd054d63fbbb Content-Type: text/plain; charset=UTF-8 On Mon, Apr 17, 2017 at 5:37 PM, Cullen Jennings wrote: > > On Apr 13, 2017, at 7:12 PM, Richard Barnes wrote: > > > On Thu, Apr 13, 2017 at 7:08 PM, Adam Roach wrote: > >> On 4/12/17 19:10, Richard Barnes wrote: >> >>> It's really not clear to me how these slides map to the mechanisms we >>> have on the table. Could someone explain how you accomplish what's in >>> these slides with DTLS-SRTP and EKT? >>> >> >> Cullen's slides expand on the key exchange that I used < >> https://www.ietf.org/proceedings/95/slides/slides-95-perc-4.pdf> to >> illustrate. As far as I know, the DTLS-SRTP and EKT handling has not >> changed since I created that older deck. I believe that the final three >> slides of that deck should answer your question. > > > Here's where you're losing me, though: These entities called "HBH key" and > "E2E key" don't actually exist; they're internal to the double transform. > From every other perspective -- DTLS-SRTP, EKT, etc -- there is one key > that's twice the length of an AES key. So you never send around an "E2E > key" or an "HBH" key, you send around one big key that has E2E and HBH > halves. > > When participant A sends an EKT message to participant B when B joins, it > sets both the HBH and E2E keys that B will use to decrypt packets from A's > SSRC. This implies that there's no need for the MD to do re-encryption HBH > unless it wants to change something. > > Here's the story as I understand it at this point: > > - Each endpoint establishes an HBH+E2E key from the DTLS handshake that it > uses for transmission > - The KD tells the MD the HBH half of each of these keys > - The KD tells each endpoint an EKTKey in an ekt_key message (encrypted > under some key derived from the DTLS handshake) > - On join, each endpoint sends an EKTCiphertext message with its HBH+E2E > transmission key, encrypted with the EKTKey > > In colorful slides (with apologies to the red/green colorblind in the > audience): > > https://docs.google.com/presentation/d/1LpKZSN_ > 7mKzN0C0gllsT8Znb3YnaikLa0h1znahWajg/edit?usp=sharing > > Does this seem correct to folks? > > --Richard > > > > > That's roughly what I have had in my mind for a long time but is slightly > different than what is in framework. The slight differences being if all > the participants have own HBH key is effectively shared across all to all > participants. I think the protocols support both (basically difference is > if EKT shares half or full key double key ). I don't care too much but we > would need to update framework slightly to reflect this. > So it sounds like we need a document update here either way: 1. With the approach in Cullen's slides, we would need to update EKT to handle half-keys 2. With the approach in my slides, we would need to update -framework ISTM that (2) is the right approach. Updating EKT to handle half-keys would either require a general mechanism to partly update keys, a giant foot-gun, or a double-specific provision in EKT, which reduces the utility of EKT quite a bit. For the folks in the crowd concerned about RTX / FEC -- this shouldn't make a profound difference one way or the other. There's no difference between the two cases in terms of what's encrypted or what the MD can do. --Richard --001a114b8258beecdd054d63fbbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 17, 2017 at 5:37 PM, Cullen Jennings <= fluffy@iii.ca> wrote:

On Apr 13, = 2017, at 7:12 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Apr 13, 2017 at 7:08 PM, Adam Roa= ch <adam@nostrum.com> wrote:
On 4/12/17= 19:10, Richard Barnes wrote:
It's really not clear to me how these slides map to the mechanisms we h= ave on the table.=C2=A0 Could someone explain how you accomplish what's= in these slides with DTLS-SRTP and EKT?

Cullen's slides expand on the key exchange that I used <https://www.ietf.org/proceedings/95/slides/s= lides-95-perc-4.pdf> to illustrate. As far as I know, the DTLS-= SRTP and EKT handling has not changed since I created that older deck. I be= lieve that the final three slides of that deck should answer your question.=

Here's where you're losing me, tho= ugh: These entities called "HBH key" and "E2E key" don&= #39;t actually exist; they're internal to the double transform.=C2=A0 F= rom every other perspective -- DTLS-SRTP, EKT, etc -- there is one key that= 's twice the length of an AES key.=C2=A0 So you never send around an &q= uot;E2E key" or an "HBH" key, you send around one big key th= at has E2E and HBH halves.

When participant A send= s an EKT message to participant B when B joins, it sets both the HBH and E2= E keys that B will use to decrypt packets from A's SSRC.=C2=A0 This imp= lies that there's no need for the MD to do re-encryption HBH unless it = wants to change something.

Here's the story as= I understand it at this point:

- Each endpoint es= tablishes an HBH+E2E key from the DTLS handshake that it uses for transmiss= ion
- The KD tells the MD the HBH half of each of these keys
- The KD tells each endpoint an EKTKey in an ekt_key message (encrypt= ed under some key derived from the DTLS handshake)
- On join, eac= h endpoint sends an EKTCiphertext message with its HBH+E2E transmission key= , encrypted with the EKTKey

In colorful slides (wi= th apologies to the red/green colorblind in the audience):

That's roughly what I have had in my mind for a long time but is= slightly different than what is in framework. The slight differences being= if all the participants have own HBH key is effectively shared across all = to all participants. I think the protocols support both (basically differen= ce is if EKT shares half or full key double key ). I don't care too muc= h but we would need to update framework slightly to reflect this.=C2=A0

So it sounds like we need a docume= nt update here either way:

1. With the approach in= Cullen's slides, we would need to update EKT to handle half-keys
2. With the approach in my slides, we would need to update -framew= ork
=C2=A0
ISTM that (2) is the right approach.=C2= =A0 Updating EKT to handle half-keys would either require a general mechani= sm to partly update keys, a giant foot-gun, or a double-specific provision = in EKT, which reduces the utility of EKT quite a bit.

<= div>For the folks in the crowd concerned about RTX / FEC -- this shouldn= 9;t make a profound difference one way or the other.=C2=A0 There's no d= ifference between the two cases in terms of what's encrypted or what th= e MD can do.

--Richard


--001a114b8258beecdd054d63fbbb-- From nobody Tue Apr 18 11:02:12 2017 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 664041293FD for ; Tue, 18 Apr 2017 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AgIcqgx4LYK for ; Tue, 18 Apr 2017 11:02:09 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 CE6C61293E4 for ; Tue, 18 Apr 2017 11:02:08 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c45so532430qtb.1 for ; Tue, 18 Apr 2017 11:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=hJTiCLgXqjM5awErtn4r3KN3mhEe/Fev+eH4TXJOBOk=; b=TBqRwgO3HhNhbf9csZVPMA29zUS/LDmD3F2UgQZbl3o3QYD6EChWJ/1pUFwllmZMrC tnPtPhNAZEF/7z9rsfd0xACSjyPkmY7+LZUvkuwPcGN5SWUGaqXg4HHWRxeXS3UQFlme 9kIYSoi/H2h/DUhYUV+l4q6LYmE+oXikotnqfdu+NOFQb8q+bJCFgyxFE0yyw1M9wsoY IacCDEaT/Dmdus+v0NYDE5LKsI5a0Aq2aU9y5U36qaRe51QKFhfxl4QYJ7hdNj8N0DzH UqWa+gOcH1bZll8h5b+YHgCXcVHp3/fbwmrXt7ydwDSZ+h0TZkzvDuVfKExJqkglNnbJ RamA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=hJTiCLgXqjM5awErtn4r3KN3mhEe/Fev+eH4TXJOBOk=; b=p33R+nLaJL11xe9244x5+Uo2fT0coKaCBYVHfto8nPK7goSWPatjDmq7/K23BxNIr0 asl2ayWw6LmGCB8ymRAiFHasYtQ4Z28/t9gpOCEHkd3a+7TJfFHRV19VqMrfN6BPNb0z SspFmLGMWSclnMTuyn/IOAyQ7hdLstiPiupZyiMmKAiwIYJ0hYVp85lVEmJ58OGYGZ/Y FS/IFgULKa7FQHUn06vLSGgf31VlSL8yRuaJ8j20x5644hnESnQtDtiFYl3TLrR5uAsh gbwVgGpgWHwMov6JGzrNff+spVtppC7Tgh0bZJbILqYF/U0oOZ4QbUZ5UlulihSpTaE/ NI4Q== X-Gm-Message-State: AN3rC/6ZSfXYTeuhqms+M2onNkbJ/T8RB7WXgxa75Hy/6ENaHqsUSjS7 yUi+faUkocbboVBveQQdnl7ww9Gy/w== X-Received: by 10.237.56.67 with SMTP id j61mr13551569qte.86.1492538528014; Tue, 18 Apr 2017 11:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.162 with HTTP; Tue, 18 Apr 2017 11:02:07 -0700 (PDT) From: Suhas Nandakumar Date: Tue, 18 Apr 2017 11:02:07 -0700 Message-ID: To: perc@ietf.org Cc: Richard Barnes , Nils Ohlmeier Content-Type: multipart/alternative; boundary=001a113e239ac6a943054d74b422 Archived-At: Subject: [Perc] Doodle Poll for Perc Virtual Interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:02:10 -0000 --001a113e239ac6a943054d74b422 Content-Type: text/plain; charset=UTF-8 Hello All To carry forward the discussions on RTX/FEC support in the PERC Context from IETF 98, we have setup the following doodle poll. http://doodle.com/poll/wag852eknq3yidpy The meeting will be for 120 mins (2 hours) and will be an online meeting. Please complete the poll by 4/24/2017 EOD (PST time) to enable us to setup the official proceedings. Cheers Perc Chairs --001a113e239ac6a943054d74b422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All


=C2=A0 =C2=A0 = To carry forward the discussions on RTX/FEC support in the PERC Context fro= m IETF 98, we have setup the following doodle poll.



The meet= ing will be for 120 mins (2 hours) and will be an online meeting.

Please complete the poll by 4/24/2017 EOD (PST time) to ena= ble us to setup the official proceedings.

Cheers
Perc Chairs

--001a113e239ac6a943054d74b422-- From nobody Tue Apr 18 11:53:41 2017 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 56DA3131462 for ; Tue, 18 Apr 2017 11:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaUkowaF43fk for ; Tue, 18 Apr 2017 11:53:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FFE12702E for ; Tue, 18 Apr 2017 11:53:37 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3IIrZ0U089876 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Apr 2017 13:53:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 18 Apr 2017 13:53:35 -0500 Cc: Richard Barnes , Nils Ohlmeier To: perc@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Perc] Change of the Guard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:53:38 -0000 Hello PERC, Richard is stepping down as PERC co-chair, due to his new day job = responsibilities. Please join me in thanking him for his hard work to = date. Nils Ohlmeier is stepping up to fill the vacancy. Please welcome him to = his new role, and take it easy on him for the first few days ;-) Thanks! Ben.= From nobody Tue Apr 18 12:00:36 2017 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 25BB81314D4 for ; Tue, 18 Apr 2017 12:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXKrmYqgixjD for ; Tue, 18 Apr 2017 12:00:33 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 BD3201314CE for ; Tue, 18 Apr 2017 12:00:29 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id o81so63641370wmb.1 for ; Tue, 18 Apr 2017 12:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UUWZz54rnmhdEMZYDyytEhF7KN1PGTVTgVhkczNvn20=; b=W1+tRZ4eyDv15eMUG1axZoEeSwxiUxAJOX4BgGeDTIAvfP1USog4x66/ND0uMRNiOP yJHE+gUz4THmwMiSc+9VQalhONF0smyCSXZoajodGAP1n3CnOdDNQdx4DDESxcNClf/q 2GNdDzQqdlTGVhQcYdhGDrIL7x65SCW5Jw0LnoMBQdHSbFlLZcCnD/R2k9VkPIpHstmj FdgWFVZCGjmJbb2IUl+Fcs9qZSj/H/2UY9LREmF+PO0SHBH27FdbyvT5ej441mp/W7HX ZIFrKznFfTRTe3N8eJcWSRVVvMpo/0N7riYQSrLSLd0WRZiPZHS3qfd213WDhQiNVUKf xnYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UUWZz54rnmhdEMZYDyytEhF7KN1PGTVTgVhkczNvn20=; b=lABfhzZ59cvKsT4v1qOHEVlxgi8hEW72lJqgsCJnflrG06wkmOgjkDQBVe7jpFOh2n Mbbyl5bd8yWOx1iJoom0+93lOyLIeUWgkYdYGJhvcbQ/Y2vZrAjSpEtFjA/h0brzUxeL Elv9u9/j7cYVqpESnUjoIm9EZOZjwDAdl3ig3gbMtyutDZ5fnWFOpXzT/7sLvAEheVsP nUVhs2DNusSmzyychjZxCavSTXq4iYBWhx4ip9EStF+AV4DD6/swOLVotAdQH4XDJLYu s5TPpcZGXwoBiW5A8XpL6Pj7+oUpQH40ox6ffsRvOrHsoq7d+QST5E6SABK/Vi5Qn4CI 752A== X-Gm-Message-State: AN3rC/53hxQZeYFpW4lBTuwWpvq0TD21g5BuHdjFc51GK80McdZGHLU3 AzxmCn/V0L1rEfdqzu3lNGXXY6Pw3g== X-Received: by 10.28.173.66 with SMTP id w63mr12999800wme.76.1492542027744; Tue, 18 Apr 2017 12:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Tue, 18 Apr 2017 12:00:26 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 18 Apr 2017 15:00:26 -0400 Message-ID: To: Ben Campbell Cc: perc@ietf.org, Nils Ohlmeier Content-Type: multipart/alternative; boundary=001a114426446080e8054d758505 Archived-At: Subject: Re: [Perc] Change of the Guard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:00:35 -0000 --001a114426446080e8054d758505 Content-Type: text/plain; charset=UTF-8 Thanks, Nils! On Tue, Apr 18, 2017 at 2:53 PM, Ben Campbell wrote: > Hello PERC, > > Richard is stepping down as PERC co-chair, due to his new day job > responsibilities. Please join me in thanking him for his hard work to date. > > Nils Ohlmeier is stepping up to fill the vacancy. Please welcome him to > his new role, and take it easy on him for the first few days ;-) > > Thanks! > > Ben. --001a114426446080e8054d758505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Nils!

On Tue, Apr 18, 2017 at 2:53 PM, Ben Campbell <ben@no= strum.com> wrote:
Hello PE= RC,

Richard is stepping down as PERC co-chair, due to his new day job responsib= ilities. Please join me in thanking him for his hard work to date.

Nils Ohlmeier is stepping up to fill the vacancy. Please welcome him to his= new role, and take it easy on him for the first few days ;-)

Thanks!

Ben.

--001a114426446080e8054d758505-- From nobody Tue Apr 18 12:01:02 2017 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 13854131480 for ; Tue, 18 Apr 2017 12:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_H3yWMEZgj5 for ; Tue, 18 Apr 2017 12:00:59 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C541314AA for ; Tue, 18 Apr 2017 12:00:49 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id y33so1893597qta.2 for ; Tue, 18 Apr 2017 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KkdqlkxqpQm9WbrkaMAm7jFvjsxjZPRaG9og5Dlu+1I=; b=GIy6zJQvcx2VRUIC+RvhZ1quTGjrYy3W6F6G/FnyD17dki0dxj3b0C7sjNoNgmfz3w lx7VaqeewGx7vQ0UFRI7QUH8lnDyJ45XF5WUrwzxuz99i47zFTRjO+yD4OrAqVY9Htl+ /8MNEFnfOMhkkcUFS1DX5b9MlWfLgLDwZ9ts3Vh/gZTAIgRKxE6wpnGXQzkQxjY+yOpU 02PLBWV/bW5K5f9KI/hICcPAL3DRa6P7umn8K1ypfKrmmxQ9RL6rEiFGB03kojGjWdZe hMbOL/CIakCBCQTk2WMxZVwIr3Xoq5huPMdJs2yUVdXMRGavxnqgVuP2DRjr9jtzqtXe Xxgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KkdqlkxqpQm9WbrkaMAm7jFvjsxjZPRaG9og5Dlu+1I=; b=HLgyn85vqpoTrLwvzSj+4JEkiA4+i7lHJtzd022NR28F7OEy46Gd497LoWvzSKvsl3 eIdMXc9DZP6JkEoBPsA9WdYtqUVcTh2+cdgsjLBi2j/70MZlWUxrASOLuwnQxzh4Ucjt 0B3qrJmRsSbu0kRunuwVQzEUmNrvuTdYASFS8gUxqiZ2wBINBywvnYZRlZsd9reYCmJ+ K6UWI4V1rWI0R9dFbE1JMQIKXpU5YvQBzegEEd5vDsFCl2i8PeikqcHZ9SFfhgf/3dA9 Jlr9GmX18x7qRlNgPQ2RkxF4hCdPTlJVqvi8hRFJ7fSAhu5/YmIQASYyoMG3+ddyqFxo 0ZBA== X-Gm-Message-State: AN3rC/6R/wm+sFPCPhnXVyS1hBg+uF9CXaBV17jLmWCFKfVN7rjsTZ0L hdbDUXsgiUEfwMd0g49COzstF7CVHg== X-Received: by 10.237.56.67 with SMTP id j61mr13816218qte.86.1492542048047; Tue, 18 Apr 2017 12:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.162 with HTTP; Tue, 18 Apr 2017 12:00:47 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Tue, 18 Apr 2017 12:00:47 -0700 Message-ID: To: Ben Campbell Cc: perc@ietf.org, Richard Barnes , Nils Ohlmeier Content-Type: multipart/alternative; boundary=001a113e239a962e70054d758617 Archived-At: Subject: Re: [Perc] Change of the Guard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:01:01 -0000 --001a113e239a962e70054d758617 Content-Type: text/plain; charset=UTF-8 Thanks Ben for the email. Thanks Richard to helping me learn the baby steps of chairing IETF and being a wonderful co-chair/mentor. I am sure there is lot more to learn and I will keep doing so. Welcome Nils on to the exciting journey in joining along a passionate group of contributors in the WG. Look forward for our collaboration. Cheers Suhas On Tue, Apr 18, 2017 at 11:53 AM, Ben Campbell wrote: > Hello PERC, > > Richard is stepping down as PERC co-chair, due to his new day job > responsibilities. Please join me in thanking him for his hard work to date. > > Nils Ohlmeier is stepping up to fill the vacancy. Please welcome him to > his new role, and take it easy on him for the first few days ;-) > > Thanks! > > Ben. > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a113e239a962e70054d758617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0Thanks Ben for the email. =C2=A0

Thanks= Richard to helping me learn the baby steps of chairing IETF and being a wo= nderful co-chair/mentor. I am sure there is lot more to learn and I will ke= ep doing so.

Welcome Nils on to the exciting journ= ey in joining along a passionate group of contributors in the WG. Look forw= ard for our collaboration.

Cheers
Suhas<= /div>


<= div class=3D"gmail_quote">On Tue, Apr 18, 2017 at 11:53 AM, Ben Campbell <be= n@nostrum.com> wrote:
Hello= PERC,

Richard is stepping down as PERC co-chair, due to his new day job responsib= ilities. Please join me in thanking him for his hard work to date.

Nils Ohlmeier is stepping up to fill the vacancy. Please welcome him to his= new role, and take it easy on him for the first few days ;-)

Thanks!

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

--001a113e239a962e70054d758617-- From nobody Tue Apr 18 13:06:13 2017 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 2815D129442 for ; Tue, 18 Apr 2017 13:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=jive.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 GyPJPH1B5uX3 for ; Tue, 18 Apr 2017 13:06:09 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63948127876 for ; Tue, 18 Apr 2017 13:06:09 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id y33so3405056qta.2 for ; Tue, 18 Apr 2017 13:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tVrvOHm6gnPuzPLvegwPpGPclOvF9snFc7Mqo8COOIA=; b=pTMXoFcu8Rxs3e9crVduGIVwIRpU6gJTY8UPgNSGkJE995RKDK55KhN+vHXywn5qDB q1kjJLU9FtLS0g9q6fak5PVhySaz19SeVM1oKmWJMKJmgKpeYG/20p1zH2mGpNS1BWy6 AghJK3cwWm2ySIIFMLCmj1osoip3P5NmA/qn6XRGJKjNFKZ9INg4PiAoVd/yyqQM5Nfx KPfVuWGJKS89I8m34RDg78DbB80RiVEGAIfv2+axgocvWEsQ3YC5DKjkiAHsgERZstPS 78/CLXCMamzXthXYyC/cy403NqMkhlG2ZN+EZ5667/ssSuADxDB8BpB6zkvCPzvXg1hX l3KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tVrvOHm6gnPuzPLvegwPpGPclOvF9snFc7Mqo8COOIA=; b=mJaWot8uzGfpbNpPk3ZXbTOkKdhIjpVrmMIZwTccYD9VO1BMflsTog9cqMscmZMbFN 4kELoJZpyJ8NqE4anEzfoRWku2pgfyNkx8LyTdumoecr1GF6kQC9QbbCn5luK08zkwH8 CjcPPuPrTdrbpkil8CsdIBOBoY5WKaPC6r5Lza3xp5XqilaR89p/0lQdkh2zXqeXdgCE NOrJ1HrPN9lw8Jmohn08CSn8AGyrW69lTrBkm7xQu0NG+SLD+NCT5UITm4/oZgD362Nd kAXxV+mxylTSchIS1o8x1OX8X27tunOB3hWHdDrxVgTtT0+6wJ0afeP0s85lrQkzwsJn L9Sw== X-Gm-Message-State: AN3rC/5g9QKkvl1AmldJQ6e/Wi8nxmUNQRL0PW+lXKpRInSP5cmKFykr 7uEUcR9qPzabrIKl X-Received: by 10.237.58.70 with SMTP id n64mr4329442qte.196.1492545968580; Tue, 18 Apr 2017 13:06:08 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([209.226.201.242]) by smtp.gmail.com with ESMTPSA id t22sm144389qke.49.2017.04.18.13.06.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 13:06:08 -0700 (PDT) To: Ben Campbell , perc@ietf.org References: Cc: Richard Barnes , Nils Ohlmeier From: Simon Perreault Message-ID: <4b1d7b91-616a-fa1f-43bd-39dd5c2f9974@jive.com> Date: Tue, 18 Apr 2017 16:06:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] Change of the Guard X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:06:11 -0000 Le 2017-04-18 14:53, Ben Campbell a crit : > Richard is stepping down as PERC co-chair, due to his new day job > responsibilities. Please join me in thanking him for his hard work to > date. Thanks! > Nils Ohlmeier is stepping up to fill the vacancy. Please welcome him > to his new role, and take it easy on him for the first few days ;-) Excellent choice! Good luck Nils! -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Fri Apr 21 12:17:40 2017 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 CA675129B36 for ; Fri, 21 Apr 2017 12:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LsKMaf5rA0RX for ; Fri, 21 Apr 2017 12:17:37 -0700 (PDT) Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D611287A0 for ; Fri, 21 Apr 2017 12:17:36 -0700 (PDT) Received: from smtp21.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp21.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 40C9CC036A; Fri, 21 Apr 2017 15:17:36 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp21.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id CAB45C025E; Fri, 21 Apr 2017 15:17:35 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.82.172.35] ([UNAVAILABLE]. [173.38.117.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Fri, 21 Apr 2017 15:17:36 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_30BD2CFE-46A4-46A1-8B14-96AEFF6FEA99" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 21 Apr 2017 15:17:34 -0400 Cc: perc@ietf.org Message-Id: <7D82714E-6AF8-40F7-96FE-64AA81E4F587@iii.ca> References: To: Suhas Nandakumar , Nils Ohlmeier X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Perc] Perc Virtual Interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:17:39 -0000 --Apple-Mail=_30BD2CFE-46A4-46A1-8B14-96AEFF6FEA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi -=20 I'd like to request some agenda time - I suspect 30 or 40 minutes would = do it - at the next interim to present what the problem is and possible = ways we could solve this RTX / FEC / DTMF issues.=20 Thanks, Cullen > On Apr 18, 2017, at 2:02 PM, Suhas Nandakumar = wrote: >=20 > Hello All >=20 >=20 > To carry forward the discussions on RTX/FEC support in the PERC = Context from IETF 98, we have setup the following doodle poll. >=20 >=20 > http://doodle.com/poll/wag852eknq3yidpy = >=20 > The meeting will be for 120 mins (2 hours) and will be an online = meeting. >=20 > Please complete the poll by 4/24/2017 EOD (PST time) to enable us to = setup the official proceedings. >=20 > Cheers > Perc Chairs >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_30BD2CFE-46A4-46A1-8B14-96AEFF6FEA99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi - 

I'd like to request some = agenda time - I suspect 30 or 40 minutes would do it - at the next = interim to present what the problem is and possible ways we could solve = this RTX / FEC / DTMF issues. 

Thanks, Cullen




On Apr 18, 2017, at 2:02 PM, = Suhas Nandakumar <suhasietf@gmail.com> wrote:

Hello All


    To carry = forward the discussions on RTX/FEC support in the PERC Context from IETF = 98, we have setup the following doodle poll.



The = meeting will be for 120 mins (2 hours) and will be an online = meeting.

Please = complete the poll by 4/24/2017 EOD (PST time) to enable us to setup the = official proceedings.

Cheers
Perc Chairs

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

= --Apple-Mail=_30BD2CFE-46A4-46A1-8B14-96AEFF6FEA99-- From nobody Mon Apr 24 03:36:37 2017 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 78CAD12EC69 for ; Mon, 24 Apr 2017 03:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxIpDokRgCxL for ; Mon, 24 Apr 2017 03:36:34 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 1F75412EC95 for ; Mon, 24 Apr 2017 03:36:34 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id l50so15152023wrc.3 for ; Mon, 24 Apr 2017 03:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=TPTQp3PsZOtlU0CM/M1TXj8DQ9KYm+B6zr42T4bC8uw=; b=e5YXtAWepnuslnmjL7lm0NkSXA0FfdoRPFQQmuNtp4r2ml1fH6qkJ2HJ6nRUQ0dnBM BHmSIbLHTtlpkUJIAZnOVw4nuMdaqjTHJGw5Xp91ErfWLs2QfaOdKZxnMSaRvg4gZspe VLszowZMZPxNYNNuNYEwGz9yHb+vgs5Op4c4Gj00f/gQ1mgeRTqFbyKsL2mOGeQLVaqQ H9yqr94jiVumNWzr51I2djCnH83BF+QLzxEzZvvJznu7FI7vVbGBlAZZRAeAENiW5rqY xeh39iFpFqM0nK0+OfIjimQWUTEehhtkQcxfyitgk5Duyhxa/RLVm70EFbP4jPmVPHzd WUgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=TPTQp3PsZOtlU0CM/M1TXj8DQ9KYm+B6zr42T4bC8uw=; b=bpSkABdJEUucfsfEHRjKYmz88P27GhUQfQffB0001H/q2fvF21q7PnitHj3b88o9eF kJAcTWt1FX7EUwREYrrcfw51WZVYvjm1oafZPrLDD2yfjS4+zKbIshKqOOHK5Khz9c2k Ta66+oh7tIuwaagLkkkZFNG0lXP3zu8S58FGIVqHjZZQCHc8kQYE1reRSxF3/dlM2vL0 uYY5OS+fDa0zOcieqXIyfBzF3e88N+BLsD2lA0UI0/KoC5ITlw4Rq76pEm+S1lwaEgym DwJhws/aGb607cw+PJ7tLR04v0Q0jB3BHpTr8RnWuQsyXDL8cVJK9B9/ezkm/1mPW4js woKw== X-Gm-Message-State: AN3rC/5pJ491tbCYjHOi7Otcil+RoCmvzipXLfCmGeMe3srBZOky7bRY Wo7Jb41nx1/V2ZQbr6s= X-Received: by 10.223.173.212 with SMTP id w78mr2706597wrc.144.1493030192302; Mon, 24 Apr 2017 03:36:32 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id r29sm21748245wrr.45.2017.04.24.03.36.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 03:36:30 -0700 (PDT) To: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> Date: Mon, 24 Apr 2017 12:36:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:36:35 -0000 Hi all, I have seen no more activity regarding the E2E RTP header issue. Is there a consensus that they can't be supported and that there is no use case for them? Does anyone have a different view? Should this be discussed and agreed on next virtual interim meeting? Best regards Sergio From nobody Mon Apr 24 03:46:01 2017 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 A889212F268 for ; Mon, 24 Apr 2017 03:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3nRiqLnPCtni for ; Mon, 24 Apr 2017 03:45:58 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 11F7D12EC95 for ; Mon, 24 Apr 2017 03:45:58 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id w64so58148987wma.0 for ; Mon, 24 Apr 2017 03:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=zFMczl/LfPTArSVTxP9f61JqBk3sOrZbG5s7gSD8uts=; b=VcOu5+m93ZJhVy7q36Id+QucXWbL/Wjc2eKwjgyiODRe30XP62HeY3mPLY4pg00Nf+ sLuHJQYw1PPb2SIFJb5iexjXpVkgdIA1kycJrdagIwJHQK09mQyhEWTQ/gWiQZf3GAmM IbHEwy5GHyuWuT4fjOZIuOo2+ebHYXJUSqRnVFvPj4/1DvLjATKvrRPiEIvsfo/0LeUT Vdg9ijKDYJcFEJHt5ta6+rBmRxx3sjHNxHAP5bzGxzRl8Ogi/y5fupC6KTL7dQJwUPtN oi04eK9+BxpRJ27k+W5Ra/6VSL+FfWUoW3KnU0KsXxwl/nzOVXiKc+vktK5sNvyiN8Oj l/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=zFMczl/LfPTArSVTxP9f61JqBk3sOrZbG5s7gSD8uts=; b=Zthi5jQCYr+oOflKyG/wZfCoKScKLREfmBuZDtPL6zd7hGwnnA4VdF6NjTpuhWlDtm thOZD/+eg5K1K572SS8TTwqYlxcmLX7u0pfadZulkqElXVpsUZqks+NjFLcmqKoz0u73 oGfl619knjnk4ayoNv8t0oGGCYUCVE+jq35GmE6rACyFEkYEV6kW/lFNjFUWLb4b9/SM UgdhSCF2M2InW1Mu2WYSMHTeMNmmggqkpLm0uoCaFpHs3Ft6jGaLHB+KvfUamZtVPogA gN7db8b3KDvD5Esd3RXrbacaJETs+Vpn+LvjgU2O+yu2zVC47/vdisdqln6q1JlAavoc hfRQ== X-Gm-Message-State: AN3rC/6OxsTQMjTwnnw+AWG9eGhpcwcdGK1xgsW10y90Nc9Of3UQ9HJA fRba2Tuesxbphe6wGsw= X-Received: by 10.28.45.213 with SMTP id t204mr8810889wmt.35.1493030756393; Mon, 24 Apr 2017 03:45:56 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id c34sm9100643wrc.7.2017.04.24.03.45.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 03:45:55 -0700 (PDT) To: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> Date: Mon, 24 Apr 2017 12:46:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:46:00 -0000 Hi all, I have realized about an edge case that I don't think we have taken into account. It is unlikely, but possible that two different peers use the same SSRC when sending data to the SFU. The SFU will protect against this HBH ssrc collision by re-writing the ssrcs to all the participants. The inner crypto will be applied on the original ssrcs from OHB and if my understanding is correct, that will cause the SRTP session to fail to authenticate the packets from one of the peers due to the sequence number jumps. Can anyone confirm if this scenario is correct? Do we have any solution for this? Best regards Sergio From nobody Mon Apr 24 08:39:01 2017 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 E2EBF131738 for ; Mon, 24 Apr 2017 08:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WdGfFQXikqk for ; Mon, 24 Apr 2017 08:38:58 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 57B7A131730 for ; Mon, 24 Apr 2017 08:38:58 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3OFcrS6023511; Mon, 24 Apr 2017 11:38:53 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2a01x6sha2-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Apr 2017 11:38:53 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 24 Apr 2017 10:38:52 -0500 From: Jonathan Lennox To: Sergio Garcia Murillo CC: "perc@ietf.org" Thread-Topic: [Perc] Drop support for E2E RTP header extensions Thread-Index: AQHSvRCAPTZRb6xCM0OEHs1XPMlsHKHU+2+A Date: Mon, 24 Apr 2017 15:38:51 +0000 Message-ID: <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> In-Reply-To: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.243.43.122] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-24_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240267 Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:39:00 -0000 DQo+IE9uIEFwciAyNCwgMjAxNywgYXQgNjozNiBBTSwgU2VyZ2lvIEdhcmNpYSBNdXJpbGxvIDxz ZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4g DQo+IEkgaGF2ZSBzZWVuIG5vIG1vcmUgYWN0aXZpdHkgcmVnYXJkaW5nIHRoZSBFMkUgUlRQIGhl YWRlciBpc3N1ZS4NCj4gDQo+IElzIHRoZXJlIGEgY29uc2Vuc3VzIHRoYXQgdGhleSBjYW4ndCBi ZSBzdXBwb3J0ZWQgYW5kIHRoYXQgdGhlcmUgaXMgbm8gdXNlIGNhc2UgZm9yIHRoZW0/IERvZXMg YW55b25lIGhhdmUgYSBkaWZmZXJlbnQgdmlldz8gU2hvdWxkIHRoaXMgYmUgZGlzY3Vzc2VkIGFu ZCBhZ3JlZWQgb24gbmV4dCB2aXJ0dWFsIGludGVyaW0gbWVldGluZz8NCg0KQXQgcHJldmlvdXMg dmlydHVhbCBpbnRlcmltcywgSSBiZWxpZXZlIHRoZSBjb25zZW5zdXMgd2FzIHRoYXQgbm8gb25l IGhhZCBhIGN1cnJlbnQgdXNlIGNhc2UgZm9yIEUyRSBSVFAgaGVhZGVyIGV4dGVuc2lvbnM7IGhv d2V2ZXIsIGlmIHdlIGRpZG7igJl0IHN1cHBvcnQgdGhlbSwgcmV0cm9maXR0aW5nIHRoZW0gaW50 byB0aGUgcHJvdG9jb2wgbGF0ZXIgd291bGQgYmUgZXh0cmVtZWx5IGRpZmZpY3VsdC4gIFRodXMs IHdlIChyZWx1Y3RhbnRseSkgZGVjaWRlZCB0byBzdXBwb3J0IHRoZW0uDQoNCklmIHRoZXkgdHVy biBvdXQgdG8gY29tcGxpY2F0ZSB0aGUgcHJvdG9jb2wgdG9vIG11Y2gsIEkgc3VwcG9zZSB0aGlz IGNhbiBiZSByZXZpc2l0ZWQu From nobody Mon Apr 24 08:46:36 2017 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 05346131755 for ; Mon, 24 Apr 2017 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBOTazN-rLpn for ; Mon, 24 Apr 2017 08:46:33 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 6D5291316C0 for ; Mon, 24 Apr 2017 08:46:33 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id z109so94300451wrb.1 for ; Mon, 24 Apr 2017 08:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KafOh0crbQogHWZzH9bsn1CLWKSpJpX8PHNIsuoKYeI=; b=Ydyb58WKhTWh143PSi/e6rZrHR+cA65CXKqq8wnkdqhYSiMbvv/jbS59zUQF7Ui/L3 IakR8F0SMerKSjuTNGh2HGfKacH2bqTESVX/OMSXbE6r6n0Ce8gFXeJAHtSj1EpfPZeH KEcfDfbzGqhtWcL5rFxIhoRZ8r9gNmmf74jBGY8ChCoYqlu076rGSpNcoIJjSkzGi/FE i91OmBdz+bk/Y0semBE+Drxdga0ArPd0ZgFVouonhzuZ2wPPnuBlKTTmCUWzbh49nAfT H5yiP0r/5YCUelLicNjAcw5y5xvWD6lW459QZU2k7L5ncjZv8LfRFw1Lm+nZ6wXVtv2B qFRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KafOh0crbQogHWZzH9bsn1CLWKSpJpX8PHNIsuoKYeI=; b=maTl9KJRXhxJyrdUc9mSPCcJJZjufykJpguQ6GYumfNaKAb/jxzTB+7ow882OR/X/f zzHfjL4aHzPE+Yk+68H/nxDfp36mVP5nHgtg4Ktgxd+nH/pIX5dvAP+nY3w5EgMNVeiB hiKZ67eV3M0b8nBdeATGN4TjJM9jBd7RAkXglgAKZoqCG2rsvgJFUdpQFYVy2WLwsUZe QVmlYcfuOBAe719pTSBiTn48BWmaWPMoS+Kr94yXGSyNYqwjlkUJveXzeNp6oETE+hRi IOYlldic5yOw94oBfuNfTbyyMiqHi8U24B1jLMtnpsslOS5ipYS/cZgVmyo87TJUWhUl XFfw== X-Gm-Message-State: AN3rC/4SJO9Ix6XcMzySio6U/KvyLpyJlV9ADOZh5TXBb5mWcCHs7HSN DdnYfZrComMXsg== X-Received: by 10.223.150.18 with SMTP id b18mr6416755wra.98.1493048791912; Mon, 24 Apr 2017 08:46:31 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id b10sm946539wme.22.2017.04.24.08.46.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 08:46:31 -0700 (PDT) To: Jonathan Lennox References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> Cc: "perc@ietf.org" From: Sergio Garcia Murillo Message-ID: <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> Date: Mon, 24 Apr 2017 17:46:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:46:35 -0000 On 24/04/2017 17:38, Jonathan Lennox wrote: >> On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo wrote: >> >> Hi all, >> >> I have seen no more activity regarding the E2E RTP header issue. >> >> Is there a consensus that they can't be supported and that there is no use case for them? Does anyone have a different view? Should this be discussed and agreed on next virtual interim meeting? > At previous virtual interims, I believe the consensus was that no one had a current use case for E2E RTP header extensions; however, if we didn’t support them, retrofitting them into the protocol later would be extremely difficult. Thus, we (reluctantly) decided to support them. > > If they turn out to complicate the protocol too much, I suppose this can be revisited. Hi Jonathan, thanks for the heads up. Apart of making protocol complex, the way that rtp header extensions are supported on double encryption won't work on E2E mode except on the most trivial scenarios. So, I expect that either we drop support or find a way to fix it. Best regards Sergio From nobody Mon Apr 24 08:52:53 2017 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 0EE31131748 for ; Mon, 24 Apr 2017 08:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJnYVGcX8Hi1 for ; Mon, 24 Apr 2017 08:52:49 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 853E4131744 for ; Mon, 24 Apr 2017 08:52:35 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id m123so71955136wma.0 for ; Mon, 24 Apr 2017 08:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mw/OuNDU9wBYod+gWpBW4BEQlzzc+Hfb89JG77JQ25Q=; b=n4uoiRPv53qF5b8jDfN9XAV1soCC/LBaR7/WUJ1nGmu6WTv/SNDj8ZugvwOucu4DFl lybiHEhGnPouW1Y1SoLhWIMiQmFn2L/iiU+CVxmEqHatK7lU1ou0LbqWVFHXqH6pPOjA +IVWp4Kf97J/silZScFEcF8a2ST8Ng0DZ7W/khOEL/lN9U9zFDB7LiEfyTg00SLkW+Td 9dFDQvoBcXAJfJZQkCpB7fjM/DlYbaD/XPxmcH9a3r9x/Xy87KZVH+MV78Wuy6R0nDuG aa68l7UD9ysWkcD8L9ll1CI0xvwkBTZ2M0lWy8qaVKJoMVHp5PsgXvIVAHNycFNm8rF7 rzbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mw/OuNDU9wBYod+gWpBW4BEQlzzc+Hfb89JG77JQ25Q=; b=TTUtTKCP+PsAzh4HyfvK/HAa4q8OnEHx+rrw7BcCH+BaooJXwYOhWmvmhhA7uwhQ7J eNhons5KsU5uOTPL2qk9oGOcNG/i7pHSy3Q7xk69kQHKzfXzzSYmvjz5Ca9YYBrM0aNj o/c2xiqone1o2mEf1hmqgjgsfa44DR9+oAHVhWU9lmawpFB0zBuRub2kjJRc7qK1WHTG ARqJ76sczxw+tMSe9CfuhaOUff23SdibrLF6QxaO5WMeR4y/rwfxIhtG2hEkFkmQ1tMV bURBwg72OzaxFmV9L0uLxSm04LKOxXNYxANGMhmrquVxnK3WKS0xu4EIyYpe/kxLQF43 hx1w== X-Gm-Message-State: AN3rC/4dcbcbwU6lomD5YD9wmJ4+M8HzJ98Kh9EjnT2KrdPNbVSoIBwL HLLGIsjtaGehXaEAomBVxxtU2JeBjA== X-Received: by 10.28.47.202 with SMTP id v193mr10317812wmv.131.1493049153757; Mon, 24 Apr 2017 08:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.84 with HTTP; Mon, 24 Apr 2017 08:52:33 -0700 (PDT) In-Reply-To: <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> From: Richard Barnes Date: Mon, 24 Apr 2017 11:52:33 -0400 Message-ID: To: Sergio Garcia Murillo Cc: Jonathan Lennox , "perc@ietf.org" Content-Type: multipart/alternative; boundary=001a11423f60713aa8054deb986b Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:52:51 -0000 --001a11423f60713aa8054deb986b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 24, 2017 at 11:46 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 24/04/2017 17:38, Jonathan Lennox wrote: > >> On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo < >>> sergio.garcia.murillo@gmail.com> wrote: >>> >>> Hi all, >>> >>> I have seen no more activity regarding the E2E RTP header issue. >>> >>> Is there a consensus that they can't be supported and that there is no >>> use case for them? Does anyone have a different view? Should this be >>> discussed and agreed on next virtual interim meeting? >>> >> At previous virtual interims, I believe the consensus was that no one ha= d >> a current use case for E2E RTP header extensions; however, if we didn=E2= =80=99t >> support them, retrofitting them into the protocol later would be extreme= ly >> difficult. Thus, we (reluctantly) decided to support them. >> >> If they turn out to complicate the protocol too much, I suppose this can >> be revisited. >> > > Hi Jonathan, thanks for the heads up. > > Apart of making protocol complex, the way that rtp header extensions are > supported on double encryption won't work on E2E mode except on the most > trivial scenarios. Since we're talking about E2E protection, it seems like the only scenario is "the header travels unmodified from sender to receiver". It seems like this is supported in the simplest way possible; all the E2E headers are grouped together, before the OHB. Beyond the OHB, you can do whatever you want. What advanced scenarios are not supported here? --Richard > So, I expect that either we drop support or find a way to fix it. > > Best regards > > Sergio > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a11423f60713aa8054deb986b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2017 at 11:46 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 24/04/2017 17:38, Jonathan Lennox wrote:<= br>
On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmai= l.com> wrote:

Hi all,

I have seen no more activity regarding the E2E RTP header issue.

Is there a consensus that they can't be supported and that there is no = use case for them? Does anyone have a different view? Should this be discus= sed and agreed on next virtual interim meeting?
At previous virtual interims, I believe the consensus was that no one had a= current use case for E2E RTP header extensions; however, if we didn=E2=80= =99t support them, retrofitting them into the protocol later would be extre= mely difficult.=C2=A0 Thus, we (reluctantly) decided to support them.

If they turn out to complicate the protocol too much, I suppose this can be= revisited.

Hi Jonathan, thanks for the heads up.

Apart of making protocol complex, the way that rtp header extensions are su= pported on double encryption won't work on E2E mode except on the most = trivial scenarios.

Since we're talking= about E2E protection, it seems like the only scenario is "the header = travels unmodified from sender to receiver".=C2=A0 It seems like this = is supported in the simplest way possible; all the E2E headers are grouped = together, before the OHB.=C2=A0 Beyond the OHB, you can do whatever you wan= t.

What advanced scenarios are not supported = here?

--Richard

= =C2=A0
So, I expect that either we drop= support or find a way to fix it.

Best regards

Sergio


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

--001a11423f60713aa8054deb986b-- From nobody Mon Apr 24 08:57:50 2017 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 74823131777 for ; Mon, 24 Apr 2017 08:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ZapV9rC7uq1B for ; Mon, 24 Apr 2017 08:57:46 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 5679313176B for ; Mon, 24 Apr 2017 08:57:46 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w64so534943wma.0 for ; Mon, 24 Apr 2017 08:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=zlHDw+AQhVdMVKENIvPvuWUxClGlRoYYO4lxayNKl+4=; b=ESZyfpccY+ENZL31oqU0SrzN4PPw2uAs8dhWGXz7LDe760ZZvvJZrVEr2wzgI27Ebl ZHd//A21bSPraE2gD0gMAvy6l0P0j/xmHwfcWzqgOxc4kEIDTOuKuWkTL1EgJ9DCjifM uEjN4fFVUiO5SVErTT0LDlcJhJskjV/ASp+65UIYGc/cJUo6ejaTIWJMIIBbFmEJ42Zg z05BHKoAeae4kD6UWzWWcAT5oK83uzEtAcre0zgvNSSXcUBROAG6wba74sQVnDvqSgY5 9KCMY+CzSPQX8e5TWFUh305V+CtnQUr7WRp70nTIbXhOCkqYio6fs+8C7ON2hQM8666t LXFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=zlHDw+AQhVdMVKENIvPvuWUxClGlRoYYO4lxayNKl+4=; b=lNMbq1dDHkC0KLknDUGsfxQ4UHKBOJrLBQIlF4dikrDm1UOtOo/nk6Tvnfy72Cly8y bRQrxzaEiicvme1/qEyU31UIPZ0Qjuh8MtRPBFqykIkOi/Ewbni1MkAgqOPnPUrR7NaQ BUKFYiwzy1ail0cD1CeJ6OvDr7H+Go3iE/PQttAzm0AB+wQalaEbTI5JY9djBj1jUBiU h0W/RPKsaHmbcD/eBpzAAhheGPJ7ejVHQ3y1AT1ImV77qQB34Mg6J1D+Yr3+IgxrHhln c2JGKbG08Bduu5T5h1pGNlyFmpbP9KRpBHXKlruCGPkNrvgR+z1fKQhCR+1HNZekX6K5 JH0A== X-Gm-Message-State: AN3rC/7x2nff0PiAxGD1iIGDBEs6HYI7mlBMCm5BZfMr8d0Pq2D5q3jl FK30d2hHSVDRTw== X-Received: by 10.28.74.218 with SMTP id n87mr9257650wmi.71.1493049464853; Mon, 24 Apr 2017 08:57:44 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id e129sm1055772wma.13.2017.04.24.08.57.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 08:57:43 -0700 (PDT) To: Richard Barnes References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> Cc: Jonathan Lennox , "perc@ietf.org" From: Sergio Garcia Murillo Message-ID: Date: Mon, 24 Apr 2017 17:57:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------39ADD87C8121C016C62E440F" Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 15:57:48 -0000 This is a multi-part message in MIME format. --------------39ADD87C8121C016C62E440F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 24/04/2017 17:52, Richard Barnes wrote: > > > On Mon, Apr 24, 2017 at 11:46 AM, Sergio Garcia Murillo > > wrote: > > On 24/04/2017 17:38, Jonathan Lennox wrote: > > On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo > > wrote: > > Hi all, > > I have seen no more activity regarding the E2E RTP header > issue. > > Is there a consensus that they can't be supported and that > there is no use case for them? Does anyone have a > different view? Should this be discussed and agreed on > next virtual interim meeting? > > At previous virtual interims, I believe the consensus was that > no one had a current use case for E2E RTP header extensions; > however, if we didn’t support them, retrofitting them into the > protocol later would be extremely difficult. Thus, we > (reluctantly) decided to support them. > > If they turn out to complicate the protocol too much, I > suppose this can be revisited. > > > Hi Jonathan, thanks for the heads up. > > Apart of making protocol complex, the way that rtp header > extensions are supported on double encryption won't work on E2E > mode except on the most trivial scenarios. > > > Since we're talking about E2E protection, it seems like the only > scenario is "the header travels unmodified from sender to receiver". > It seems like this is supported in the simplest way possible; all the > E2E headers are grouped together, before the OHB. Beyond the OHB, you > can do whatever you want. > > What advanced scenarios are not supported here? RTP header extensions are negotiated on the SDP O/A, so not all endpoints may support same header extension, and even if they support same set of extensions, they may be negotiated with different ids. So it is impossible to support RTP header extensions E2E except in the scenario in which all endpoints support same subset of extensions and happens to be negotiated with same id. Best regards Sergio --------------39ADD87C8121C016C62E440F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 24/04/2017 17:52, Richard Barnes wrote:


On Mon, Apr 24, 2017 at 11:46 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 24/04/2017 17:38, Jonathan Lennox wrote:
On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

Hi all,

I have seen no more activity regarding the E2E RTP header issue.

Is there a consensus that they can't be supported and that there is no use case for them? Does anyone have a different view? Should this be discussed and agreed on next virtual interim meeting?
At previous virtual interims, I believe the consensus was that no one had a current use case for E2E RTP header extensions; however, if we didn’t support them, retrofitting them into the protocol later would be extremely difficult.  Thus, we (reluctantly) decided to support them.

If they turn out to complicate the protocol too much, I suppose this can be revisited.

Hi Jonathan, thanks for the heads up.

Apart of making protocol complex, the way that rtp header extensions are supported on double encryption won't work on E2E mode except on the most trivial scenarios.

Since we're talking about E2E protection, it seems like the only scenario is "the header travels unmodified from sender to receiver".  It seems like this is supported in the simplest way possible; all the E2E headers are grouped together, before the OHB.  Beyond the OHB, you can do whatever you want.

What advanced scenarios are not supported here?

RTP header extensions are negotiated on the SDP O/A, so not all endpoints may support same header extension, and even if they support same set of extensions, they may be negotiated with different ids. So it is impossible to support RTP header extensions E2E except in the scenario in which all endpoints support same subset of extensions and happens to be negotiated with same id.

Best regards
Sergio

--------------39ADD87C8121C016C62E440F-- From nobody Mon Apr 24 09:32:26 2017 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 D14EE131827 for ; Mon, 24 Apr 2017 09:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyAMQv7fGtld for ; Mon, 24 Apr 2017 09:32:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AFD113180F for ; Mon, 24 Apr 2017 09:32:23 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3OGWLik038796 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 24 Apr 2017 11:32:21 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Sergio Garcia Murillo , perc@ietf.org References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> From: Adam Roach Message-ID: Date: Mon, 24 Apr 2017 11:32:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:32:25 -0000 On 4/24/17 05:46, Sergio Garcia Murillo wrote: > It is unlikely, but possible that two different peers use the same > SSRC when sending data to the SFU. The SFU will protect against this > HBH ssrc collision by re-writing the ssrcs to all the participants. The issue of SSRC collision detection and resolution is covered at length and with normative language in . The entities involved in this process are exclusively media sources, not media intermediaries. /a From nobody Mon Apr 24 10:28:00 2017 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 751E01318C9 for ; Mon, 24 Apr 2017 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BLCJxpr_SxbI for ; Mon, 24 Apr 2017 10:27:58 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54141318CC for ; Mon, 24 Apr 2017 10:27:57 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j127so42450820vkh.0 for ; Mon, 24 Apr 2017 10:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PQm8u2aNyNd3e+A0tte2fUs1lsAxtbjle1mdeSYKqCo=; b=IXUEWF54/conMoRkyuMaIFr8vPiL/26xSTfnIsPvXpmWFq99sd6SjenE6ofNyVW8Ab 0ZfqmXRPLFKAadml6/I3SIwVVeTrdSXGkh5tlg1yYJJF6jZ9zilRR5HeZ+4Wp4uqlOTl Ghy+SIUInGb848ZMm/GbU9EkLR8S0/qliksZ0OWNdwJ58gLBfh6YwqTdU7Bd++hSpRm3 ElBfTVYxZQbfBBlMopb2NLSDcxeUTyPI//JJnzdBtkan0XJwoUab5IxJ1JTiARuNcZSO zyhEYLgUSb75ex/7X6LFcNkx2+64QA/OmFp5U8lnxduAdL+5sO9HPMjcIIYT4gnAe0yb 6dTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PQm8u2aNyNd3e+A0tte2fUs1lsAxtbjle1mdeSYKqCo=; b=U5cBiZVdVYukrRs/paeMsnj4U/OLVse5xXoA7LL8AVQt5+SO6qHiHbXad+qeY/Xl2A kGdzimzeyUGuELlzzs7Ud9s8Z2sCW+AXQRhIbtzLu7Ni2oZU+nKVMmK8OUkcmtRb+RRO nc5YZVZ5NM0mcFkOutlUBZlnrBd8qbD741xBADAZWluveiLAEHIIXmHJShxK9dm3Jcmi +5PXLm9cmnDGmE3zQyBp04tpXGqRHbL6WHdxWpStwtFwDtTiu+U06LtbwX+kBoh8/nf+ uj35C+5iyXOootIfhzoE5HVYO7yRItMsQrUNJP5QXaUwbrchdeamoltMM4EbOYn4/4M6 0oEQ== X-Gm-Message-State: AN3rC/4AzEmwCbB6BfUMnpo9VJOeC333VD/3D8gTD6VO7NHKi9yROpCM TfWCEUSA1K7YApUBrGZx+eV2taWh7A== X-Received: by 10.31.238.74 with SMTP id m71mr3331394vkh.109.1493054876664; Mon, 24 Apr 2017 10:27:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 10:27:36 -0700 (PDT) In-Reply-To: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> From: Bernard Aboba Date: Mon, 24 Apr 2017 10:27:36 -0700 Message-ID: To: Sergio Garcia Murillo Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114db14e8dd5b4054decedfb Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:27:59 -0000 --001a114db14e8dd5b4054decedfb Content-Type: text/plain; charset=UTF-8 Sergio -- Because PERC utilizes the original SSRC as a means to determine the key utilized to encrypt the payload, SSRC uniqueness is required across all members of the conference. This then raises the question of how SSRC conflicts are detected between the participants and which of the RTP topologies defined in RFC 7667 can be used with PERC. For example, while it might be desirable for a PERC SFU to support SSRC and Sequence Number rewriting, a PERC SFU doing this still has to enable the endpoints to be aware of the original SSRCs, so as to avoid conflicts. Effectively, it seems like asking for two distinct RTP topologies to be in use at the same time. >From the point of view of the original SSRCs, it seems that an RTP translator topology is needed. However, if an SFU is doing SSRC and Sequence Number rewriting, then it is acting as a Selective Forwarding Middlebox (Section 3.7) with respect to the rewritten SSRCs. On Mon, Apr 24, 2017 at 3:46 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi all, > > I have realized about an edge case that I don't think we have taken into > account. > > It is unlikely, but possible that two different peers use the same SSRC > when sending data to the SFU. The SFU will protect against this HBH ssrc > collision by re-writing the ssrcs to all the participants. > > The inner crypto will be applied on the original ssrcs from OHB and if my > understanding is correct, that will cause the SRTP session to fail to > authenticate the packets from one of the peers due to the sequence number > jumps. > > Can anyone confirm if this scenario is correct? Do we have any solution > for this? > > Best regards > > Sergio > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a114db14e8dd5b4054decedfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sergio --

Because PERC utilizes the ori= ginal SSRC as a means to determine the key utilized to encrypt the payload,= SSRC uniqueness is required across all members of the conference.

This then raises the question of how SSRC conflicts are de= tected between the participants and which of the RTP topologies defined in = RFC 7667 can be used with PERC.

For example, while= it might be desirable for a PERC SFU to support SSRC and Sequence Number r= ewriting, a PERC SFU doing this still has to enable the endpoints to be awa= re of the original SSRCs, so as to avoid conflicts.

Effectively, it seems like asking for two distinct RTP topologies to be i= n use at the same time.=C2=A0

From the point of vi= ew of the original SSRCs, it seems that an RTP translator topology is neede= d. However, if an SFU is doing SSRC and Sequence Number rewriting, then it = is acting as a Selective Forwarding Middlebox (Section 3.7) with respect to= the rewritten SSRCs.



=C2=A0







On Mon, Apr 24, 2017 at 3:46 AM, Sergio Garcia Murill= o <sergio.garcia.murillo@gmail.com> wrote:
=
Hi all,

I have realized about an edge case that I don't think we have taken int= o account.

It is unlikely, but possible that two different peers use the same SSRC whe= n sending data to the SFU. The SFU will protect against this HBH ssrc colli= sion by re-writing the ssrcs to all the participants.

The inner crypto will be applied on the original ssrcs from OHB and if my u= nderstanding is correct, that will cause the SRTP session to fail to authen= ticate the packets from one of the peers due to the sequence number jumps.<= br>
Can anyone confirm if this scenario is correct? Do we have any solution for= this?

Best regards

Sergio

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

--001a114db14e8dd5b4054decedfb-- From nobody Mon Apr 24 11:38:02 2017 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 3ADA4131933 for ; Mon, 24 Apr 2017 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGXbxUwvI8UB for ; Mon, 24 Apr 2017 11:37:59 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 E3FFC13192A for ; Mon, 24 Apr 2017 11:37:51 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id v1so5508960pgv.1 for ; Mon, 24 Apr 2017 11:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hFq3//uInDONlMUsuf/WG4FK7Ibj3voTZ3BAyBfl6OI=; b=NNhK7EzMWYp9IXtiaOEs2YhMvJ7+v6qgx56HsTRgZqHX5IF1QjLi9bi+sI1Rbxf+1B +UmVJfdYUGW0TGqmsyuW9G/MNhQjFLPrjdXLeCEHcSPrkPxcePTEkJoqEkRNYWZP/t3U Hz4XP7ftsu4FeSt8rQ7K29K0mBUgGOR9+EOqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hFq3//uInDONlMUsuf/WG4FK7Ibj3voTZ3BAyBfl6OI=; b=Uk82MR3C5otLQFjhgTq/uJK5ORa76ooYyhqv/UxXQtgjPX+WHRIf4hgswcKVte9OUn rvFfQ3EIw1W5sZXRVJMu9FJnfCq6GyQOW5qb9mGvse5My1GPL240mL2LeleOA39e0GlJ 7l0iTf21rUD9Sp8r72WLBiq4GVQYyLp1+M0V6MaYTAiO1oz0DOi6K7pVu/0H2ImMtozo AWfWEbiEIMCRcOCqQjfk1x2MCz1TtpT41kIP0FdWEbwSUbXxyTv6U+Bwc7Fq0O9MZnw5 qcbFL+WeOncbI+Qd3eeF5pqNZjGWKJJZpTp5BQyZyCcjIurI3+6Q0V+XQcxxUupFNzlg u4UA== X-Gm-Message-State: AN3rC/5NQ+qWBcMfLfio0oQXsdHaPh1G+8MyC7DzGUgB1A6U0PG+oFBx Er/o2TNaUho1WT5u X-Received: by 10.99.106.5 with SMTP id f5mr8330603pgc.66.1493059071501; Mon, 24 Apr 2017 11:37:51 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:3122:e88f:1459:8313? ([2620:101:80fc:224:3122:e88f:1459:8313]) by smtp.gmail.com with ESMTPSA id 186sm32136623pfx.72.2017.04.24.11.37.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 11:37:50 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9B16CB59-7526-4F54-9912-5450185CABBC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 11:37:47 -0700 In-Reply-To: Cc: Richard Barnes , Suhas Nandakumar To: perc@ietf.org References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Doodle Poll for Perc Virtual Interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:38:01 -0000 --Apple-Mail=_9B16CB59-7526-4F54-9912-5450185CABBC Content-Type: multipart/alternative; boundary="Apple-Mail=_F043E5FB-FB95-4732-A40B-98F0C13EF53D" --Apple-Mail=_F043E5FB-FB95-4732-A40B-98F0C13EF53D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just a friendly reminder that if you want to participate in the interim = meeting and haven=E2=80=99t entered your availability in the doodle = poll, please to do so today. Thank you Nils Ohlmeier > On Apr 18, 2017, at 11:02, Suhas Nandakumar = wrote: >=20 > Hello All >=20 >=20 > To carry forward the discussions on RTX/FEC support in the PERC = Context from IETF 98, we have setup the following doodle poll. >=20 >=20 > http://doodle.com/poll/wag852eknq3yidpy = >=20 > The meeting will be for 120 mins (2 hours) and will be an online = meeting. >=20 > Please complete the poll by 4/24/2017 EOD (PST time) to enable us to = setup the official proceedings. >=20 > Cheers > Perc Chairs >=20 --Apple-Mail=_F043E5FB-FB95-4732-A40B-98F0C13EF53D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just a friendly reminder that if you want to participate in = the interim meeting and haven=E2=80=99t entered your availability in the = doodle poll, please to do so today.

Thank you
  = Nils Ohlmeier

On Apr 18, 2017, at 11:02, = Suhas Nandakumar <suhasietf@gmail.com> wrote:

Hello All


    To carry = forward the discussions on RTX/FEC support in the PERC Context from IETF = 98, we have setup the following doodle poll.



The = meeting will be for 120 mins (2 hours) and will be an online = meeting.

Please = complete the poll by 4/24/2017 EOD (PST time) to enable us to setup the = official proceedings.

Cheers
Perc Chairs


= --Apple-Mail=_F043E5FB-FB95-4732-A40B-98F0C13EF53D-- --Apple-Mail=_9B16CB59-7526-4F54-9912-5450185CABBC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/kX8AAoJEJ3NnGfOORkkYEYP/RFahgqmFwvJ5oDvY2bCtntM iukEWlG+0tIEWLfo0sNS7qYei9GWjRtjz+MV84hOK7tTN+VQ04p8mkz832dEIQ7L 44vqx2cXGR4yFQ7myKe2qjR7AGxZ/3hPm1EefFyC/0lTKScHNWGPJj4UZAWLwiH2 nzCFvp1NOe9EQUNj+gPFqnOA5x7OMFos/mcBCdHPb1UczTUWFiKgk3sP9rDPlPmM YGv1ofKgw0jln5hs/kyjPoCXmcG05fhnjgH9cohBurye+xUPuySKHdB79Lq3D7pO A/J9XAon17qeLR3+/oxq9EnYzqTwlTHUzXBkKT1odArLvCUIJpWJ4Ac4KVuhQVVj VV00ZNKja/O7TeNhgaE1+CocDaaqxSmVyu4mDypqDdX3bL5+QP46QpekqOx67f/j lJxAl+EaM/sxZ1Ib9cQoDmE0IV8oYdfYR980vlIryapCtx4qKWy0IavbeYRTw6Nk x1URVfKV7QObTiy4nQlt/UhiPH3rolVCfnM1cyd+OsI36DVahfxRLyWjQ66YAQjC 2wCnqhkeyMMn1148+jMZW8tmoD3Jzv14BaT4jGHs1QyWcMAVe4vWbsvob4dCSUaQ RuYUfJ1JrcA7pyv0fRjHl64+nqRfS0oD/WTzB8PRRqNmLnCHHhTzD4g8JkUCJyUK /z77gBnjnrs212Cs4UUS =hJpy -----END PGP SIGNATURE----- --Apple-Mail=_9B16CB59-7526-4F54-9912-5450185CABBC-- From nobody Mon Apr 24 12:19:33 2017 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 07E081294A5 for ; Mon, 24 Apr 2017 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CnUWYKDZsZTZ for ; Mon, 24 Apr 2017 12:19:30 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CF3128B88 for ; Mon, 24 Apr 2017 12:19:30 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id m123so77157732wma.0 for ; Mon, 24 Apr 2017 12:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=NUCfHpzIrd8SVjgG2A/Kk00lkB+RSSLfcH+QvTzFhi0=; b=dP7Kb62pkqjTU2IgvrKdTRhOILbcZHFNq+ntYEK3l0ipnLMbbqFmLq31azYkrtWb2Q B9q7LuwKsXePBoQQiF7hcJ1+kG7CTGgGLOFsSuM8Ur4ymjZJnQtlM+FHqH+R2qMrhORq Ivy3uV7xU9t+bGd/T0xRm71WOKAd0cVS1N/2PhNf9peU8pN54Dz7P9R8k1RK9+jPTqZM TviJ2q8TYxjdKnj5QZQjwSJdE/KFqGTbVmKceFOcr7OxVxB27IjIOkdaghq31Elc1Ydd yGGlPR/eDiE8Gz/HNoYSTWOCuKUFRrV66VaXP2jWOyJ5ui2B7cmHXtS2/2oLcMo5JKUy gFvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NUCfHpzIrd8SVjgG2A/Kk00lkB+RSSLfcH+QvTzFhi0=; b=Xnymi+pvUgUBXL/F/UrmQEQVlKzcDbBk/4RezVh3+NTx4VnnS1b5xTfJN1Ev8rfZYt R9zBYpAUrSlDPoftaRua/Cpx5rjS8XrpKYxiaZlDNkpGkkMJMXIL+8ttWn7g4Kk4wfPk E3BFZfbMrvHpAi1KmTMvPMIOOkeWjGl7sL4sRPcMdnwVtbQhrzDASGPLJoRwkcxd65pN wxu78fTjWarMnPqdwX76gjaBSB1oytwBxotg+RHratvOc8ulVFeWzVqzXmb+t8i16fkg e7K3N6FEHgedv6yFA3SEkEhtt0o62OWbTPI5uHRfjhSSSDKFqCg/wSxuy68lzVA6RaGP +aJw== X-Gm-Message-State: AN3rC/4OFdGWxKp0MMvQtgG7gGCNI7Fm10m3kbYEuqifuqSbYWwtYkQ7 RQKaG2dt1NS/zg== X-Received: by 10.28.234.84 with SMTP id i81mr10049312wmh.138.1493061569142; Mon, 24 Apr 2017 12:19:29 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id n48sm8480269wrn.30.2017.04.24.12.19.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 12:19:28 -0700 (PDT) To: Bernard Aboba References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <4f83804e-7bc7-2343-9b1c-2b9fff6760ac@gmail.com> Date: Mon, 24 Apr 2017 21:19:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 19:19:32 -0000 On 24/04/2017 19:27, Bernard Aboba wrote: > Sergio -- > > Because PERC utilizes the original SSRC as a means to determine the > key utilized to encrypt the payload, SSRC uniqueness is required > across all members of the conference. > Hi Bernard, Aren't you referring to EKT? AFAIK in double encryption there is a single E2E key shared by all participants. Best regards Sergio From nobody Mon Apr 24 12:37:35 2017 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 6FA421294C0 for ; Mon, 24 Apr 2017 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v6CEbkBqRyn for ; Mon, 24 Apr 2017 12:37:33 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 DB8F51294F6 for ; Mon, 24 Apr 2017 12:37:31 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id u65so5569398wmu.1 for ; Mon, 24 Apr 2017 12:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SZ1ip9SYF/5HWVmfPpXTJwKt9VAgwR0trePjCbCbErI=; b=MqNDiBqZ1KughkqG06DzeTEDwn8w2Dg+FJS4SFXjkRU2vHGLcfck7iXuYZzS5qVGLL hZ2gnfcCTmSLuVthH8K3SeHncmEIu3e8RFeKb/WPOwaD5R/tct1AcvgR3w3zHTRNmuwQ 71oPS/EBfVXb9dI7awKin5iA/XdjS+jG2BlO2kEybnoz/pB+W6lv0dRyU5UumwCEw/Sk MQKOjCvcQUt2AlfnH1tn+mOJcpOeAhhPtFSAvIVuPqGIjti1myI0c0kcnzm6Gw4nukui DR6YQWsPYa78IOtftR+ZlPN4y9zwm5luzGF9h3ac+jXNkWltG8JSKVnO1W+1lK8/NLVP 1fgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SZ1ip9SYF/5HWVmfPpXTJwKt9VAgwR0trePjCbCbErI=; b=qJfL0qey/zk+889UqgcTTBgas6UMEDEAwASnIEUgVNT0XxI6KfhbqwNAIo3W3/ISDp 1oThqc4Ygic2XGJSANf0m3+qllGvXEjV/fdZKrWtFItA5v7FGMBegc8X4Xm2VoNDhmu0 vsTTxD34H/zdFpfzZRxIjrRDMHfuaj1/Ffofs6x01uKxoAOiHJS0IaBTsLXqroAnLkNC hHyvebTuIHRD1rtmeV57Cw6TmgEn2rnX+zfc5uWbON0KrmA9f7mRQHsRuUdICukvEsjH EFQdCvfKTTaMN7iOwXApkb3lC5SE3bXYsFZ8VjfjSDHUc+qPwlAfjKL4vy9EJLOu7Fet PDkA== X-Gm-Message-State: AN3rC/7XVecbFlnsZ7ffJBKrVrTrvsO1R9EW7iFlwKPfO5+eVfAbk9j1 CcqZLmCg620/fw== X-Received: by 10.28.228.4 with SMTP id b4mr11068085wmh.119.1493062650294; Mon, 24 Apr 2017 12:37:30 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id m83sm395080wmc.7.2017.04.24.12.37.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 12:37:29 -0700 (PDT) To: Bernard Aboba References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> Cc: perc@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Mon, 24 Apr 2017 21:37:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 19:37:34 -0000 On 24/04/2017 19:27, Bernard Aboba wrote: > Sergio -- > > Because PERC utilizes the original SSRC as a means to determine the > key utilized to encrypt the payload, SSRC uniqueness is required > across all members of the conference. > > This then raises the question of how SSRC conflicts are detected > between the participants and which of the RTP topologies defined in > RFC 7667 can be used with PERC. > > For example, while it might be desirable for a PERC SFU to support > SSRC and Sequence Number rewriting, a PERC SFU doing this still has to > enable the endpoints to be aware of the original SSRCs, so as to avoid > conflicts. > > Effectively, it seems like asking for two distinct RTP topologies to > be in use at the same time. > > From the point of view of the original SSRCs, it seems that an RTP > translator topology is needed. However, if an SFU is doing SSRC and > Sequence Number rewriting, then it is acting as a Selective Forwarding > Middlebox (Section 3.7) with respect to the rewritten SSRCs. > I agree, and i don't see an easy way of solving this without ensuring the SSRC uniqueness. For EKT maybe ssrc assignment may be done by the key distributor when providing the key to the endpoint, but for double encryption I would prefer a simpler approach, like reducing the randomness space of SSRC to latest 16bits, and set the first 16bits to a "participant id" set by the KD or the SFU. Best regards Sergio From nobody Mon Apr 24 12:42:59 2017 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 1061B1314ED for ; Mon, 24 Apr 2017 12:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hZp2yJ58RTeM for ; Mon, 24 Apr 2017 12:42:57 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414261294FE for ; Mon, 24 Apr 2017 12:42:57 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id r190so77887602wme.1 for ; Mon, 24 Apr 2017 12:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=krOtdgMxlcHUC/fWAyDMX3BwoYdRkdu9/UJYgMVb6sk=; b=KPsVT4STO3mUueB+dbH2fXL4PEngoDespwUJ/XaImlYXtep6nIRr8GKadMO54bQo1B n5lZlse51IocLtEh3sTiWswPtqPg30lWGWJBsSzx11JyBHcy/5eVBdG114XF1NUXriWi S8jqpOiJ/El1YMJS7gM0ikjl1O/2X1MEaTBe8sxPIoeedhgIUSPNmdd+uz7SoIgoKjRa QCGrIVOWe9RCLqqsVpl0FHZxq160z22e4y34O1wYd+qSE1RqhjcGuIrklIsER1conBKF Bgi7AlYr8CmHEqXJVH2nsXQ6pvgYdml0kIe4TuxSxeOgx4z0YhkNnoTFcEOyDFc/yRa5 hXnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=krOtdgMxlcHUC/fWAyDMX3BwoYdRkdu9/UJYgMVb6sk=; b=srzPIp6rLX3PTN2Ut0c4mcboGSeTKOmW0qcVMVqLxqqsAMTAon64Hz6CV4QiRZBdbe CD4zTfzIcFWQ4GUYgEBoipX8wVmREVbTuhfF0RTIGXPYx1xHSRUbCLmqinEVDeIEDjFy 2F0QWDwdSkSlEk/Lu3uncKpkJcqRVeJ2QQLvZdt7zp2z05WuoX5hxBy3GsbYREb0tp6f rW1j+x2ubYaNSGKNrCFCGKTsEgR55Vw9gMaNpIJd1/LYUOjVQ9vFCDARnAHEHs4cT5EZ 5IBliHRVzq7wPY+rISqr/2RSAXGBbbdNovP1A7RChueHA72Gk8MlYz8Y9QMC+IzDoqYS qWAA== X-Gm-Message-State: AN3rC/59JDD3qh1n3nvMeie2mooNwEY9vLz7tgalijTR2lRJxkDrHR3K BqR7htOU1oL0ZcufBvM= X-Received: by 10.28.98.65 with SMTP id w62mr11236090wmb.85.1493062975538; Mon, 24 Apr 2017 12:42:55 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id i21sm23529632wrc.50.2017.04.24.12.42.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 12:42:54 -0700 (PDT) To: Adam Roach , perc@ietf.org References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 24 Apr 2017 21:42:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 19:42:59 -0000 On 24/04/2017 18:32, Adam Roach wrote: > On 4/24/17 05:46, Sergio Garcia Murillo wrote: >> It is unlikely, but possible that two different peers use the same >> SSRC when sending data to the SFU. The SFU will protect against this >> HBH ssrc collision by re-writing the ssrcs to all the participants. > > > The issue of SSRC collision detection and resolution is covered at > length and with normative language in > . The entities > involved in this process are exclusively media sources, not media > intermediaries. I am not aware of a single SFU that handles SSRC collision that, they all overwrite the SSRC to avoid it. The E2E SSRC collision will happen with the SSRC values of the OHB when doing the inner crypto, so RTP mechanism don't apply. Best regards Sergio From nobody Mon Apr 24 13:27:22 2017 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 AD82712422F for ; Mon, 24 Apr 2017 13:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 V4GkVG_s--bo for ; Mon, 24 Apr 2017 13:27:18 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 792CC1200F1 for ; Mon, 24 Apr 2017 13:27:18 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id j127so45073820vkh.0 for ; Mon, 24 Apr 2017 13:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0V8qUWOVIrI3Js5EoyIQ5Fjr7q/AITDquKkhEeK6LrQ=; b=AV4Dd8u115ZNhAxjGSzNrFrSxGxWIG+9oNtkhU/+rcNznBPrc6jhjpZJqABwpzEtLd r3BK5NfS/+IDDi7cXQmnbFFPS+ErFbH3ZsiTBJyoomDzXJjNq1yA6J6wiQpjgoFuAHpd xDfNQiVALrVinMWQuOc0SdJw/jI+pWqRoNdBE0kPMXFdTxt0eeKOLEDxSWyY0b25/hUf Z+Yy55QlNT9uLDzzKyjl4K1P+fWpj5e51eTSWsoKCv5+X7mafrsDtN9BkM7oaST7yf4J DGwoU8qEEnuSgnVGccJ/rHFWfx6MXikhxBr9cQqWjxMN7iN+rrCKMFS8bsXihDrzpts8 QgeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0V8qUWOVIrI3Js5EoyIQ5Fjr7q/AITDquKkhEeK6LrQ=; b=loUu5vXz0GcaaYoyD7mW890+KVhA+fmbh9fUoF96xb/61LTU1GRdLn7gcGuOUZGvqt AiwI2iHZrhNozR2ijGiH2rc7SeGM1dOS6YAMfAjtWVrdl2r2ryV13tEcbIVXYlh7tINt 82axMa/ZYXyKiL9cG2jQ6wDzZtqfftkhQmcx/+SHsW3F9tWl2/oCRBTXEo75IZn+37Ls AwXbcqptgKBHbVd0OZfG2gQ34rdurmtFq5uTkZWwxfdKQOgAApxL2E/Ts8vLScBzaEOa fiLLYrRvykEzhMAP+nsbDx5Q6dLNz1RTThhxUYlczaA1zr9i2gBtyiEg/vyJlLhbC7gj fSeg== X-Gm-Message-State: AN3rC/7ngOd9NPsWNcvBAW5Ndl22b+VtqDzOTMzYLssMCfHcln/RoN5c K7ojLbLBMEXMVoxCjDGR3r6GBpAfPg== X-Received: by 10.31.141.81 with SMTP id p78mr3566587vkd.18.1493065637343; Mon, 24 Apr 2017 13:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.100 with HTTP; Mon, 24 Apr 2017 13:26:56 -0700 (PDT) In-Reply-To: References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> From: Bernard Aboba Date: Mon, 24 Apr 2017 13:26:56 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Adam Roach , perc@ietf.org Content-Type: multipart/alternative; boundary=001a11425f48f0b6ac054def6ef9 Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 20:27:21 -0000 --001a11425f48f0b6ac054def6ef9 Content-Type: text/plain; charset=UTF-8 Sergio said: "I am not aware of a single SFU that handles SSRC collision that, they all overwrite the SSRC to avoid it." [BA] I am also not aware of an SFU that does selective dropping that is designed as an RTP translator. While in theory it may be possible to design such an SFU, such a design would not fit naturally into any of the RTP topologies described in RFC 7667, which creates considerable complexity. An SFU needs to rewrite sequence numbers and control the contents of the RTCP SRs sent to the endpoints or else the endpoints will think that the packets dropped by the SFU represent gaps that need to be repaired. An SFU also needs to support congestion control and HBH repair, which means that it needs to read the contents of RTCP SRs, RRs, congestion control and feedback messages sent by the endpoints, apply RTX/FEC to fill in gaps, as well as originating congestion control and feedback messages (as well as RTX/FEC). Trying to do these things while maintaining the illusion that the SFU is functioning as an RTP translator requires the SFU to forward some RTCP packets (e.g. BYE, SDES), while modifying the contents of other RTCP packets (SRs, RRs) to present a consistent view to endpoints, and acting upon and originating still other RTCP packets (e.g. feedback messages) with the SSRCs of other endpoints. It's easy to see why developers would choose to avoid this complexity. On Mon, Apr 24, 2017 at 12:42 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 24/04/2017 18:32, Adam Roach wrote: > >> On 4/24/17 05:46, Sergio Garcia Murillo wrote: >> >>> It is unlikely, but possible that two different peers use the same SSRC >>> when sending data to the SFU. The SFU will protect against this HBH ssrc >>> collision by re-writing the ssrcs to all the participants. >>> >> >> >> The issue of SSRC collision detection and resolution is covered at length >> and with normative language in > fc3550#section-8.2>. The entities involved in this process are >> exclusively media sources, not media intermediaries. >> > > I am not aware of a single SFU that handles SSRC collision that, they all > overwrite the SSRC to avoid it. The E2E SSRC collision will happen with the > SSRC values of the OHB when doing the inner crypto, so RTP mechanism don't > apply. > > Best regards > Sergio > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a11425f48f0b6ac054def6ef9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"I am not aware of a single SFU that handles SSRC collisi= on that, they all overwrite the SSRC to avoid it."
[BA] I am also not aware of an SFU that does selective droppin= g that is designed as an RTP translator. =C2=A0 While in theory it may be p= ossible to design such an SFU, such a design would not fit naturally into a= ny of the RTP topologies described in RFC 7667, which creates considerable = complexity.=C2=A0

An SFU needs to rewrite sequence= numbers and control the contents of the RTCP SRs sent to the endpoints or = else the endpoints will think that the packets dropped by the SFU represent= gaps that need to be repaired.=C2=A0

An SFU also = needs to support congestion control and HBH repair, which means that it nee= ds to read the contents of RTCP SRs, RRs, congestion control and feedback m= essages sent by the endpoints, apply RTX/FEC to fill in gaps, as well as or= iginating congestion control and feedback messages (as well as RTX/FEC). = =C2=A0

Trying to do these things while maintaining= the illusion that the SFU is functioning as an RTP translator requires the= SFU to forward some RTCP packets (e.g. BYE, SDES), while modifying the con= tents of other RTCP packets (SRs, RRs) to present a consistent view to endp= oints, and acting upon and originating still other RTCP packets (e.g. feedb= ack messages) with the SSRCs of other endpoints.

I= t's easy to see why developers would choose to avoid this complexity.






On Mon,= Apr 24, 2017 at 12:42 PM, Sergio Garcia Murillo <sergio.gar= cia.murillo@gmail.com> wrote:
On 24/04/2017 18:32, Adam Roach wrote:
On 4/24/17 05:46, Sergio Garcia Murillo wrote:
It is unlikely, but possible that two different peers use the same SSRC whe= n sending data to the SFU. The SFU will protect against this HBH ssrc colli= sion by re-writing the ssrcs to all the participants.


The issue of SSRC collision detection and resolution is covered at length a= nd with normative language in <https://tools.ietf.= org/html/rfc3550#section-8.2>. The entities involved in this pr= ocess are exclusively media sources, not media intermediaries.

I am not aware of a single SFU that handles SSRC collision that, they all o= verwrite the SSRC to avoid it. The E2E SSRC collision will happen with the = SSRC values of the OHB when doing the inner crypto, so RTP mechanism don= 9;t apply.

Best regards
Sergio


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

--001a11425f48f0b6ac054def6ef9-- From nobody Mon Apr 24 13:38:06 2017 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 CAEC51200F1 for ; Mon, 24 Apr 2017 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive.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 YFstUW74_1qQ for ; Mon, 24 Apr 2017 13:38:03 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 2840012422F for ; Mon, 24 Apr 2017 13:38:03 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id y63so99057074qkd.1 for ; Mon, 24 Apr 2017 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=psOewoSuPWolqULzTHfIzSjzBRIzwVI7enw9r+2EQMw=; b=EhZP/uKvmSJwkNXG1X2+S1CHYEK92+qtu33QNPIj25/Ex/nbbqwdFN/JAFReEqKDuc DkUNEfkZLp9PjPUTBQQZej47Y4QcVqOTmZWwud+73P4KSpCrMvJRBgeeCPudoTJ6mTEj iZGarxvKlBeCbTDXNBTo1OGQVl1xOBuCOJL9fxwrMf4SaGId2CgGCmAhn7YhgurqBeuB 6Xuj2UbEheqmwUmooPIcun7J1HUpR1Q4EZQGgd0n4VUub8pfuNYNrYRA4/SMPSG4Mz+1 FjzTHTL4qldSOkro6A2254q5jSrvB9fyhNfmEM6HgjuPghpyeS8XGS+8N6SCP+ov9anO 5wDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=psOewoSuPWolqULzTHfIzSjzBRIzwVI7enw9r+2EQMw=; b=PZj7CitQhAZec+/wYiP5Voz65iDWuZFKa8tCpbV1fkXPA9XDqryu1wzg6tlCqYWQz6 QX0+2F9sNsUBbHCCjdqm6uOdRRAhz+3+s8n8tlfQ5MdnDN84ZdY9YdBxJCjH8otJUDX5 Je48pw/mllOQYbmH8kLjS1L4elXkkrkWkb3wW+mGt9Jp4ARbkrCHTx+WyxNUwlCCyqrZ aWNroWyE1EdtKHl9LtqCxSMrsCCT13Vryxgl+ExvbojNK4Yo5JJwxIWLOY0c8yC1U0xn 7AH6hYqfrOymq2vJuBvbBpXFmpJcmuQTm2b/KjvQayfHpOZWTaBrj9jinMTYIlAbuHuV JMjA== X-Gm-Message-State: AN3rC/47aVJy5FNyre/vX0+gj6ILOZL2FZFgtIGAmnhN9KEhn0QMNG6h 3670s4KvmHwzk9Nplz/jthXfW02w51cSQF2THX5GA0KEIiylN/0T/xrX00sb/iAswJsCfJPrRMu +NYIiq1u8jFAqe228Xz8zUK/AXiieK57LytP7Y85hLD8F X-Received: by 10.55.25.72 with SMTP id k69mr21047719qkh.276.1493066282081; Mon, 24 Apr 2017 13:38:02 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:4432:ab4f:72a7:1b69]) by smtp.gmail.com with ESMTPSA id s76sm10094786qka.34.2017.04.24.13.38.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 13:38:01 -0700 (PDT) To: Sergio Garcia Murillo , Adam Roach , perc@ietf.org References: <2d0e0ed9-14b4-bd02-5ed2-48e519136f99@gmail.com> From: Simon Perreault Message-ID: <479b310b-2b3e-38df-0044-cb331572f10d@jive.com> Date: Mon, 24 Apr 2017 16:39:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] Double encryption - E2E SSRC collision on inner crypto X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 20:38:05 -0000 Le 2017-04-24 15:42, Sergio Garcia Murillo a crit : > On 24/04/2017 18:32, Adam Roach wrote: >> On 4/24/17 05:46, Sergio Garcia Murillo wrote: >>> It is unlikely, but possible that two different peers use the same >>> SSRC when sending data to the SFU. The SFU will protect against this >>> HBH ssrc collision by re-writing the ssrcs to all the participants. >> >> The issue of SSRC collision detection and resolution is covered at >> length and with normative language in >> . The entities >> involved in this process are exclusively media sources, not media >> intermediaries. > > I am not aware of a single SFU that handles SSRC collision that, they > all overwrite the SSRC to avoid it. Mine handles it as described in RFC 3550. Works perfectly. In production with lots of traffic. -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Mon Apr 24 13:57:45 2017 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 2CC401201F8 for ; Mon, 24 Apr 2017 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QiIrvS4ve2j for ; Mon, 24 Apr 2017 13:57:37 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B851287A3 for ; Mon, 24 Apr 2017 13:57:36 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id a103so202138068ioj.1 for ; Mon, 24 Apr 2017 13:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0zBzzLIQ/fGKruSaCOIuOhfaXIYiJs+dwck+upFw25c=; b=RYoJgnwkNRtFdC0G7T0VUonfQM6RvCkzODS2idWYK7crC6Isna9ppo294LivTR2XAP zSuorHe6heaVIU7c9Xs4BHUe4+/BUt1zIM+Jm8JEYwzfkZ6A5NWH2nxRuK6e3xr0HRB0 wdyjzHwrU2NfXhgK5VU0w374tZ91cGAnOYGoI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0zBzzLIQ/fGKruSaCOIuOhfaXIYiJs+dwck+upFw25c=; b=oYJ/XK+3cGlIcB+jL98fF0lNekGdMOXGmYN3K/3W2Xl3BHKn0gv+C7bUTFPPTUiXpz I+oMP8aRRJpeMJbK6w2w5Qu3OTJXn/xbot9zVFOMmHED94uSXGXnVR8GPLagObfG5hDh ykkPd4zKRimjaWKygQ5g8BZsc6SYG8rvtLBZsx9uXHivKmSXLcTuIWx/Nq7NCTyniYH/ wdjPjiBLoPyHdHbd3paGAoagQdMdPpvkkqqmZ3BQbjLsEqRvRxqjSYEUUHMo3xsfPUTG yQ485dWYXl3FbkUk5ATXO4+BMxoN7Sr8OFheREEkhF5Gj0sgDdcpWR86jfwbVhI1zGd/ 0MPg== X-Gm-Message-State: AN3rC/5K3gsBLOl1X6VGfYTYVVRvVhJ6rWTrkna9mQqXtAOsPTob0sap ygMq0MuhuJvM9a8D X-Received: by 10.107.9.231 with SMTP id 100mr8791779ioj.90.1493067455862; Mon, 24 Apr 2017 13:57:35 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:3122:e88f:1459:8313? ([2620:101:80fc:224:3122:e88f:1459:8313]) by smtp.gmail.com with ESMTPSA id y7sm294584itc.27.2017.04.24.13.57.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 13:57:34 -0700 (PDT) From: Nils Ohlmeier Message-Id: <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_771AF090-4262-40C1-B05B-0105D67BE5B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Apr 2017 13:57:30 -0700 In-Reply-To: Cc: Richard Barnes , Jonathan Lennox , "perc@ietf.org" To: Sergio Garcia Murillo References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 20:57:39 -0000 --Apple-Mail=_771AF090-4262-40C1-B05B-0105D67BE5B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_FFFEB3DB-C1B6-47EE-8714-4086284FDFD0" --Apple-Mail=_FFFEB3DB-C1B6-47EE-8714-4086284FDFD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 24, 2017, at 08:57, Sergio Garcia Murillo = wrote: >=20 > RTP header extensions are negotiated on the SDP O/A, so not all = endpoints may support same header extension, and even if they support = same set of extensions, they may be negotiated with different ids. So it = is impossible to support RTP header extensions E2E except in the = scenario in which all endpoints support same subset of extensions and = happens to be negotiated with same id. The topic of header extensions has been discussed in the past at the = first perc interim meeting on 2016-01-11. I suggest reading the meeting = minutes and materials from that meeting: = https://datatracker.ietf.org/group/perc/meetings/ = It appears at the time discussion on RTCP had not concluded yet. But I = don=E2=80=99t think that the conclusion of doing RTCP hop-by-hop only = changes substantially the arguments to allow end-to-end header = extensions. I assume nobody disagrees that negotiating end-to-end header extension = is not easy. But it is purely a signaling problem. I don=E2=80=99t see a = technical reason why the media plane should dis-allowed it. As it is a signaling issue it also means that every PERC conferencing = solution is free to remove end-to-end header extension from the = signaling if it wants to make it=E2=80=99s life easier. Best Nils Ohlmeier --Apple-Mail=_FFFEB3DB-C1B6-47EE-8714-4086284FDFD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 24, 2017, at 08:57, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

RTP header extensions are negotiated on the SDP O/A, so not all endpoints may support same header extension, and even if they support same set of extensions, they may be negotiated with different ids. So it is impossible to support RTP header extensions E2E except in the scenario in which all endpoints support same subset of extensions and happens to be negotiated with same id.

The topic = of header extensions has been discussed in the past at the first perc = interim meeting on 2016-01-11. I suggest reading the meeting minutes and = materials from that meeting: https://datatracker.ietf.org/group/perc/meetings/
It appears at the time discussion on RTCP had not concluded yet. But I = don=E2=80=99t think that the conclusion of doing RTCP hop-by-hop only = changes substantially the arguments to allow end-to-end header = extensions.

I assume nobody = disagrees that negotiating end-to-end header extension is not easy. But = it is purely a signaling problem. I don=E2=80=99t see a technical reason = why the media plane should dis-allowed it.
As it is a = signaling issue it also means that every PERC conferencing solution is = free to remove end-to-end header extension from the signaling if it = wants to make it=E2=80=99s life easier.

Best
  Nils Ohlmeier

= --Apple-Mail=_FFFEB3DB-C1B6-47EE-8714-4086284FDFD0-- --Apple-Mail=_771AF090-4262-40C1-B05B-0105D67BE5B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/ma7AAoJEJ3NnGfOORkk5gUQALRXR0yLPuBwppd4Ho3L/aL9 mZN/2r7wnJyScj8VIbx3T12tBkfQaTc+7dECN36W/bd3xd2yQD7zYOEZOu2pWxDQ vJZTNUULqsPmSAwZbezQ1GlOCM3WkwGb5sfl5Wte0ZHY2hynn4U+qHQx4yiafTED gw8NRigtFTQQIrJ5r7R1RrxLLZN71MQ0/qpoyExVJdr35HvRvB2YzwS0tfBE30iH l1nELt2UJZewUSESXGJZ54/bNDyE1UpDiI/p+aBSy2LYWBwEwvqTXTBROmC5HaV0 6agM+5YNoZvn4ray2nquiMUgDGxDbF7zkLyWGHDMfwLgCE7LA5866HQZhnyuBMNL HffWP38csv0nV7VNqhJiwozTsJDlFfSSEtfC3UBY32E6dP1dVd6jHlzmZHx1xZuQ 4+dvNBOKpeyB6KfRGPhdlVDxLWgDPUgzh+5yvpvUui+pq2MkfSrG9LN8ckLAQ52H sNUM8D6bindCo2skn97SCVvJsC0tP5nlLADj5Y8G0/9q7XTm9EJzAqBVpF9CogaH SZdO9D1Scx352spxq3Wy/zpESz6qnwpbEM7HTBgBAcZBI4ZDGs3GwlaVmFkUZ9t/ lIWM8q9e66gCPS2XV91hDFQL4kDW7Xt4CY207IbenqSbyIvgtz+eqIKHn9MBgNJg bsLIFZghgoCwoDH0D0/y =bqZW -----END PGP SIGNATURE----- --Apple-Mail=_771AF090-4262-40C1-B05B-0105D67BE5B6-- From nobody Mon Apr 24 14:30:38 2017 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 2D92F13193D for ; Mon, 24 Apr 2017 14:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILV-zPEnrJDp for ; Mon, 24 Apr 2017 14:30:34 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 DEA861294A6 for ; Mon, 24 Apr 2017 14:30:31 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id z52so57381924wrc.2 for ; Mon, 24 Apr 2017 14:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Xf0AwA2b63pGAEQvE0++Ccfu7mtBD6fkHXfSM/U/oPM=; b=eSNbx7g3X4ZxlZSFDeIZyujpIyehhJqtVt/iGYaKNq+MhjxKhgNPSywaEfGoCgntZ3 NzAJ3KjRyIc1vMktmTXDSum+HF73FWSZEYNCwDWy73DVaI+Co8QypJD9/zAfoZ848kED 8x5MUI096eddOd9OyAVSbXkpOi8gAhWXCyIkZvb2mcNelM5yxucu94XtjkYMY7LJVD7A JCbUc846lvj2Y70v66lVYsw9f7EEfaGv0D5xqBgRwXmp1sZU1SoQoPOJ0/qGTXRZvRzE QqAnczgxLyTPC+YmC13revzxit+Vgov302NpfVJ+Pnn7QNoSj2w+0jx64LppBSQQ9yTG ANQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Xf0AwA2b63pGAEQvE0++Ccfu7mtBD6fkHXfSM/U/oPM=; b=jS4pRLGVh1Rs8Bxtywgbsgbf0EerzvoDD6YyB228dnyO2P/Z0aY/fEpKbRu+kn53Pb rXUwxJHUBZSTFX+9gyQZphvNnzEkF8+GqJvszCZTRlpFeJIK4JLmXbu3t+wxL8AAbgkt +PUnzwK8bG4CFYzCtRIINy5kpyKN3GyJIT4RFEYvoX2fad3x0PXU7gnGjeakkOnuvSWI 69H6+Zp1SnQR5n8/OoqfslkGK90V1LeKPaQyh70aWEUYB2CjQ1Kh8bG9v7w8iDbiiqsZ r1s6m7EPHJ5hxHnWrpbYbAaB+pS9CJj5SDoA8xJ9aUi9bDKgq6QPj1LLPv9rZGXyGW+s bhdQ== X-Gm-Message-State: AN3rC/4e/KKpaMVmaHXhvZkD4uryS4hlHKeWHTgW3CnbsYzTYvp2d800 1lyhs9XF1VFzKtZH0s0= X-Received: by 10.223.143.13 with SMTP id p13mr7412492wrb.3.1493069430239; Mon, 24 Apr 2017 14:30:30 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id f189sm343113wmf.34.2017.04.24.14.30.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 14:30:28 -0700 (PDT) To: Nils Ohlmeier References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> Cc: Richard Barnes , Jonathan Lennox , "perc@ietf.org" From: Sergio Garcia Murillo Message-ID: Date: Mon, 24 Apr 2017 23:30:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> Content-Type: multipart/alternative; boundary="------------C62E4F1AF784D0674DE05BB4" Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:30:36 -0000 This is a multi-part message in MIME format. --------------C62E4F1AF784D0674DE05BB4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 24/04/2017 22:57, Nils Ohlmeier wrote: > >> On Apr 24, 2017, at 08:57, Sergio Garcia Murillo >> > > wrote: >> >> RTP header extensions are negotiated on the SDP O/A, so not all >> endpoints may support same header extension, and even if they support >> same set of extensions, they may be negotiated with different ids. So >> it is impossible to support RTP header extensions E2E except in the >> scenario in which all endpoints support same subset of extensions and >> happens to be negotiated with same id. > > The topic of header extensions has been discussed in the past at the > first perc interim meeting on 2016-01-11. I suggest reading the > meeting minutes and materials from that meeting: > https://datatracker.ietf.org/group/perc/meetings/ > It appears at the time discussion on RTCP had not concluded yet. But I > don’t think that the conclusion of doing RTCP hop-by-hop only changes > substantially the arguments to allow end-to-end header extensions. > > I assume nobody disagrees that negotiating end-to-end header extension > is not easy. But it is purely a signaling problem. I don’t see a > technical reason why the media plane should dis-allowed it. > As it is a signaling issue it also means that every PERC conferencing > solution is free to remove end-to-end header extension from the > signaling if it wants to make it’s life easier. > Let me recap: * We don't have an use case for E2E rtp header extensions * We don't provide a solution for signaling E2E rtp header extensions vs HBH ones * We don't provide a solution on how to successfully signal/handling different subsets of rtp header extensions and unify the negotiated ids * We introduce a new concept of rtp header ordering that is not defined anywhere and is not supported by anyone currently making implementation much more difficult * We don't expect anyone implementing it Really, I don't see any reason why we have to keep support for E2E rtp header extensions. Regards Sergio --------------C62E4F1AF784D0674DE05BB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 24/04/2017 22:57, Nils Ohlmeier wrote:

On Apr 24, 2017, at 08:57, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

RTP header extensions are negotiated on the SDP O/A, so not all endpoints may support same header extension, and even if they support same set of extensions, they may be negotiated with different ids. So it is impossible to support RTP header extensions E2E except in the scenario in which all endpoints support same subset of extensions and happens to be negotiated with same id.

The topic of header extensions has been discussed in the past at the first perc interim meeting on 2016-01-11. I suggest reading the meeting minutes and materials from that meeting: https://datatracker.ietf.org/group/perc/meetings/
It appears at the time discussion on RTCP had not concluded yet. But I don’t think that the conclusion of doing RTCP hop-by-hop only changes substantially the arguments to allow end-to-end header extensions.

I assume nobody disagrees that negotiating end-to-end header extension is not easy. But it is purely a signaling problem. I don’t see a technical reason why the media plane should dis-allowed it.
As it is a signaling issue it also means that every PERC conferencing solution is free to remove end-to-end header extension from the signaling if it wants to make it’s life easier.


Let me recap:
  • We don't have an use case for E2E rtp header extensions
  • We don't provide a solution for signaling E2E rtp header extensions vs HBH ones
  • We don't provide a solution on how to successfully signal/handling different subsets of rtp header extensions and unify the negotiated ids
  • We introduce a new concept of rtp header ordering that is not defined anywhere and is not supported by anyone currently making implementation much more difficult
  • We don't expect anyone implementing it
Really, I don't see any reason why we have to keep support for E2E rtp header extensions.

Regards
Sergio --------------C62E4F1AF784D0674DE05BB4-- From nobody Tue Apr 25 10:21:10 2017 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 6BA83131701 for ; Tue, 25 Apr 2017 10:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 eKV2G-Eu6ySt for ; Tue, 25 Apr 2017 10:21:01 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 15E3813170D for ; Tue, 25 Apr 2017 10:20:04 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id h123so65295050qke.0 for ; Tue, 25 Apr 2017 10:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0H8j9jOE8XAnGxpZDs+qBmjlvRHNFj1/+EiLyQv7hK0=; b=fxcqI7R6macnbGsseFJxA4VpiogJTjr4mtIA+u9+Whh6SC7ZPoxOUGeeRnB2vphoWy 1gclEtf5sfSKkJcHvI1yj0UuVnuUfe0hF/diX0PbOOqPVeg5JnUEL1UNaCuovad61ltu qYVO2nacA7J05Z/tHqVxdFd1bhgWBTJLCge6pocNRfF4BduWGU26kJ5ANLUDcSPQSBrk EiXp8dAWR92SjBBQEPyKrkJmTEeyeAnDwbe883NzqJRmhnnaPLKt3sWR5jh+RBAVSioS yRos0G2o1iiMHmHnYXegNt/BCHaxAy2NnOmF5sBiNDjrn5JLsA22vzJwgyge+ebYrT1h O8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0H8j9jOE8XAnGxpZDs+qBmjlvRHNFj1/+EiLyQv7hK0=; b=J9o39kxPPIIrE/nNnLLbxQCf2OU37xcLeH2a1BNxWw+gxTaPhSSOv/xInHPk1xIuFG mc763zuaQUHDa96fAxWYuWqAOM1WSO4i285Ih2BwztBDHgwbVWpBOukY48q1hRBfovp3 OoBFaPpVneVT0+WRNk79JTGQJbiO2ut1xnch9LfywY9g7qUeiTb5EEHQacONykLrsaRo UsD6Bcr5CM3AXSIO0b1kBUbMCHx4F86TJqdqpaUfW469/ogxLAJZVyiVAsZ1MZjXndes oe9EOI3POwPj46hgTaxaOvZdvZV0UChCJZMG36Wcn9Scmn+VCYMNf4GXHxdu/R72ynMs s0+Q== X-Gm-Message-State: AN3rC/7WiC8TKmUWv8RuUhDdVRPZFW0ywD500XDsfTSFgHibCGGWhAYt OVYl+TS83AZX6mxeEIawsp+aYpNgbQ== X-Received: by 10.55.98.21 with SMTP id w21mr11365985qkb.118.1493140803205; Tue, 25 Apr 2017 10:20:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.51.162 with HTTP; Tue, 25 Apr 2017 10:20:02 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Tue, 25 Apr 2017 10:20:02 -0700 Message-ID: To: Nils Ohlmeier Cc: perc@ietf.org, Richard Barnes Content-Type: multipart/alternative; boundary=001a11482bc22cc01f054e00ef8e Archived-At: Subject: Re: [Perc] Doodle Poll for Perc Virtual Interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 17:21:03 -0000 --001a11482bc22cc01f054e00ef8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks everyone for participating in the poll. We will be closing the Poll and sending out a final date soon, Cheers Suhas On Mon, Apr 24, 2017 at 11:37 AM, Nils Ohlmeier wrote: > Just a friendly reminder that if you want to participate in the interim > meeting and haven=E2=80=99t entered your availability in the doodle poll,= please to > do so today. > > Thank you > Nils Ohlmeier > > On Apr 18, 2017, at 11:02, Suhas Nandakumar wrote: > > Hello All > > > To carry forward the discussions on RTX/FEC support in the PERC > Context from IETF 98, we have setup the following doodle poll. > > > http://doodle.com/poll/wag852eknq3yidpy > > The meeting will be for 120 mins (2 hours) and will be an online meeting. > > Please complete the poll by 4/24/2017 EOD (PST time) to enable us to setu= p > the official proceedings. > > Cheers > Perc Chairs > > > --001a11482bc22cc01f054e00ef8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks everyone for participating in the poll. We will be = closing the Poll and sending out a final date soon,


=
Cheers
Suhas
On Mon, Apr 24, 2017 at 11:37 AM, Nils Ohlmeier= <nohlmeier@mozilla.com> wrote:
Just a friendly reminder that= if you want to participate in the interim meeting and haven=E2=80=99t ente= red your availability in the doodle poll, please to do so today.

Thank you
=C2=A0 Nils Ohlmeier

On Apr 18, 2017, at 11:02, Suhas Nandakum= ar <suhasietf@g= mail.com> wrote:

Hello All


=C2=A0 =C2=A0 To carry forward the discussions on RTX/FEC support in = the PERC Context from IETF 98, we have setup the following doodle poll.



The meeting will be for 120 mins (2 hour= s) and will be an online meeting.

Please complete = the poll by 4/24/2017 EOD (PST time) to enable us to setup the official pro= ceedings.

Cheers
Perc Chairs
<= br>

--001a11482bc22cc01f054e00ef8e-- From nobody Tue Apr 25 14:19:11 2017 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 49FA2129353 for ; Tue, 25 Apr 2017 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqdaBfZjm5lY for ; Tue, 25 Apr 2017 14:19:08 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5324A1252BA for ; Tue, 25 Apr 2017 14:19:08 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id x188so84421304itb.0 for ; Tue, 25 Apr 2017 14:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GfwoVMzT8VdnaQgzGcs3MmNRb4hlYjmIGOplBHMKQQo=; b=HBcuxBIUAA8ahwrYiggbn151256b6vTTgGJYv09gW3TgdaKOVL0mnRXLLMnA8N+36a uDhDDLkPlFurbBKNQz/2kp9/0vQuXIdzl0G1ZP3cwn6ud0zKVOJs/UsJzEvh48NatUd0 WnRty+t9KfQlti3+yq0iRLO6kXAh1iEXu3Aj8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GfwoVMzT8VdnaQgzGcs3MmNRb4hlYjmIGOplBHMKQQo=; b=gxsGK5q6xpdxqMFWdhhjPDj18XohnqEfgJFmurHifkOTjy8rhP8Nl1gGzbv21Y7OaE h/hoYDJv82CXe7YhvSd7Vi6iCMuHXXh7dDjYeA1LJJDqBoAA482zJUzenwhsg3x3XKXN SqgFYUIquCp+CE1MlxdrhCMnhRLTRl+KFqV24NHKlBWzh1wWNSBO1iCqZt+MBggkmMB1 lzndg40juSXozi86oL+nGHunJt/pxr0WGOW0nfTK3L3EtpHRuLi1Y00KuEWGH39i7hjR 3X4+4IWPRzTOcd5+RmKDT30xK3IFe1nrGjI7nhY8H//GeCZD+bI4kXB2gdL8GC8BtDyd qmYQ== X-Gm-Message-State: AN3rC/5SZ1oqk2jLth2mwvjLrscR2294ykElKvlj5kusE/5gG/08vHO/ 3NTxGzfcbqnIBlO/ X-Received: by 10.36.65.227 with SMTP id b96mr7502647itd.118.1493155147585; Tue, 25 Apr 2017 14:19:07 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:2cbd:c196:e332:6007? ([2620:101:80fc:224:2cbd:c196:e332:6007]) by smtp.gmail.com with ESMTPSA id 18sm571405iom.51.2017.04.25.14.19.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 14:19:06 -0700 (PDT) From: Nils Ohlmeier Message-Id: <7CC5C051-9BF9-4AFB-939B-57B4F955C661@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_554FDFEE-2069-4309-AECE-DBB44655DD8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Apr 2017 14:19:02 -0700 In-Reply-To: Cc: Richard Barnes , Jonathan Lennox , "perc@ietf.org" To: Sergio Garcia Murillo References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:19:10 -0000 --Apple-Mail=_554FDFEE-2069-4309-AECE-DBB44655DD8C Content-Type: multipart/alternative; boundary="Apple-Mail=_22FCB754-747D-4B1B-A718-7B30BD3D7957" --Apple-Mail=_22FCB754-747D-4B1B-A718-7B30BD3D7957 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 24, 2017, at 14:30, Sergio Garcia Murillo = wrote: >=20 > Let me recap: > We don't have an use case for E2E rtp header extensions There are things like audio level and video orientation, which make more = sense to be passed along by the MDD, rather then re-write them. I guess = in worst case a malicious MDD which re-writes all extension headers = could always mark my audio packet with a very low level, so that I never = become the active speaker. The one use case I have come up with so far, which hasn=E2=80=99t been = propose AFAIK, would be an extension to prove the identity of the sender = for each RTP packet send with asymmetric keys. > We don't provide a solution for signaling E2E rtp header extensions vs = HBH ones So far I always thought the group would =E2=80=9Csimply=E2=80=9D come up = with a fixed list of header extensions which are E2E, for example = orientation and audio level. Admitably that might not be a very good = solution. > We don't provide a solution on how to successfully signal/handling = different subsets of rtp header extensions and unify the negotiated ids To me this is signaling part I mentioned before. Effectively you have to = generate new offers from the MDD to align all participants on the IDs. > We introduce a new concept of rtp header ordering that is not defined = anywhere and is not supported by anyone currently making implementation = much more difficult Indeed the fact that suddenly the order of negotiated header extensions = matters changes probably how most existing implementations add = extensions to the RTP packets. Obviously it would be ideal if we can = propose new standard which require no or little changes. This appears to = be not the case here unfortunately. Best Nils > We don't expect anyone implementing it > Really, I don't see any reason why we have to keep support for E2E rtp = header extensions. >=20 > Regards > Sergio --Apple-Mail=_22FCB754-747D-4B1B-A718-7B30BD3D7957 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 24, 2017, at 14:30, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

Let me recap:
  • We don't have an use case for E2E rtp header = extensions
There are things like audio = level and video orientation, which make more sense to be passed along by = the MDD, rather then re-write them. I guess in worst case a malicious = MDD which re-writes all extension headers could always mark my audio = packet with a very low level, so that I never become the active = speaker.
The one use case I have come up with so far, which = hasn=E2=80=99t been propose AFAIK, would be an extension to prove the = identity of the sender for each RTP packet send with asymmetric = keys.
  • We don't provide a solution for signaling E2E rtp = header extensions vs HBH ones
So far I always thought = the group would =E2=80=9Csimply=E2=80=9D come up with a fixed list of = header extensions which are E2E, for example orientation and audio = level. Admitably that might not be a very good solution.
  • We don't provide a solution on how to successfully signal/handling different subsets of rtp header extensions and unify the negotiated ids
To me = this is signaling part I mentioned before. Effectively you have to = generate new offers from the MDD to align all participants on the = IDs.
  • We introduce a new concept of rtp header = ordering that is not defined anywhere and is not supported by anyone currently making implementation much more = difficult
Indeed the fact that = suddenly the order of negotiated header extensions matters changes = probably how most existing implementations add extensions to the RTP = packets. Obviously it would be ideal if we can propose new standard = which require no or little changes. This appears to be not the case here = unfortunately.

Best
  = Nils
  • We don't expect anyone implementing it
Really, I don't see any reason why we have to keep support for E2E rtp header extensions.

Regards
Sergio

= --Apple-Mail=_22FCB754-747D-4B1B-A718-7B30BD3D7957-- --Apple-Mail=_554FDFEE-2069-4309-AECE-DBB44655DD8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY/71HAAoJEJ3NnGfOORkk/xgP/i29MHqtj8HwkWrP4BJMcBUo wx/t64rswkXi5UVf+Q+VoN0U3nWz6WfB17TMsUqBPlsGrg1V5kaGh5gwx8rFNKx2 Vs3Q00xTI1sE2kDdH6L2yln2ghTcjxlMCOUP4g3ovwcTb2TGkFvxNZucTxFKnfdF /29nJuTNL6P78uxwQJk68KK+r17f4KRcqu5kEgBjQ9o3ukBDsJ4GfP+1pWR6fPfm XFplXXpjlt23lC502Dhoswru7BFhPoFbz9DZHFcZHbA83tlHFIzxJ5S0KyaYcUhu tvhHdJzz8irCHyAcdNCkuLoP52foLxmwnCHVLRiwiW26Ttba7Fsv/fW2eL75jHhX WK4C72eCcv+u2PuUQtoOZ9pK7jKftDgPpesc7Py+K7FRa7b25q+G0jSydqirBeSN buUu5syXEvpN/PGnK/gtPgRPnoXpkbmV5MJxXeKb2VRAlIh9cqJiZZGi4XrLbVBr gp5MMz2Ycig59UQ9v6KWjLPMC8gyRAoimUL8HEFize52Yp1CjzkEoPrP1wqkQrRy 714vFvaW7ozNhQsEyoZyKgLD0EPu4YSifmI0uE4F6W8HiJcJspBH4xrioFsCrbui h3sqMqK2BWpqrjvhgfDFqafHYkcpgR3J5gvLUCceCo5+EEDJ9wtBs+BPyzinArHR jpZ6G9DzLI/GENTh7lJY =jr1+ -----END PGP SIGNATURE----- --Apple-Mail=_554FDFEE-2069-4309-AECE-DBB44655DD8C-- From nobody Tue Apr 25 14:28:26 2017 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 30CF51200F1 for ; Tue, 25 Apr 2017 14:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 WIE-hVp8_tKy for ; Tue, 25 Apr 2017 14:28:23 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 CB058129436 for ; Tue, 25 Apr 2017 14:28:20 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id x184so188817636oia.1 for ; Tue, 25 Apr 2017 14:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3YbVDosUB9OuR3fgbXT7Ek1q8iS/C96Sw+d/VLv23kY=; b=TGz9brH+1gQfJ6bReASHFPN2HQDjsWPydi4b5LGdb8O/fc6REv1N3xKQQda9ynONUw GJ+Yd/mb3w21XmuLhDIuFi5txgg4JcDpqgrFP0s4gUoR0DsMaon1e2HtE3hPW20qrWXi 64AEBgQlYT9xbuHm/emFm787S8Unoq+LvzE8ExthVDSjYppjGaRmz5ajT+043uQJ8zcL LgjsN9fg5scsz6V4PeXslnGwPHws0GR+DZAOhm0mJhvsDEwiaJ8TnJj3bpoRBtoEAvZ/ yDgPNE3IQshiUdEGdQi3wFjjSan7PXCGKefj8c4vUqCWS7rzCvubER1xyc4SRsuQPOEJ QWfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3YbVDosUB9OuR3fgbXT7Ek1q8iS/C96Sw+d/VLv23kY=; b=rgCGeWJONKnP6JIewTduGpSfzfs8vQUEBiKgIWZIGcS4NCMGNHq6hpRBBv6I1suzyv rnn9qxpbrDsfaIBDF8kZ/5jo/ca3FSgVIstrIgRborYJjLhsmSPFTaLha1hqeapzAdT1 giXJKo+sOi25eScQ6F0Wz6Lg8asCzY7r45h9nv3sF4VKJQ7kZiUHrDi397+CWUEFJ4hj v60vPT2QlIl6nxCe88Iq6N3JBxKVy0GXP9YVsXcoa+rZI6FFQtcBAWe9nNcI1qH5g6ln nisfSgZJvTiW6C6STQAeN6hTYgLK2x3Kt+ySpdYgv53J51G5xjKSx9N6G+7X5p4QNfAl +LVA== X-Gm-Message-State: AN3rC/46b5DMNhHYYffTkdeCr1+bjmzETGbuZ/hxUQjGW9xn9hMr2tq0 vvQwIShicmC8Irw9d9E= X-Received: by 10.202.212.10 with SMTP id l10mr19829827oig.71.1493155699710; Tue, 25 Apr 2017 14:28:19 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id s11sm1785987otd.48.2017.04.25.14.28.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 14:28:18 -0700 (PDT) To: Nils Ohlmeier , Sergio Garcia Murillo References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> <7CC5C051-9BF9-4AFB-939B-57B4F955C661@mozilla.com> Cc: Richard Barnes , Jonathan Lennox , "perc@ietf.org" From: Emil Ivov Message-ID: <29c961e0-0fd5-0709-f6c2-42cfa0bba672@jitsi.org> Date: Tue, 25 Apr 2017 16:28:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7CC5C051-9BF9-4AFB-939B-57B4F955C661@mozilla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:28:25 -0000 On 4/25/17 4:19 PM, Nils Ohlmeier wrote: > >> On Apr 24, 2017, at 14:30, Sergio Garcia Murillo >> > > wrote: >> >> Let me recap: >> >> * We don't have an use case for E2E rtp header extensions > There are things like audio level and video orientation, which make more > sense to be passed along by the MDD, rather then re-write them. This is not really relevant. MDDs do that today without E2E encryption and they can continue doing it in the future. I think the point that Sergio is making is more about whether or not we have a case where not having hdr extensions could somehow compromise a call in a way that isn't possible otherwise. Personally I don't see that. > I guess > in worst case a malicious MDD which re-writes all extension headers > could always mark my audio packet with a very low level, so that I never > become the active speaker. And the only thing this would achieve is to make you think that your application is buggy. MDDs has many otherwise to achieve that. > The one use case I have come up with so far, which hasnt been propose > AFAIK, would be an extension to prove the identity of the sender for > each RTP packet send with asymmetric keys. Lost you. >> >> * We don't provide a solution for signaling E2E rtp header >> extensions vs HBH ones > So far I always thought the group would simply come up with a fixed > list of header extensions which are E2E, for example orientation and > audio level. Admitably that might not be a very good solution. So we are updating 5285 again? Or offer/answer? I didn't see this in the charter and it seems rather overly ambitious to me. The only solution I can think of is for us to dissociate ourselves from SDP here (like we've done for ICE) and say something along the lines of: hey we don't currently have an IETF compliant mechanism to let you negotiate this, but if you have your own, this is how the transport would work. Emil >> * We don't provide a solution on how to successfully signal/handling >> different subsets of rtp header extensions and unify the >> negotiated ids > To me this is signaling part I mentioned before. Effectively you have to > generate new offers from the MDD to align all participants on the IDs. >> >> * We introduce a new concept of rtp header ordering that is not >> defined anywhere and is not supported by anyone currently making >> implementation much more difficult > Indeed the fact that suddenly the order of negotiated header extensions > matters changes probably how most existing implementations add > extensions to the RTP packets. Obviously it would be ideal if we can > propose new standard which require no or little changes. This appears to > be not the case here unfortunately. > > Best > Nils >> >> * We don't expect anyone implementing it >> >> Really, I don't see any reason why we have to keep support for E2E rtp >> header extensions. >> >> Regards >> Sergio > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > -- https://jitsi.org From nobody Tue Apr 25 16:25:45 2017 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 DADBC12785F for ; Tue, 25 Apr 2017 16:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1Dov7F0tbXnR for ; Tue, 25 Apr 2017 16:25:42 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 E6C8812EB61 for ; Tue, 25 Apr 2017 16:25:41 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w64so35632559wma.0 for ; Tue, 25 Apr 2017 16:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=8vpDdf8GDZY4InTCo+OOsPtf5HIewFgkTaQ0GdetW5s=; b=SdWvr2avQLRp4JR2LRDqyclobJqgBOv9Q82qdsZICqNA9SsFFVTxoXnl/qjg0G1fmb ANByHK6ctoCmvXZJlWkLSazODyEQxSfN1noMnZTLrD6a7N+OAsbo3JW9D1YrhAhsAsht V/ecOVu4WHeXkT0WYJv+KaHo9PiMmI9PEGwmUgqBbfkS3O29jdSzY1CCjHILTVcrC6Oo AX5OlL5l1aXE7VSOkhX3GSDCnGdIIXTm9z0gIFuBdwx44325/bhyQDcphbeWtqhTOHri NrUWqeDS9Y0wybekpPorDkBG7YJUQrg5d7gieOC58UQCscZCY1wRcQiZcp16/GwxTNIM PT6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=8vpDdf8GDZY4InTCo+OOsPtf5HIewFgkTaQ0GdetW5s=; b=lwVMk3HOf3Jm0+hgOTQcSf2gLbRbYPd04nWN1/ZcNpfVPk8LE1rM/s8Z++FJMkBwP3 KOB6VnhdqseY9aW+mP7QYC9KCwQf9flLNekB+H9qjZVbSfg1mSqFrj9FzXUvsD3LMvXg rjgqOt8KTKEzOo+BPbgIHcgLqndrR6KUAYjwRt5QQvqOUReKbWSbK2PS0ac4gZ/+uiT0 ObnojU23WmgicTMkHex2lkf4YCgYntaPJd/+CtFoUclL/06hzj8Sj1cbHbEKLbyJnOZR SCVALZS5zpjzHLdoIeO5uJsY4XrbG07ht6B/lJ5u4PlRs7TImsABzuQ6efR5Vyww7fY0 ISbQ== X-Gm-Message-State: AN3rC/69IFqHfyiykxIiZynOQ3w6zG/np0DS5HzeFMsvFTpgVkQHEyNA y51vHXAtLiDFVQ== X-Received: by 10.28.169.15 with SMTP id s15mr3421981wme.2.1493162740355; Tue, 25 Apr 2017 16:25:40 -0700 (PDT) Received: from [192.168.0.196] ([77.225.146.169]) by smtp.googlemail.com with ESMTPSA id q140sm5514581wmb.14.2017.04.25.16.25.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 16:25:39 -0700 (PDT) To: Nils Ohlmeier References: <49c7de34-8bc6-bb7d-4524-0af26089eecb@gmail.com> <1CF6F66C-939F-484D-8C53-46ACB8CA69BE@vidyo.com> <27ca2993-5c66-8388-7187-b47ed8ae1340@gmail.com> <8FD07F5D-CD52-445B-AF75-BA1696F3A151@mozilla.com> <7CC5C051-9BF9-4AFB-939B-57B4F955C661@mozilla.com> Cc: Richard Barnes , Jonathan Lennox , "perc@ietf.org" From: Sergio Garcia Murillo Message-ID: Date: Wed, 26 Apr 2017 01:25:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7CC5C051-9BF9-4AFB-939B-57B4F955C661@mozilla.com> Content-Type: multipart/alternative; boundary="------------CCDCEC4A8EC57AA9C18D1522" Archived-At: Subject: Re: [Perc] Drop support for E2E RTP header extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:25:44 -0000 This is a multi-part message in MIME format. --------------CCDCEC4A8EC57AA9C18D1522 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 25/04/2017 23:19, Nils Ohlmeier wrote: > >> On Apr 24, 2017, at 14:30, Sergio Garcia Murillo >> > > wrote: >> >> Let me recap: >> >> * We don't have an use case for E2E rtp header extensions >> > There are things like audio level and video orientation, which make > more sense to be passed along by the MDD, rather then re-write them. I > guess in worst case a malicious MDD which re-writes all extension > headers could always mark my audio packet with a very low level, so > that I never become the active speaker. The extension is named "client to mixer audio level" and it is by definition HBH as it is required by the SFU in order to work properly. There is another *different* extension for "client to mixer audio level" which is also HBH. Video orientation is the only extension that makes sense to be e2e, but i don't think that it justifies all the effort required to implement it, and could be HBH and copied over by the SFU as it is done today. It can also safely disabled with just a little overhead on sender side to rotate the videos in origin. Which I think it is the safest method anyway today as AFAIK firefox doesn't support it yet, so it is better to be disabled. > The one use case I have come up with so far, which hasn’t been propose > AFAIK, would be an extension to prove the identity of the sender for > each RTP packet send with asymmetric keys. I think that we can find much better solutions for that than a new rtp header extension. [...] >> >> * We introduce a new concept of rtp header ordering that is not >> defined anywhere and is not supported by anyone currently making >> implementation much more difficult >> > Indeed the fact that suddenly the order of negotiated header > extensions matters changes probably how most existing implementations > add extensions to the RTP packets. Obviously it would be ideal if we > can propose new standard which require no or little changes. This > appears to be not the case here unfortunately. That is the problem when there is not a use case, that it is not possible to find a solution that fulfills it. Best regards Sergio --------------CCDCEC4A8EC57AA9C18D1522 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 25/04/2017 23:19, Nils Ohlmeier wrote:

On Apr 24, 2017, at 14:30, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

Let me recap:
  • We don't have an use case for E2E rtp header extensions
There are things like audio level and video orientation, which make more sense to be passed along by the MDD, rather then re-write them. I guess in worst case a malicious MDD which re-writes all extension headers could always mark my audio packet with a very low level, so that I never become the active speaker.
The extension is named "client to mixer audio level" and it is by definition HBH as it is required by the SFU in order to work properly. There is another *different* extension for "client to mixer audio level" which is also HBH.

Video orientation is the only extension that makes sense to be e2e, but i don't think that it justifies all the effort required to implement it, and could be HBH and copied over by the SFU as it is done today. It can also safely disabled with just a little overhead on sender side to rotate the videos in origin. Which I think it is the safest method anyway today as AFAIK firefox doesn't support it yet, so it is better to be disabled.

The one use case I have come up with so far, which hasn’t been propose AFAIK, would be an extension to prove the identity of the sender for each RTP packet send with asymmetric keys.

I think that we can find much better solutions for that than a new rtp header extension.

[...]
  • We introduce a new concept of rtp header ordering that is not defined anywhere and is not supported by anyone currently making implementation much more difficult
Indeed the fact that suddenly the order of negotiated header extensions matters changes probably how most existing implementations add extensions to the RTP packets. Obviously it would be ideal if we can propose new standard which require no or little changes. This appears to be not the case here unfortunately.

That is the problem when there is not a use case, that it is not possible to find a solution that fulfills it.

Best regards
Sergio

--------------CCDCEC4A8EC57AA9C18D1522-- From nobody Fri Apr 28 07:19:28 2017 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 D6C9612945B; Fri, 28 Apr 2017 07:19:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149338916682.2915.3552348615106735061@ietfa.amsl.com> Date: Fri, 28 Apr 2017 07:19:26 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-double-04.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 14:19:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : SRTP Double Encryption Procedures Authors : Cullen Jennings Paul E. Jones Adam Roach Filename : draft-ietf-perc-double-04.txt Pages : 14 Date : 2017-04-28 Abstract: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic contexts to provide "hop-by-hop" and "end-to-end" security guarantees. Both the end-to-end and hop-by-hop cryptographic transforms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-double-04 https://datatracker.ietf.org/doc/html/draft-ietf-perc-double-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 07:19:50 2017 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 EDF9312EAA6; Fri, 28 Apr 2017 07:19:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149338917394.2991.8781534581984775359@ietfa.amsl.com> Date: Fri, 28 Apr 2017 07:19:33 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-04.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 14:19:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : Encrypted Key Transport for DTLS and Secure RTP Authors : Cullen Jennings John Mattsson David A. McGrew Dan Wing Filename : draft-ietf-perc-srtp-ekt-diet-04.txt Pages : 23 Date : 2017-04-28 Abstract: Encrypted Key Transport (EKT) is an extension to DTLS and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-04 https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 08:22:26 2017 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 A70C7129C59; Fri, 28 Apr 2017 08:22:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149339294066.2881.14659906740178405707@ietfa.amsl.com> Date: Fri, 28 Apr 2017 08:22:20 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-dtls-tunnel-01.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:22:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange Authors : Paul E. Jones Paul M. Ellenbogen Nils H. Ohlmeier Filename : draft-ietf-perc-dtls-tunnel-01.txt Pages : 16 Date : 2017-04-28 Abstract: This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the media distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the media distributor. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-01 https://datatracker.ietf.org/doc/html/draft-ietf-perc-dtls-tunnel-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-dtls-tunnel-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
>>&= gt;I would expect the MD to just send any incoming RFC 4103 packets to all = other participants in the conference
I was hoping that was sufficient.
<= font face=3D"arial, helvetica, sans-serif">
>>>=C2=A0I'm not sure what might = be most appropriate, but Unicode does define a zero-width space (U+200B).
RTP padding is likely= enough, and if the max characters per packet is small the character count = might already be reasonably masked by the AES block size.
=
The idle is harder to solve (which relat= es to the marker bit use).=C2=A0 That does provide leakage about when peopl= e are talking, and perhaps the length of each remark.

Steve