From nobody Fri Mar 3 16:04:19 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 1750E129A91; Fri, 3 Mar 2017 15:55:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858534109.15846.4251433674375069777.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:41 -0800 Archived-At: Cc: ben@nostrum.com, perc@ietf.org Subject: [Perc] perc - Requested session has been scheduled for IETF 98 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:41 -0000 Dear Suhas Nandakumar, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. perc Session 1 (2:00:00) Wednesday, Morning Session I 0900-1130 Room Name: Montreux 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: acme netvc siprec clue avtext avtcore tls rtcweb sipbrandy Second Priority: tcpinc oauth straw sipcore stir payload xrblock uta mmusic modern saag Third Priority: stox codec dispatch insipid p2psip kitten People who must be present: Ben Campbell Richard Barnes Suhas Nandakumar Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Tue Mar 7 22:10: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 90D9C1293F9 for ; Tue, 7 Mar 2017 22:10:36 -0800 (PST) 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, 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 wWzQgVd0D9UK for ; Tue, 7 Mar 2017 22:10:35 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 91F6E126B6D for ; Tue, 7 Mar 2017 22:10:35 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id v190so10482417pfb.1 for ; Tue, 07 Mar 2017 22:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=dT0Y88OvTTsk2zzGIT8TG84usBSt1bFjBMrafpWZ9xA=; b=awKjdjNOgCZJ8sRfDaR9SzsKzGkrTgw44bRqKppxDcmaZUcOJ1/yFBARjCz1qzpi6z fPkfuHfj+ugYLvuL3PereOnoNxKCwe2xumq7UqAcvnfzUjmEmC/Gfb3Awyc0UJLt9rR3 VE+uUyMN6GY0Ce2oRWsrXAmP6W+zw1m/h4Poc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=dT0Y88OvTTsk2zzGIT8TG84usBSt1bFjBMrafpWZ9xA=; b=IdFAX5SurCW2ZQlhgMVi0yFtzac3BXphg4BpEBbQ9AbSsI+2DF847IDRinp2P1ozTz AMyWX2m1HXiAzR/PrNLMQiloSYETjJPAgLVodz7yl4/5XqCtZvwqLqk5OeV6Cm/RSKlZ w/Q275LTyJwhvsiwTg2LItn4PMPdC0pr1vL1W+ANSTU+k4nHIgfcOZCO7k7OjBmeRekf LCkVqpCH4c49YM/pFUdb82AM5R5MSIiJCZIMEcEz2LyoOlN5BQwy1oJhih9Se42DuE4B TfLeFBPnVVdaiR29I92QdHtcXuta8fH51F5gTrOKHZRtYtlZOYr9f9LhHwDJXRHLsMG6 crCg== X-Gm-Message-State: AMke39mpdwiUY+Vg6CHyNYJjRkGzjXxW3TVjRD7goauYxHVtLKZaJW23qLMd36j3ixTqG2vq X-Received: by 10.98.111.129 with SMTP id k123mr5209663pfc.18.1488953434431; Tue, 07 Mar 2017 22:10:34 -0800 (PST) Received: from ?IPv6:2601:647:4601:ec84:e5bb:b223:4881:ce73? ([2601:647:4601:ec84:e5bb:b223:4881:ce73]) by smtp.gmail.com with ESMTPSA id m136sm3324237pga.22.2017.03.07.22.10.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 22:10:33 -0800 (PST) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_0E782F0D-2482-4690-9B50-DF1319A10978"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <1A008D84-24AB-46A1-BDAF-00A1F8F8BA28@mozilla.com> Date: Tue, 7 Mar 2017 22:10:32 -0800 To: "perc@ietf.org" X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Perc] OHB usage in the client X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 06:10:36 -0000 --Apple-Mail=_0E782F0D-2482-4690-9B50-DF1319A10978 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, While starting to implement support for double encryption in Firefox I = encountered the following issue: Can the originating client use the OHB RTP header extension as a marker = between RTP header extension which can be removed by the MDD? One example which comes to mind might be the RID header extension for = simulcast, where it makes little sense to include that extension all the = way end-to-end to the receiving clients. So in such a case I think it might make sense for the originating client = to - build the RTP packet with all header extensions intended e2e - add the OHB header extension - do the e2e encryption - add header extension which can be removed by the MDD, like RID - do the HBH encryption - send the packet to the MDD I did not find any wording in the current drafts which either encourages = this usage or forbids it. I assume this is a use case which has not been = considered so far. Is this something we should add to the drafts? Best regards Nils Ohlmeier --Apple-Mail=_0E782F0D-2482-4690-9B50-DF1319A10978 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----- iQIcBAEBCgAGBQJYv6BYAAoJEJ3NnGfOORkkUWcP/3IBoSGolscSOxZ+pLN8/ZOg Jx80CqireeSR9OCMq5ccyhjOmzFCvWNgGk+ZEyofJBDj/+287zhx/aFA4//8aC85 LcUmMLkN4epD7Z2uXb5yEQPY/o8nByz6G4p9VgOZt7qOUDA0BXUSLESlxBpdAT+G bHAXVUYpabXaFbKdjumTnAB9Emtk6IJbJ8ZS7oRgCVQaacfothRbzjzq5RevTKP8 1sIWiBDg9dAe5bMoTwQIrglHFUkU6gj1SHxuEIYzUY8AWpwqIlbTBuscd2wIfIA/ 2yr6XPiXVWaviTlyrBmtJu5me0uybCk8JaY8TryYpP1TJ66oKDedG0qdQV9LD6F2 wkyQ0jbFgL/0CFO3T4TFrYoobZFX3jSR1ZYlvTS1JgCPGxhoxkTvQyYGYBRoXra5 bdBs3y/6AD6PNPWRIZ7NLhwVpe7tBKNggB8QeXSFf7LLR2CPPgKUSdG5BTiblMnT PmORXGeUazouxde2EjfqBFTrWn+Z9ADtQdTZxw5XanyfSVQvSfJue5gPJIZHdFk9 Ah5DKoOFagtpixgP2n1Pkr7BvfwMWkzShe9KiEJ0+QDTlFYV6sdDC0O2M9F+AjXV VN3LB5hpzogfokoHYqxhS9yuza88n9+1t0xF2yctjGxgDZUOQBicZNNjRlr7HA3b BITOf9/+NmeNjz+3SjLe =rI00 -----END PGP SIGNATURE----- --Apple-Mail=_0E782F0D-2482-4690-9B50-DF1319A10978-- From nobody Wed Mar 8 11:16: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 9C04F129527 for ; Wed, 8 Mar 2017 11:16:19 -0800 (PST) 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 kppTmz62Rgtl for ; Wed, 8 Mar 2017 11:16:18 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 A95981294BC for ; Wed, 8 Mar 2017 11:16:18 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 1so82113391qkl.3 for ; Wed, 08 Mar 2017 11:16:18 -0800 (PST) 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=M7YqhtY2ThqH9UEy3ExDQX1hP3kmtwCyt3f6UPDhxiA=; b=fOZrWhHB198/xZRn45LWDd5J1a+uEtJq6CaFoY/fm3J66QFRNwVXstMpIa9gHZTIWw F0cUhjjC8LxHqX3kvMKD11UVGevXgHiH+1nQTuoS5gsKjQztGjy+SDFD1iuTK4PTQjUM qzcZLie0Z9mG1EoDLfxY/nBLTd0SKDJX2uchcc5RpTfgJULQhwMrYpybjdslTnPrQ9mb KprLaZAZSs6xRwSUsGbKY+SSOIdUjtdD3KSaofac4SrlF3RfqqnIGUXYFI86wdNKsMtc 5KBxruqvM/AcPQPsiFTd3xoTVkn56RCqh/yWBFsOyEwQmb8agT6wg+PfUxNe5Dg2S5M8 iYng== 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=M7YqhtY2ThqH9UEy3ExDQX1hP3kmtwCyt3f6UPDhxiA=; b=ZfGoxFB2/PHNSCpZmaAd37fYz3ELDGZEMlY5dt4IxhSsf4Jd3ZvqBqFnKABdz4R45g UqtYPF8tWDBlZ/g78kSIBJTNRe2w7dglQQ2yhZe7TvJtR1A2KimCO1p950RlB69b6UuP FCirtvMQE7lZopxKlITqndsmuMBCgvSNCBL2XCLVjL6i8IhFvLYSNXG03EFybhm6EVF6 dLus9k8ghLRZJUDi9Lcn10xhImblA6mYymmVmyDCZ203a/Lz7lw1z21ZtyZ2EVJ4H2AV m8GfWONZFn2Qo/EhlTLRC59ODxW4+6Mw2PtrVlgbKtakxde89m0SMcin8Q27fpGQI1Db yDfQ== X-Gm-Message-State: AMke39lnnPrAM0YqUPd89EN1DLr6FZQZIc4dlm6Jenze71Nd1moqHzjFfMl02sIyrU2N+nfSDfk2wiOwyB88LQ== X-Received: by 10.200.48.244 with SMTP id w49mr9721943qta.77.1489000577606; Wed, 08 Mar 2017 11:16:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Wed, 8 Mar 2017 11:16:17 -0800 (PST) From: Suhas Nandakumar Date: Wed, 8 Mar 2017 11:16:17 -0800 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a113f40f47facc9054a3cf677 Archived-At: Cc: Richard Barnes Subject: [Perc] IETF98 PERC Agenda time requests. X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:16:19 -0000 --001a113f40f47facc9054a3cf677 Content-Type: text/plain; charset=UTF-8 The PERC WG session at IETF 98 in Chicago is scheduled for: *09:00-11:30 Wednesday, March 29, 2017 * Please submit any requests for agenda time by March 15. Thanks, Suhas (as co-chair) --001a113f40f47facc9054a3cf677 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The PERC WG session at IE= TF 98 in Chicago is scheduled for:

09:00-11:30=C2=A0Wednesday, March 29= , 2017=C2=A0
=
Please submit any requests for agenda time by=C2=A0March 15.

Thanks,
Suhas (as co-chair)
--001a113f40f47facc9054a3cf677-- From nobody Wed Mar 8 19:39: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 6476012973A for ; Wed, 8 Mar 2017 19:39:51 -0800 (PST) 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 zibWaW-rmimN for ; Wed, 8 Mar 2017 19:39:50 -0800 (PST) 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 E95FE129739 for ; Wed, 8 Mar 2017 19:39:49 -0800 (PST) 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 v293dmi2025907 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Mar 2017 22:39:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1489030788; bh=WaAFZt2cEVOiV+1IpnU8T9OVaqc/otRpgxVaiUNQk6o=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=fKGrOnDxh0j0VdRssa20d8fjLgFx4ho7qcUDZRa5ooLwSFXOf2a/qklQ4uXUXlffK 3gJZK5CVr67IuRdn5VlWuY3hnxFLQsfjpxAwZWf6PjVJZ/BpRwo7NletSDqOgJpF9a 7dJzc+tPJ17+BOeQR915tBLs6q/FRcBxshYASa0c= From: "Paul E. Jones" To: "Nils Ohlmeier" , "perc@ietf.org" Date: Thu, 09 Mar 2017 03:39:49 +0000 Message-Id: In-Reply-To: <1A008D84-24AB-46A1-BDAF-00A1F8F8BA28@mozilla.com> References: <1A008D84-24AB-46A1-BDAF-00A1F8F8BA28@mozilla.com> User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB5B98FDBD-864D-417D-ACB8-20890BF9168F" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Wed, 08 Mar 2017 22:39:48 -0500 (EST) Archived-At: Subject: Re: [Perc] OHB usage in the client X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 03:39:51 -0000 --------=_MB5B98FDBD-864D-417D-ACB8-20890BF9168F Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nils, In section 5.1, we have: If the endpoint wishes to insert header extensions that can be modified by an Media Distributor, it MUST insert an OHB header extension at the end of any header extensions protected end-to-end (if any), then add any Media Distributor-modifiable header extensions. ... There's a bit more there in that same paragraph, but that's the answer=20 to your question. However, it might actually be good to define those extensions that=20 should be placed after the OHB. Otherwise, one client might insert a=20 set of extensions before the OHB and another might do it after. We=20 could try to document those here or perhaps have another draft that=20 provides recommendations for various extensions. Paul ------ Original Message ------ From: "Nils Ohlmeier" To: "perc@ietf.org" Sent: 3/8/2017 1:10:32 AM Subject: [Perc] OHB usage in the client >Hello, > >While starting to implement support for double encryption in Firefox I=20 >encountered the following issue: > >Can the originating client use the OHB RTP header extension as a marker=20 >between RTP header extension which can be removed by the MDD? > >One example which comes to mind might be the RID header extension for=20 >simulcast, where it makes little sense to include that extension all=20 >the way end-to-end to the receiving clients. >So in such a case I think it might make sense for the originating=20 >client to >- build the RTP packet with all header extensions intended e2e >- add the OHB header extension >- do the e2e encryption >- add header extension which can be removed by the MDD, like RID >- do the HBH encryption >- send the packet to the MDD > >I did not find any wording in the current drafts which either=20 >encourages this usage or forbids it. I assume this is a use case which=20 >has not been considered so far. Is this something we should add to the=20 >drafts? > >Best regards > Nils Ohlmeier > --------=_MB5B98FDBD-864D-417D-ACB8-20890BF9168F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Nils,

In section 5.1, we have:
<= div>
=C2=A0 =C2=A0 =C2= =A0If the endpoint wishes to insert header extensions that can be =C2=A0 =C2=A0 =C2=A0modified by an M= edia Distributor, it MUST insert an OHB header
=C2=A0 =C2=A0 =C2=A0ex= tension at the end of any header extensions protected end-to-end
=C2= =A0 =C2=A0 =C2=A0(if any), then add any Media Distributor-modifiable header=
=C2=A0 =C2=A0 =C2=A0extensions. ...

Ther= e's a bit more there in that same paragraph, but that's the answer to your= question.

However, it might actually be good to= define those extensions that should be placed after the OHB. =C2=A0Otherwis= e, one client might insert a set of extensions before the OHB and another m= ight do it after. =C2=A0We could try to document those here or perhaps have = another draft that provides recommendations for various extensions.
<= div>
Paul

------ Original Message ------
From: "Nils Ohlmeier" <noh= lmeier@mozilla.com>
To: "perc@ietf.org" <perc@ietf.org= >
Sent: 3/8/2017 1:10:32 AM
Subject: [Perc] OHB usage in the client

Hello,
=C2=A0
While starting to implement support for double encryption in Firefox I = encountered the following issue:
=C2=A0
Can the originating client use the OHB RTP header extension as a marke= r between RTP header extension which can be removed by the MDD?
=C2=A0
One example which comes to mind might be the RID header extension for= simulcast, where it makes little sense to include that extension all the wa= y end-to-end to the receiving clients.
So in such a case I think it might make sense for the originating clie= nt to
- build the RTP packet with all header extensions intended e2e
- add the OHB header extension
- do the e2e encryption
- add header extension which can be removed by the MDD, like RID
- do the HBH encryption
- send the packet to the MDD
=C2=A0
I did not find any wording in the current drafts which either encourag= es this usage or forbids it. I assume this is a use case which has not been = considered so far. Is this something we should add to the drafts?
=C2=A0
Best regards
=C2=A0=C2=A0Nils Ohlmeier
=C2=A0
--------=_MB5B98FDBD-864D-417D-ACB8-20890BF9168F-- From nobody Thu Mar 9 11: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 C10BE12945A; Thu, 9 Mar 2017 11:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9FPB0YAF0hZC; Thu, 9 Mar 2017 11:06:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997CD129452; Thu, 9 Mar 2017 11:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5347; q=dns/txt; s=iport; t=1489086369; x=1490295969; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pr8hvkNYc3zHiUszYJEV8zS5npFQV6B0R9q3kIWwZ2A=; b=lyZpejkLY1F/GxdtFXIp7yiVlcgGe4vTitQjXKMkHhXMFs7+hesmAOxG vDBMiGfqynZs80BHLI1htlgPUvNR+8bS2e0SzwANlly0AhgfzJ+VDKQyr X1d9i473d9NhS+kEKJ7/hrP/daVoQNGZBaTL9EOjCQrz8XCvrbMJ9jBvl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAQC9psFY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jgWsHg1mKDJFPhiOBaod+hS2CDoYiAoIxPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQMEHARVEAIBCAQNAwECKAQDIQkIFAkIAgQBDQWJaAMVsRIMgiWHN?= =?us-ascii?q?g2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRvglGCI4Jngl4Fm386AY4MhCu?= =?us-ascii?q?Be48liESCEIhqAR84gQNWFYcTdYkegQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208,217";a="395679676" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2017 19:06:08 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v29J68BQ018189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 19:06:08 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 13:06:08 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Thu, 9 Mar 2017 13:06:08 -0600 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba , Emil Ivov , Boris Grozev Thread-Topic: [avtext] draft-ietf-avtext-framemarking and FEC Thread-Index: AQHSmQg1frQLKhEX+0Sxuj+szvmizA== Date: Thu, 9 Mar 2017 19:06:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.238.74] Content-Type: multipart/alternative; boundary="_000_D4E70BF46AB64mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "perc@ietf.org" Subject: Re: [Perc] [avtext] draft-ietf-avtext-framemarking and FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:06:10 -0000 --_000_D4E70BF46AB64mzanatyciscocom_ Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Bernard, Adding PERC for your question on HBH vs E2E FEC/RTX. I expected HBH but don= 't think this has been discussed. Adding Emil and Boris as they plan to sub= mit/present a PERC draft related to this (RTX). Frame marking was intended for Source RTP Streams not Redundancy RTP Stream= s [RFC 7656]. I will update the draft to reflect this. If E2E encrypted red= undancy streams need some type of marking, I would recommend a separate mar= king mechanism rather than overloading or extending the current video frame= marking draft. Thanks, Mo From: avtext > on b= ehalf of Bernard Aboba > Date: Wednesday, March 1, 2017 at 3:10 PM To: "avtext@ietf.org" > Subject: [avtext] draft-ietf-avtext-framemarking and FEC So far, discussion on framemarking has focused on conveying information abo= ut video frames useful to an SFU. In video forwarding scenarios, forward error correction can be used to prot= ect one or more layers. Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not end-= to-end. For example, FEC is consumed and re-generated by the SFU which rec= eives video frames and repairs via the received FEC if it can.The SFU decid= es which video frames to forward (such as by using info in the frame markin= g header), and will regenerate an FEC stream corresponding to the forwarded= stream. My question is whether hop-by-hop robustness is expected to continue with P= ERC so that the payloads of FEC packets would be available to the SFU, or w= hether FEC payload would also be encrypted so that FEC would be end-to-end. If FEC becomes end-to-end, do those packets also need to be marked? --_000_D4E70BF46AB64mzanatyciscocom_ Content-Type: text/html; charset="windows-1251" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Bernard,

Adding PERC for your question on HBH vs E2E FEC/RTX. I expected HBH bu= t don't think this has been discussed. Adding Emil and Boris as they plan t= o submit/present a PERC draft related to this (RTX).

Frame marking was intended for Source RTP Streams not Redundancy RTP S= treams [RFC 7656]. I will update the draft to reflect this. If E2E encrypte= d redundancy streams need some type of marking, I would recommend a separat= e marking mechanism rather than overloading or extending the current video frame marking draft.

Thanks,
Mo

From: avtext <avtext-bounces@ietf.org> on behalf of Berna= rd Aboba <bernard.aboba@gmail= .com>
Date: Wednesday, March 1, 2017 at 3= :10 PM
To: "avtext@ietf.org" <= avtext@ietf.org>
Subject: [avtext] draft-ietf-avtext= -framemarking and FEC

So far, discussion on framemarking has focused on conveyin= g information about video frames useful to an SFU. 

In video forwarding scenarios, forward error correction can be used to= protect one or more layers. 

Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not= end-to-end.  For example, FEC is consumed and re-generated by the SFU= which receives video frames and repairs via the received FEC if it can.The= SFU decides which video frames to forward (such as by using info in the frame marking header), and will regenerate a= n FEC stream corresponding to the forwarded stream. 

My question is whether hop-by-hop robustness is expected to continue w= ith PERC so that the payloads of FEC packets would be available to the SFU,= or whether FEC payload would also be encrypted so that FEC would be end-to= -end. 

If FEC becomes end-to-end, do those packets also need to be marked?&nb= sp;
 --_000_D4E70BF46AB64mzanatyciscocom_-- From nobody Fri Mar 10 13:57: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 7402A1294EA for ; Fri, 10 Mar 2017 13:57:52 -0800 (PST) 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 fy9qrHwfmxwS for ; Fri, 10 Mar 2017 13:57:51 -0800 (PST) Received: from smtp149.dfw.emailsrvr.com (smtp149.dfw.emailsrvr.com [67.192.241.149]) (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 8A3D9129452 for ; Fri, 10 Mar 2017 13:57:51 -0800 (PST) Received: from smtp19.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9667040251; Fri, 10 Mar 2017 16:57:50 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 28ADD401AF; Fri, 10 Mar 2017 16:57:50 -0500 (EST) 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); Fri, 10 Mar 2017 16:57:50 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <1A008D84-24AB-46A1-BDAF-00A1F8F8BA28@mozilla.com> Date: Fri, 10 Mar 2017 14:57:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12B2800B-D4C3-407A-9F38-CD53F4F8FA67@iii.ca> References: <1A008D84-24AB-46A1-BDAF-00A1F8F8BA28@mozilla.com> To: Nils Ohlmeier X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] OHB usage in the client X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 21:57:52 -0000 > On Mar 7, 2017, at 11:10 PM, Nils Ohlmeier = wrote: >=20 >=20 > Can the originating client use the OHB RTP header extension as a = marker between RTP header extension which can be removed by the MDD? Yes, and I think that is generally a good thing for implementations to = do.=20 From nobody Mon Mar 13 02:18:55 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 3EA44129400; Mon, 13 Mar 2017 02:18:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148939672913.17047.16572935065373770247@ietfa.amsl.com> Date: Mon, 13 Mar 2017 02:18:49 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-dtls-tunnel-00.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:18:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing 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-00.txt Pages : 16 Date : 2017-03-12 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-dtls-tunnel-00 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 Mon Mar 13 09:16:41 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 089EF129405; Mon, 13 Mar 2017 09:16:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942179602.16906.1587372254214201231@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:16:36 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-03.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:16:36 -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 Secure RTP Authors : Cullen Jennings John Mattsson David A. McGrew Dan Wing Filename : draft-ietf-perc-srtp-ekt-diet-03.txt Pages : 21 Date : 2017-03-13 Abstract: Encrypted Key Transport (EKT) is an extension to 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-03 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 Mon Mar 13 09:18:41 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 D712C129509; Mon, 13 Mar 2017 09:18:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942191586.16849.7648424935487231731@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:18:35 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-double-03.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:18:36 -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-03.txt Pages : 13 Date : 2017-03-13 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-double-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-03 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 Mon Mar 13 10:06:47 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 874B3129509; Mon, 13 Mar 2017 10:06:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942480237.17026.4002623178944928071@ietfa.amsl.com> Date: Mon, 13 Mar 2017 10:06:42 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-03.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:06:42 -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 : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing Authors : Paul E. Jones David Benham Christian Groves Filename : draft-ietf-perc-private-media-framework-03.txt Pages : 18 Date : 2017-03-13 Abstract: This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distribution devices are not trusted with the end-to-end media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-03 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 Mon Mar 13 11:24: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 178551299FE for ; Mon, 13 Mar 2017 11:24:42 -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, 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 XnYQoFGOSd3g for ; Mon, 13 Mar 2017 11:24:40 -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 F203A129A04 for ; Mon, 13 Mar 2017 11:24:38 -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 v2DIOaJB028386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Mar 2017 14:24:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1489429477; bh=ISy8Em3INdcUk3lbKNfpv/RcVO+uIJgElxBR0lBU40g=; h=From:To:Subject:Date:Reply-To; b=jZZpZ9UlDxG6Kw7WKEOzLkNgMHs3i2M1pwVio6OWx3MrYcq04TyWzgirFuwxpF+tn DReMz9Po6rLTyZNj5nssoJuRtwRRJVjZxISIrBp3asOyQRnen+Amo/+AnHU3ys+lY5 /ey11ZfgkkxuQEQwLdlGduHl55J/zqRIjNPByxK4= From: "Paul E. Jones" To: "perc@ietf.org" Date: Mon, 13 Mar 2017 18:24:36 +0000 Message-Id: User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Mon, 13 Mar 2017 14:24:37 -0400 (EDT) Archived-At: Subject: [Perc] Signaling the SDP dtls-id in DTLS X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:24:42 -0000 PERC WG, We submitted the the draft referenced below for consideration in PERC=20 during this IETF meeting. Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 3/13/2017 2:21:56 PM Subject: I-D Action: draft-jones-perc-dtls-id-00.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Transporting the SDP attribute 'dtls-id' in=20 TLS and DTLS Authors : Paul E. Jones Nils H. Ohlmeier Filename : draft-jones-perc-dtls-id-00.txt Pages : 6 Date : 2017-03-13 Abstract: This draft defines a new extension to carry the "dtls-id" value defined for use in the Session Description Protocol within TLS and DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-perc-dtls-id/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-jones-perc-dtls-id-00 Please note that it may take a couple of minutes from the time of=20 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Mar 13 14:54: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 D9102129BC5 for ; Mon, 13 Mar 2017 14:54:42 -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 9RIFlyQvH5dL for ; Mon, 13 Mar 2017 14:54:41 -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 6E52F129BBF for ; Mon, 13 Mar 2017 14:54:41 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id x35so42901688qtc.2 for ; Mon, 13 Mar 2017 14:54:41 -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=5xnVQqT1N77G32GZs9bGsKe8QYa/YQric8vzxxwNkaQ=; b=O16Z/jRCIWUb1HUAE2KaHaKux1Aubxz4XVaqM0ZMxgIVC5shF8yiUEXDbE2Y2q14lQ sv8w07NTGUq0/K1q1vjRT8LpuB3Z/KPtGog10DFTGXo71tUsV0ki5YcWPEYOhbMbrNnA mYZHHxqAPjB8GbIBM2AKVFF2VjgGHqHoGZW/z9+Pes9CIoCH6mzH2hLuSrKUs6Yc8L73 kdeG1z5WqKB1GvVIZY4lx16g1PUTMR64aUAjdE3lfp+ioRNMhsMgXhmqBk1o+2EbMMvc mZiDNXjMZoH+Zk4f2jtce06UmwlF6s8jnaLL1wDzeVEDCF7ah5EqMDvQjvlXQH5Bx11p IQAQ== 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=5xnVQqT1N77G32GZs9bGsKe8QYa/YQric8vzxxwNkaQ=; b=DctCZBLQNnFVSt1AVAPZIj0aZART2GdYm8tqxmIctvu3kKfgKfEUX1pRRB/rlxM/6P tJDz6CNI85sqFMHAycI2GRLXkcn/IBSbUSMe+0aYv0kXN04EuvZTpPscac6+RbFV5WT8 d4e9XgIl78bAmfBgx8KaHjPyIFROfPWstE6/Q8OYf4UJFHEz6/hb8nAM8ZZs03Fvx5ZP cM0EM8Axy0XficBtlCGVZKHMBJJayRyo1lWeCqKzYt5pgY1aPMqEoz0AX11I5/v6qA1E 8RlWS/JzorPZlxjqfJJiwbk169tDjtCV6KGP4DJiB5tHk2C/xKEfkaREJtWFj+rbdZD8 x4/g== X-Gm-Message-State: AMke39npmNd+bfQZJVLmQqFc/wfulQY8u/UO6SMOvjZKbx0WQ6LJy0T9tV9WtgrNHZ4bnO1TnwO7p2K6azRA3Q== X-Received: by 10.200.46.91 with SMTP id s27mr36841652qta.278.1489442080503; Mon, 13 Mar 2017 14:54:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 14:54:40 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 14 Mar 2017 08:54:40 +1100 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Signaling the SDP dtls-id in DTLS X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:54:43 -0000 Note that this overlaps with the draft I shared in avtcore last meeting: https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ The mechanism in Paul's (and Nils') draft is a strict subset of what is in the other draft. It's identical now because Paul and I have been talking. We just don't know how to proceed, because avtcore consider the security aspects of the UKS work outside of their remit/expertise (or something like that, I can't remember the details of the discussion from last meeting). If this working group is open to taking on a slightly larger scope of work than what Paul's draft covers, then it might be prudent to discuss strategy at the meeting. On 14 March 2017 at 05:24, Paul E. Jones wrote: > PERC WG, > > We submitted the the draft referenced below for consideration in PERC during > this IETF meeting. > > Paul > > ------ Forwarded Message ------ > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Sent: 3/13/2017 2:21:56 PM > Subject: I-D Action: draft-jones-perc-dtls-id-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Transporting the SDP attribute 'dtls-id' in TLS > and DTLS > Authors : Paul E. Jones > Nils H. Ohlmeier > Filename : draft-jones-perc-dtls-id-00.txt > Pages : 6 > Date : 2017-03-13 > > Abstract: > This draft defines a new extension to carry the "dtls-id" value > defined for use in the Session Description Protocol within TLS and > DTLS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jones-perc-dtls-id/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-jones-perc-dtls-id-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Mon Mar 13 15:21: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 71A1B129BDB for ; Mon, 13 Mar 2017 15:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=2.035, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hM8NO5Ra74LN for ; Mon, 13 Mar 2017 15:21:24 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 6F78D129BD4 for ; Mon, 13 Mar 2017 15:21:20 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2DMJSnH001400; Mon, 13 Mar 2017 18:21:17 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 294b7q9mpx-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Mar 2017 18:21:17 -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, 13 Mar 2017 17:21:16 -0500 From: Jonathan Lennox To: Martin Thomson Thread-Topic: [Perc] Signaling the SDP dtls-id in DTLS Thread-Index: AQHSnEewzeAqH6pJsUqSdrKNhNHoH6GTq4SA Date: Mon, 13 Mar 2017 22:21:16 +0000 Message-ID: <584E02CC-2353-4E3E-8CA3-80D4476EC82E@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <409F14D57C98CF45A54517F20275FF3C@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-13_16:, , 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-1702020001 definitions=main-1703130172 Archived-At: Cc: "Paul E. Jones" , "perc@ietf.org" Subject: Re: [Perc] Signaling the SDP dtls-id in DTLS X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:21:25 -0000 DQo+IE9uIE1hciAxMywgMjAxNywgYXQgNTo1NCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBOb3RlIHRoYXQgdGhpcyBvdmVybGFwcyB3 aXRoIHRoZSBkcmFmdCBJIHNoYXJlZCBpbiBhdnRjb3JlIGxhc3QgbWVldGluZzoNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGhvbXNvbi1hdnRjb3JlLXNkcC11a3Mv DQo+IA0KPiBUaGUgbWVjaGFuaXNtIGluIFBhdWwncyAoYW5kIE5pbHMnKSBkcmFmdCBpcyBhIHN0 cmljdCBzdWJzZXQgb2Ygd2hhdA0KPiBpcyBpbiB0aGUgb3RoZXIgZHJhZnQuICBJdCdzIGlkZW50 aWNhbCBub3cgYmVjYXVzZSBQYXVsIGFuZCBJIGhhdmUNCj4gYmVlbiB0YWxraW5nLiAgV2UganVz dCBkb24ndCBrbm93IGhvdyB0byBwcm9jZWVkLCBiZWNhdXNlIGF2dGNvcmUNCj4gY29uc2lkZXIg dGhlIHNlY3VyaXR5IGFzcGVjdHMgb2YgdGhlIFVLUyB3b3JrIG91dHNpZGUgb2YgdGhlaXINCj4g cmVtaXQvZXhwZXJ0aXNlIChvciBzb21ldGhpbmcgbGlrZSB0aGF0LCBJIGNhbid0IHJlbWVtYmVy IHRoZSBkZXRhaWxzDQo+IG9mIHRoZSBkaXNjdXNzaW9uIGZyb20gbGFzdCBtZWV0aW5nKS4NCg0K SSB0aGluayB0aGUgZGlzY3Vzc2lvbiDigJQgb3IgYXQgbGVhc3QgbXkgcGFydCBvZiB0aGUgZGlz Y3Vzc2lvbiDigJQgd2FzIHRoYXQgdGhlIFVLUyBwcm9ibGVtIGNhbiBvY2N1ciBmb3IgVExTLCBh bmQgZm9yIERUTFMvU0NUUCwgbm90IGp1c3QgZm9yIERUTFMvU1JUUDsgaXTigJlzIGluaGVyZW50 IHRvIHRoZSBmaW5nZXJwcmludCBtZWNoYW5pc20gYW5kIFNEUC4gVGh1cyBpdCBzZWVtZWQgdG8g bWUgdGhhdCBpdCB3YXMgbW9yZSBpbiBNTVVTSUPigJlzIHJlbWl0IHRoYW4gaW4gQVZUQ09SReKA mXMuICAoSSBkb27igJl0IHRoaW5rIFBFUkMgaXMgcmlnaHQuKQ0KDQo+IElmIHRoaXMgd29ya2lu ZyBncm91cCBpcyBvcGVuIHRvIHRha2luZyBvbiBhIHNsaWdodGx5IGxhcmdlciBzY29wZSBvZg0K PiB3b3JrIHRoYW4gd2hhdCBQYXVsJ3MgZHJhZnQgY292ZXJzLCB0aGVuIGl0IG1pZ2h0IGJlIHBy dWRlbnQgdG8NCj4gZGlzY3VzcyBzdHJhdGVneSBhdCB0aGUgbWVldGluZy4NCj4gDQo+IE9uIDE0 IE1hcmNoIDIwMTcgYXQgMDU6MjQsIFBhdWwgRS4gSm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNv bT4gd3JvdGU6DQo+PiBQRVJDIFdHLA0KPj4gDQo+PiBXZSBzdWJtaXR0ZWQgdGhlIHRoZSBkcmFm dCByZWZlcmVuY2VkIGJlbG93IGZvciBjb25zaWRlcmF0aW9uIGluIFBFUkMgZHVyaW5nDQo+PiB0 aGlzIElFVEYgbWVldGluZy4NCj4+IA0KPj4gUGF1bA0KPj4gDQo+PiAtLS0tLS0gRm9yd2FyZGVk IE1lc3NhZ2UgLS0tLS0tDQo+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+IFRv OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+IFNlbnQ6IDMvMTMvMjAxNyAyOjIxOjU2IFBNDQo+ PiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1qb25lcy1wZXJjLWR0bHMtaWQtMDAudHh0DQo+ PiANCj4+IA0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+PiBkaXJlY3Rvcmllcy4NCj4+IA0KPj4gDQo+PiAgICAg ICAgVGl0bGUgICAgICAgICAgIDogVHJhbnNwb3J0aW5nIHRoZSBTRFAgYXR0cmlidXRlICdkdGxz LWlkJyBpbiBUTFMNCj4+IGFuZCBEVExTDQo+PiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUGF1 bCBFLiBKb25lcw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIE5pbHMgSC4gT2hsbWVpZXIN Cj4+IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWpvbmVzLXBlcmMtZHRscy1pZC0wMC50eHQNCj4+ IFBhZ2VzICAgICAgICAgICA6IDYNCj4+IERhdGUgICAgICAgICAgICA6IDIwMTctMDMtMTMNCj4+ IA0KPj4gQWJzdHJhY3Q6DQo+PiAgIFRoaXMgZHJhZnQgZGVmaW5lcyBhIG5ldyBleHRlbnNpb24g dG8gY2FycnkgdGhlICJkdGxzLWlkIiB2YWx1ZQ0KPj4gICBkZWZpbmVkIGZvciB1c2UgaW4gdGhl IFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgd2l0aGluIFRMUyBhbmQNCj4+ICAgRFRMUy4N Cj4+IA0KPj4gDQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvbmVz LXBlcmMtZHRscy1pZC8NCj4+IA0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMt cGVyYy1kdGxzLWlkLTAwDQo+PiANCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPj4gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4+IA0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+ IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sDQo+PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4g DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g UGVyYyBtYWlsaW5nIGxpc3QNCj4+IFBlcmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGVyYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gUGVyYyBtYWlsaW5nIGxpc3QNCj4gUGVyY0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BlcmMNCj4gDQoN Cg== From nobody Mon Mar 13 16:20: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 DE1AC129B24 for ; Mon, 13 Mar 2017 16:20:47 -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 IS4RMh6GxPJ8 for ; Mon, 13 Mar 2017 16:20:46 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 6D6E3129562 for ; Mon, 13 Mar 2017 16:20:46 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id i34so44194652qtc.0 for ; Mon, 13 Mar 2017 16:20:46 -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:content-transfer-encoding; bh=8apds+TKaGSNJo0i+fVRtEvuKe32pIC9RSivkKJG0Nc=; b=N10dF6T4GgDomSn/E9AVR+f3/z/3unGfH6PjMy1CJcCXwnNXkmV/Pi+BdvPA48ghzG bEfwWtNsOfjY969163DzVOiqqdg30CMWKGCOnxpgv/LCl79GxVPyUyASIhRwLkuXK/Kf XB2UrR1FeLLPOiLljNNrxhQwUXZPnLuFwQj929tgynb4UEoZKILizF8IJls7YDl5VXhq YPlktVU1N0OGyAm6hhH+eHJqP23OUT0T6WK6oGdRmazggrmIpcpx5cNfpEicqi/u0IaA lpJV8t4dU4h8nVv3zSSg/D9zHGL3UA3wMikRxRMo3YlaZH99PNMgc7CjnWQwYxLmznuv nRhg== 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=8apds+TKaGSNJo0i+fVRtEvuKe32pIC9RSivkKJG0Nc=; b=bfJB0DEfNZ666QyOpfkK3gA5MWWDBcEkpsTiG0B0NVxfjIYItGlOraWUyuxJYnJRJA LLcVh511ONOzsWibe48updtFauQzVR6v0iMrO293nZSDg8X5NGNv0rljXUl3gMts/suj y3Ebwp+GuXChjfsKom4QwwWyOiGhSnzvJUX6PIYUlnrnT0aWvPtac5PBRNoAwFZ+oP2o Y6WWa2eSCROK07oUj2bflNInW5rufDydf5f0BROOXEqXKSDptbhWc4s7zUYT2BQ4v4r/ RIFjEVBSFTM3yrWn0D4qt8123ajHMPyVOXUbDGaukJLpdC/t2Ad3rl1KhD3UOHdVgB6T jltg== X-Gm-Message-State: AMke39nmVQQ7qaY69XpXyPMho3e6kIsQym620Lru0IyR1YcSmQELegjQOGIuaFQ30swk46UNJlo0Jcag6Rgx2Q== X-Received: by 10.237.34.250 with SMTP id q55mr36069533qtc.144.1489447245519; Mon, 13 Mar 2017 16:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 16:20:45 -0700 (PDT) In-Reply-To: <584E02CC-2353-4E3E-8CA3-80D4476EC82E@vidyo.com> References: <584E02CC-2353-4E3E-8CA3-80D4476EC82E@vidyo.com> From: Martin Thomson Date: Tue, 14 Mar 2017 10:20:45 +1100 Message-ID: To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Paul E. Jones" , "perc@ietf.org" Subject: Re: [Perc] Signaling the SDP dtls-id in DTLS X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:20:48 -0000 On 14 March 2017 at 09:21, Jonathan Lennox wrote: > I think the discussion =E2=80=94 or at least my part of the discussion = =E2=80=94 was that the UKS problem can occur for TLS, and for DTLS/SCTP, no= t just for DTLS/SRTP; it=E2=80=99s inherent to the fingerprint mechanism an= d SDP. Thus it seemed to me that it was more in MMUSIC=E2=80=99s remit than= in AVTCORE=E2=80=99s. (I don=E2=80=99t think PERC is right.) Hmm, and that reminds me why a=3Ddtls-id isn't going to cut it here. Unless we expand it to include other uses of TLS. I'll go lobby mmusic. From nobody Mon Mar 13 17:13: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 CE4D7129514 for ; Mon, 13 Mar 2017 17:13:40 -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 RDL3xLBfsJtN for ; Mon, 13 Mar 2017 17:13:39 -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 AB7751293DA for ; Mon, 13 Mar 2017 17:13:39 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id y76so236393105qkb.0 for ; Mon, 13 Mar 2017 17:13:39 -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=HOAh3TPfAo4+xV3c+u9lELZf+cgcZHPA0JrE+Aps9IE=; b=ACkfyRxn91oK8RBrOYWZXsY9FyvbAcg8CTMC37h0D/VIMHPktoerBhLuBEnRKGpl9B F69ttpq1fMHzDQ7IDfmlEWXwl1El7I/HF+KO0/7bs95AcSeQaVJlC7I8Z9VTE762zlb8 zUrKdn1Jm5n58f9VqztiTd2Ir1xZjPdoQ5WimrPeAMugJxGPsWV2/2I6QulsvXOUMwEo BKZWAasQ+UG1eFjuM6SmDVkVKK0ZN2SLQ9CGj0UUpJjseDLwAjAuvkLi2UlvrOLZAWKC OQKyNj1z1W1hJ1Ha5h3fPZJY3Y6irS2VG8pasV6BCJ4tUcy3viRFJHvr9dlBHrYmPX93 rmag== 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=HOAh3TPfAo4+xV3c+u9lELZf+cgcZHPA0JrE+Aps9IE=; b=A8UYAH4FvpR0lwrZ0AuSxd7DVN3iJKKuc0ICGvlVQwMnZ16jm6wW1k4cKSMNJkFnHI Pj9Bx05rIaTUn+uWQ5k2gPnGO7Xkn/nbb3k5J2OIQgxgkLFf9tVss0HSVLqAs2bGBSk6 VZ9JO6J6gJvtKurWGBIqvSf8EQiOt0DI6AJz6Cx3antl/fqS/QIoJvSUOt4LZRIRLg27 jaNTWkgKl9S6WKDa0z2P9pKutBrfMEMuHoccRmf/e3C9P1WK4VPk3+o/H2N579vWEL0w SeMl6l0oJsZx9tZQRCis/9WPvaODAXlzSqohr3ox08WwIniAktatbhbQR+KeF9UGoCcl b7Uw== X-Gm-Message-State: AMke39kIqn3V8dIV0QYjejTCPfjsytYWlwOyZX2zjwEd2K3WX9pm8+75h+4L3kDtK2pyi8uOEYkqHtT+5CFFmw== X-Received: by 10.233.216.68 with SMTP id u65mr33397533qkf.68.1489450418748; Mon, 13 Mar 2017 17:13:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 17:13:38 -0700 (PDT) From: Martin Thomson Date: Tue, 14 Mar 2017 11:13:38 +1100 Message-ID: To: perc@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Perc] Diet review of draft-ietf-perc-srtp-ekt-diet-03 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 00:13:40 -0000 If this is the diet version of the protocol, the full-blown version must have been mammoth, because this has lots of moving parts. Not that it can be trimmed much (see below), it's just an observation. This document really needs an overview of how the pieces fit together. It defines two separate mechanisms and the relationship between those is not very well articulated. A reader shouldn't have to read as much as I did to understand that you have: 1. a DTLS connection established between peers 2. that connection used to exchange an EKT key (or keys) indexed by SPI 3. each endpoint that sends SRTP occasionally sends the keys it is using to all recipients, encrypted under one of the EKT keys it knows In the Security Considerations: EKT inherits the security properties of the DTLS-SRTP (or other) keying it uses. This is untrue in a very important way. DTLS explicitly provides protection against key synchronization (certain attacks notwithstanding). The entire purpose of EKT is to enable key synchronization. This is introduction-worthy material in my opinion. Finally, a design complaint: this document adds a new message to TLS (one of the two key exchange methods). That message has an inner type that is extensible. I would prefer if this were to define multiple message types. In particular, DTLS 1.3 is adding acknowledgments at the DTLS layer, which will produce redundant mechanisms. From nobody Mon Mar 13 20:33: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 227DE1298C8 for ; Mon, 13 Mar 2017 20:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, 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 3XY-edAp7JIs for ; Mon, 13 Mar 2017 20:33:48 -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 7BBD3129865 for ; Mon, 13 Mar 2017 20:33:48 -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 v2E3XkBD011878 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Mar 2017 23:33:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1489462427; bh=6CoLJaq+nGQDx9xmzIP8QCWYcaQpPiY2UZJidJLdFhY=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=SBo0trotIFvM7owO2N06Ixldgk4bOwaZKc56sy2ss7E/rkpxOBbu1hDAjDOvEQnUB GrDcCg6yNwRmbQJeyzBxW3Aysi4lI5hnQ7WEx5SCmVgIr0Ljeo3u2Vqia7kjZylgx3 lfN0UQwMpQILVm/uSWXVa5WNER2zqWJLJ+bm/95M= From: "Paul E. Jones" To: "Martin Thomson" Date: Tue, 14 Mar 2017 03:33:47 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Mon, 13 Mar 2017 23:33:47 -0400 (EDT) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Signaling the SDP dtls-id in DTLS X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 03:33:50 -0000 Martin, I have no particular desire to see dtls-id in DTLS standardized in PERC,=20 though I did want to have a discussion to see if we can take this=20 approach to solve one of the open issues with the PERC tunnel spec. If=20 there is agreement on the approach, let's definitely figure out how to=20 get it done. The procedural bits in the draft Nils and I submitted should be=20 integrated into other PERC documents (e.g., tunnel and some other=20 document for the endpoint procedures). We did not intend for that draft=20 to continue going forward, but just to serve as a starting point for=20 discussion on this approach. Paul ------ Original Message ------ From: "Martin Thomson" To: "Paul E. Jones" Cc: "perc@ietf.org" Sent: 3/13/2017 5:54:40 PM Subject: Re: [Perc] Signaling the SDP dtls-id in DTLS >Note that this overlaps with the draft I shared in avtcore last=20 >meeting: >https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ > >The mechanism in Paul's (and Nils') draft is a strict subset of what >is in the other draft. It's identical now because Paul and I have >been talking. We just don't know how to proceed, because avtcore >consider the security aspects of the UKS work outside of their >remit/expertise (or something like that, I can't remember the details >of the discussion from last meeting). > >If this working group is open to taking on a slightly larger scope of >work than what Paul's draft covers, then it might be prudent to >discuss strategy at the meeting. > >On 14 March 2017 at 05:24, Paul E. Jones wrote: >> PERC WG, >> >> We submitted the the draft referenced below for consideration in PERC= =20 >>during >> this IETF meeting. >> >> Paul >> >> ------ Forwarded Message ------ >> From: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> Sent: 3/13/2017 2:21:56 PM >> Subject: I-D Action: draft-jones-perc-dtls-id-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Transporting the SDP attribute 'dtls-id' in= =20 >>TLS >> and DTLS >> Authors : Paul E. Jones >> Nils H. Ohlmeier >> Filename : draft-jones-perc-dtls-id-00.txt >> Pages : 6 >> Date : 2017-03-13 >> >> Abstract: >> This draft defines a new extension to carry the "dtls-id" value >> defined for use in the Session Description Protocol within TLS and >> DTLS. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-jones-perc-dtls-id/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-jones-perc-dtls-id-00 >> >> >> Please note that it may take a couple of minutes from the time of=20 >>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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc From nobody Tue Mar 14 20:42:44 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 77BE91294EF for ; Tue, 14 Mar 2017 20:42:43 -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 m4nE4BzlFTof for ; Tue, 14 Mar 2017 20:42:41 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 BDC591294A8 for ; Tue, 14 Mar 2017 20:42:41 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v127so3966703qkb.2 for ; Tue, 14 Mar 2017 20:42:41 -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=/tdl3XaRFCFwgPE6TAkQEd9QA+uLpjUIC7Iiohzc3lU=; b=SIfgGvBIuq+mJfyZQShk4vU1UEsovBsq21A+MQlC2X1udLYal7tahSTKG1ZYOa9tz5 +RdAYeoDTZXQz6jpI9D63abLHIGth4Sesbiz+Sx0nKKMwXA/Za0IOPMYKHWlfZniPpjU faZRA3RVe+4Dh++LICkRk13C61dS8+jQQPsZBr9Z3ot+GcR6R9FEFUUu+N7f/PgMhM2/ SI8IGtq9NgYOeQpo1Muoz09YUWZv1du7oMJ0+WAw3Gm2cSC846Uf0Pez7oFaCJbxGCRZ khFMJwoJZZDKMcD9GCUWiwOuGegcy1spLOhYUFLHO7ipnIXaSWMhzL238dt5zBqNEHP1 MX+g== 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=/tdl3XaRFCFwgPE6TAkQEd9QA+uLpjUIC7Iiohzc3lU=; b=DaM1v54U3M3XKL5frGlR8PcMDfzeyp/GvA/dq1acWf1wv5lDZBWgUDJoSofXGhjON1 fzg1ErSprEM68dOvr0NNBCERZfbS3pX28Rf3WQkhZRE/boZI7q0fKOqbUSIro9Q9YYA3 AElCsscIAH0Pc4rgK1Bs1l6KH/l9HWmycruiaodCYz4FLeMwgQaD+0XHstfHEY45b0S2 uycwrAHexGsKeHIT3GMzrdA8QzPbK9EcO1EleTLqgA+/FWNokKaCDa2qOf7JHz+YSMNd nRogKLU4KicV9iB8Onb5NgljCUkicpnMkQyZUR6nhcOD4Qvi9YVXbSh5A/XKDpBIjykA a//A== X-Gm-Message-State: AFeK/H00eKhmyn5P/BIaEC6vfNTxiQeaZbK+MqMjxkEdXRfsFqgS10CPnQ2ezrovGmIhSwIgfbiTEZ0iKriZuQ== X-Received: by 10.55.105.6 with SMTP id e6mr868534qkc.252.1489549360802; Tue, 14 Mar 2017 20:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Tue, 14 Mar 2017 20:42:40 -0700 (PDT) From: Suhas Nandakumar Date: Tue, 14 Mar 2017 20:42:40 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a1148733886b77f054abcbcbe Archived-At: Subject: [Perc] PERC IETF 98 - Initial Agenda 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, 15 Mar 2017 03:42:43 -0000 --001a1148733886b77f054abcbcbe Content-Type: text/plain; charset=UTF-8 Hello All Here is the initial agenda for the IETF98 Perc meeting: https://www.ietf.org/proceedings/98/agenda/agenda-98-perc-01 Please let us know if you have any questions. Cheers Suhas/Richard --001a1148733886b77f054abcbcbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 Here is the initial ag= enda for the IETF98 Perc meeting:=C2=A0




Please let us know if you have any que= stions.


Cheers
Suhas/Rich= ard

--001a1148733886b77f054abcbcbe-- From nobody Wed Mar 15 21:52: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 2ECAA1204DA for ; Wed, 15 Mar 2017 21:52:42 -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=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 01aH6_ugZNXf for ; Wed, 15 Mar 2017 21:52:40 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 E8D571201FA for ; Wed, 15 Mar 2017 21:52:39 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m27so1310542iti.1 for ; Wed, 15 Mar 2017 21:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=FYx5hX09o3uqnRMxUpEM80AhZWVA42racR/v8RYNIc0=; b=nUo3/ILhGeSM3CDfSgLYT+gvI+E1nkSrQsjbamOWFlSsY7mGtzizT1vlHYzg1NC0bS R8N9Pc/Wpctor2qb6cyRJHQDZLr+tYPG3DkYJVQeVQ12FUBGz155Cibp0YuRSDIbu6/V MT47OmBCGWnqOArTE733ibWVNyzeG0hY4pYBFnqcvt2axq5izVokZILBPdLeqZPPSp/h hVZtpvg0ydoPKsM4gNZFxq1R0YyyWepCjUcU1Ye8yDPqtDxXJ39nIWmUlZ6TAGgOWygk QR/SP3j/r7dKFnM6ruh8k1TKBVyakwDvx3QH/QRkqPseqbpQH0t1cZ3X1ApAmxCWHxJc UKvQ== 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=FYx5hX09o3uqnRMxUpEM80AhZWVA42racR/v8RYNIc0=; b=hFDxKYm+k0khmszCYnP0fbt8sfLQtlQhVYjWdvyrR5NbjFRDFpd5rUaPy7WTe4MHCl L3UOCY45wtO1k7h6USeV7c0DmXjytcfiM2kVqF/ULhBInJxW0I/xXZ1mHjsst+Btx6HE ZpDV8cI1DUNebu4Xs2lw9ml8X+oFoIgVWJNDCMVWHE+Ki9Wnaxh+Vk3lk4KosAdd/Kby WYbv6DeZ7IAX2zGRIScaQIiQL3sPz8ewczEYzucfCOOcylquV8rlqMwNrWEmrm2Jfy+P Ivd5549d0Or0LFq8AXzXTom0E+bGRaw7kMPy3qkiIYPNB7vWpvd7HpizR5pi+4UjmAlx aZIQ== X-Gm-Message-State: AFeK/H3Ici1FJEvthwGuUaxjfEEHhM6/84NBFJSJOZiDEQq4AV7dS5Kp9rHLg+lf2F2tAw== X-Received: by 10.36.43.194 with SMTP id h185mr25681013ita.121.1489639958712; Wed, 15 Mar 2017 21:52:38 -0700 (PDT) Received: from [192.168.1.196] ([136.62.26.34]) by smtp.googlemail.com with ESMTPSA id u206sm1179639itc.24.2017.03.15.21.52.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 21:52:37 -0700 (PDT) To: "perc@ietf.org" From: Emil Ivov Message-ID: Date: Wed, 15 Mar 2017 23:52:36 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] RTX 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, 16 Mar 2017 04:52:42 -0000 Hey folks, Boris and I thought we'd put a couple of thoughts on RTX use down on paper. Didn't make it for cut off but you can check it out here: https://github.com/bgrozev/perc-rtx/blob/master/draft-ietf-ivov-double-rtx-01 Will present it in Chicago together with the SSRC one (that is still in the queue). Cheers, Emil -- https://jitsi.org From nobody Tue Mar 21 14:49: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 8EB3A1294AA for ; Tue, 21 Mar 2017 14:49:25 -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] 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 PYaqj20tDL_S for ; Tue, 21 Mar 2017 14:49:24 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 F03411293E3 for ; Tue, 21 Mar 2017 14:49:23 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id o24so159771833otb.1 for ; Tue, 21 Mar 2017 14:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Cob1JTigRvkmKzrwBUkd5/yxQY7GC+lnaaKbLh/460Q=; b=ok2Au4+FQl5jQB5XsDmgOan6jXPt/0Hqvz1T/yGk+EBcc9ubyIBx6qNhVk11mzbeEr ksUfqYsnVhsrlvn2TcHEv4jjKuJQgkg/wGLpfF5rHv1EM0laimoAA6GmOJ6Agxdufhj3 TOFuHWcjC8JqbV5zwOX/uxJMH7wzTQbA9bBbO4YVUbVUeP4N3EUV1Bv7iG1mZdabxrXw AEXckWoMM83s1AQV/yYz07F5Kp8mWmvM4NnVkdI2dDvErEGIQuABk8EJstukZ0o0XEFM fXEgoqAFdPLclrscmcy3dqWKEK+5R6TYSkA3Dwq/ENLdrAiRAn3lOLkkl9uIT0+CGjEv 5BIA== 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=Cob1JTigRvkmKzrwBUkd5/yxQY7GC+lnaaKbLh/460Q=; b=RlgbRtkJE4e8JDknkXNkd+VCR/Ll3m21M1T2NX0iWSkYwhWgeAvhS8c1qe3atpC9fD F2KhKFZtPR9tLZwTtIdgPbc18pI4SKSNV3Q3FX4TfzczGup6xH8gN1AlpgpGWzRRqeqJ yb4lwnM/bQhdI7SqPrRQSHE8c//OFLSdZLLcE+PpEBg3+5kg6GmZibkKgfc+awEP2kOL QZU2Tcv7meSeKs1OxAKcrnsl0tHw4vSacFNL90dRSw4cAqhqBZlz84NCRrorKGZhqeEr Ym9Qrv0AdoSp8QTS2p8fJO9UOVQ2aDWHc8SZMc8qHyCAJIWYpErOVOfP+wL7qGtVfwh/ 7gSg== X-Gm-Message-State: AFeK/H2f4hul2mWnDq6eHHGIbJopUXavPX3Xr8Jz0l1IAUbOfJuwxZSiA/SVQ3z+We9MuTXE5+k69pOQgkoSjQ== X-Received: by 10.157.39.6 with SMTP id r6mr18936300ota.45.1490132963131; Tue, 21 Mar 2017 14:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 21 Mar 2017 14:48:17 -0700 (PDT) From: Eric Rescorla Date: Tue, 21 Mar 2017 14:48:17 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a113ad16aef965a054b449d14 Archived-At: Subject: [Perc] Question on diet Design? 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, 21 Mar 2017 21:49:25 -0000 --001a113ad16aef965a054b449d14 Content-Type: text/plain; charset=UTF-8 I've read this document and I'm finding it hard to understand the basic design. Ignoring all the details, we have a node i which connects to the Key Distributor (KD), and we want to establish a shared key for each node i = 0, 1, ... n (this is just to establish E2E keys. I'm ignoring HBH keys for now). So, as I read it, the system works like this. - Node i connects to KD and establishes a DTLS connection which establishes a pairwise key K_d_i. - The KD then generates a fresh EKT key K_e_i and sends it to i encrypted under K_d_i. - The KD then generates a shared group key K_g and sends it individually to all i in SRTP/EKT encrypted under K_e_i. Is that correct so far? If so, my question is why you need K_e_i? You have already established a shared secret via the DTLS connection and you can make as many fresh pairwise encryption keys as you want from that, so why do you need to make a new encryption key K_e_i and send it from KD to i? -Ekr --001a113ad16aef965a054b449d14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read this document and I'm finding it ha= rd to understand the
basic design. Ignoring all the details, we h= ave a node i which
connects to the Key Distributor (KD), and we w= ant to establish a
shared key for each node i =3D 0, 1, ... n (th= is is just to establish
E2E keys. I'm ignoring HBH keys for n= ow). So, as I read it, the system
works like this.

=
- Node i connects to KD and establishes a DTLS connection which = establishes
=C2=A0 a pairwise key K_d_i.
- The KD then = generates a fresh EKT key K_e_i and sends it to i encrypted
=C2= =A0 under K_d_i.
- The KD then generates a shared group key K_g a= nd sends it individually
=C2=A0 to all i in SRTP/EKT encrypted un= der K_e_i.

Is that correct so far?

<= /div>
If so, my question is why you need K_e_i? You have already establ= ished
a shared secret via the DTLS connection and you can make as= many fresh
pairwise encryption keys as you want from that, so wh= y do you need
to make a new encryption key K_e_i and send it from= KD to i?

-Ekr

--001a113ad16aef965a054b449d14-- From nobody Tue Mar 21 15:58: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 DC9141293FD for ; Tue, 21 Mar 2017 15:58:46 -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 nsd5wxYXQI4M for ; Tue, 21 Mar 2017 15:58:45 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 54876129404 for ; Tue, 21 Mar 2017 15:58:43 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id i203so5135409ywc.3 for ; Tue, 21 Mar 2017 15:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FxwImU+ghi/WekBbaFf+NkGl4p6fT779jnYIFPh98gg=; b=a6/bLuGDqOGHiqeN40PhURt7OGFh8Q/AXWY3L00QIXNSsDeJYIoXruyCCWnpsiHZpJ J46Z0Th4xaov8p9dwN70hLmoiYqebPk71WEH/Bb/VjS1jOsQI2nAsFfP9UFeoS0stnf3 CDoK1Xu502L4+MXGdlYQrj2NaM1NZs7j9e+lVsepZxlt3kXUahFqYdwsSsRnfGw4Jr3p gvBISx63RDn1gLnitkK0cZV30zQ81Fj7Bkv1i0IPZSyRW3P38fDI4hJ7RCY6NMv17ADM fxMQLVz4lmPrzKsWe2MVxd1HhkVPTkIR6fRoELohHKQT5GdH9molvzn8+MH/gQAq8QUT O9lA== 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=FxwImU+ghi/WekBbaFf+NkGl4p6fT779jnYIFPh98gg=; b=idp5muldBHYtDQPwssLbWG4a9FFkL+eRiZGJ0Ut6q3TcqLpx0XKQIXcS96QcY3HkcX Mbnw/rpMP6wbPcD45fxheo0utfQyr1BJQPpWGle+zTnEoiZq/4sQpFU+Hx3jk7+6aab6 XgWtBudU+Vn3j+grRF2GTOdOzMMGMnl2incTB4UKmiJ4G50KbWRbMFj3bUs+/Ul1XQJi TCsC10JQ+DJbKMaLegxLDcCQ4dlLAF1kOsfnu6MZCeqsdCfoLT/H5bsdOviLi9kVyRwm pIGUR+29PPhPLVQKrRFPCjWlHxhR+xHsnotPFIfNly5DHfVarfCdlc1MoafFx7PiRirz 1Jxg== X-Gm-Message-State: AFeK/H0/hm2Sqtx8RJgHeCSE6oL8jwdvIIcTEIYZM2KjouaPJdz/jzXI398Pd/5of+kK/QRoBMQh0IUlS8To1w== X-Received: by 10.37.53.138 with SMTP id c132mr24398986yba.105.1490137122300; Tue, 21 Mar 2017 15:58:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 21 Mar 2017 15:58:01 -0700 (PDT) From: Eric Rescorla Date: Tue, 21 Mar 2017 15:58:01 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114bbb32d77e47054b4595b6 Archived-At: Subject: [Perc] Double questions 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, 21 Mar 2017 22:58:47 -0000 --001a114bbb32d77e47054b4595b6 Content-Type: text/plain; charset=UTF-8 I've been reading Double and wanted to make sure I understand it. Here's my attempt to summarize, along with some questions. Corrections/answers would be welcome. INITIAL ENCRYPTION - Normal header - Non-modifiable Extensions - Modifiable Extensions - Payload When you encode a packet, you first encrypt the inner packet consisting solely of: - Normal header - Non-modifiable Extensions - Payload [I am ignoring encrypted extensions] Then if there is 1 or more non-modifiable extensions, you append an OHB and the modifiable extensions, like so: - Normal header - Non-modifiable Extensions - OHB - Modifiable Extensions - Encrypted Payload And now you encrypt that. As I understand it, the OHB, if present, must replicate the inner header: The OHB MUST replicate the information found in the RTP header following the application of the inner cryptographic transform. Does that mean it must be of 3-byte length? If so, why, because the outer transform shouldn't be changing any of these values. I.e., at the point where the packet gets to the media relay, PT and SEQ should match between the header and OHB. RELAYING Now, the media distributor removes the outer transform to recover: - Normal header - Non-modifiable Extensions - OHB - Modifiable Extensions - Encrypted Payload AT this point it can: 1. Change SEQ and/or PT as long as it updates OHB to match. But how does it get out of sync?] 2. Do anything it wants to the modifiable extensions, prepending an OHB if there was one. So, now you have: - Normal header - Non-modifiable Extensions - OHB' - Modifiable Extensions' - Encrypted Payload And you encrypt that and send. DECRYPTION Finally, upon decryption, you strip the outer transform, and get: - Normal header - Non-modifiable Extensions - OHB' - Modifiable Extensions' - Encrypted Payload You then remove the modifiable extensions, stomp the stuff in the normal header with the OHB, and then strip the inner transform. I note that S 5.3. says: o The PT from the outer SRTP packet is used for normal matching to SDP and codec selection. o The sequence number from the outer SRTP packet is used for normal RTP ordering. So, does that mean that the original PT/SEQ (as reconstructed from OHB) are not used for anything other than to make the decryption work? They're totally discarded? -Ekr --001a114bbb32d77e47054b4595b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been reading Double and wanted to make sure = I understand it.
Here's my attempt to summarize, along with s= ome questions.
Corrections/answers would be welcome.
INITIAL ENCRYPTION
- Normal header
- Non-m= odifiable Extensions
- Modifiable Extensions
- Payload<= /div>

When you encode a packet, you first encrypt the in= ner packet consisting
solely of:

- Norma= l header
- Non-modifiable Extensions
- Payload

[I am ignoring encrypted extensions]

<= div>Then if there is 1 or more non-modifiable extensions, you append an
OHB and the modifiable extensions, like so:
=C2=A0 =C2=A0= =C2=A0
- Normal header
- Non-modifiable Extensions
- OHB
- Modifiable Extensions
- Encrypted Payload=

And now you encrypt that. As I understand it, the= OHB, if present,
must replicate the inner header:

=
=C2=A0 =C2=A0 =C2=A0 The OHB MUST replicate the information foun= d in the
=C2=A0 =C2=A0 =C2=A0 RTP header following the applicatio= n of the inner cryptographic
=C2=A0 =C2=A0 =C2=A0 transform.

Does that mean it must be of 3-byte length? If so, why= , because the
outer transform shouldn't be changing any of th= ese values. I.e.,
at the point where the packet gets to the media= relay, PT and SEQ
should match between the header and OHB.
=


RELAYING
Now, the media distri= butor removes the outer transform to recover:

- No= rmal header
- Non-modifiable Extensions
- OHB
- Modifiable Extensions
- Encrypted Payload

=
AT this point it can:

1. Change SEQ and/or PT= as long as it updates OHB to match.
=C2=A0 =C2=A0But how does it= get out of sync?]
2. Do anything it wants to the modifiable exte= nsions, prepending
=C2=A0 =C2=A0an OHB if there was one.

So, now you have:

- Normal header=
- Non-modifiable Extensions
- OHB'
- Mod= ifiable Extensions'
- Encrypted Payload

<= div>And you encrypt that and send.


=
DECRYPTION
Finally, upon decryption, you strip the= outer transform, and get:

- Normal header
- Non-modifiable Extensions
- OHB'
- Modifiable = Extensions'
- Encrypted Payload

You = then remove the modifiable extensions, stomp the stuff in the
nor= mal header with the OHB, and then strip the inner transform.

=
I note that S 5.3. says:

=C2=A0 =C2=A0o= =C2=A0The PT from the outer SRTP packet is used for normal matching to
=C2=A0 =C2=A0 =C2=A0 SDP and codec selection.

=C2=A0 =C2=A0o =C2=A0The sequence number from the outer SRTP packet is u= sed for normal
=C2=A0 =C2=A0 =C2=A0 RTP ordering.

<= /div>
So, does that mean that the original PT/SEQ (as reconstructed fro= m
OHB) are not used for anything other than to make the decryptio= n work?
They're totally discarded?

<= br>
-Ekr

--001a114bbb32d77e47054b4595b6-- From nobody Tue Mar 21 16:43:44 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 A7454129496 for ; Tue, 21 Mar 2017 16:43:43 -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, 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 D7XCELID-IAN for ; Tue, 21 Mar 2017 16:43:41 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 C6C23129409 for ; Tue, 21 Mar 2017 16:43:41 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id p189so62920816pfp.1 for ; Tue, 21 Mar 2017 16:43:41 -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=X8UwST7OaXw6R6km6Tdy+WDPIfLUHUBWAERJc0jW3e4=; b=I3KIrgf2WNBW/EfSzcaSz1i5K617KVEChggidZfYMMMGK70BNYPLB5UOJmgck+Edve L/TgUh90si8xcJ6bjk8tRNs87uRdRMHuQ86A3PFcAk3KOcsgZpEV/UzyJ2pqDEq190uo 55Rh6EWQOlErQ/zXzlaQvmNEMQDAxIop1qZRA= 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=X8UwST7OaXw6R6km6Tdy+WDPIfLUHUBWAERJc0jW3e4=; b=oLx1F5PALOP9hAhQjQegcA85ph0dIIt364cLsPZN7t5CUa0RJc+Ku+/t++oOhqw7+T IGISV6LTGYXibhSsqhf0iWbTo9M0c+qO0G5GYHgEHM8MGQ5cQ1cIT5AHCYQphfi+lQ7L hVDsPBTusv6kgfGxvL4NkEq3NKpTg0PbxbtJMV4+XcXRFsHhyZHJ5MUin7j7JQqTptY0 BmQzPX0qJYrilFh5nZDZ8gf7IgNE/de+zOTbvleiZWPiQ1sIydxEJVBTVxqPyC0DYzSo kseJa8YXMy6eBzdGvpn13D+7mQ4bDz7dIUL757qiT+Pdvg8VbKZAocks3tMB4VrSilW8 OKDQ== X-Gm-Message-State: AFeK/H1gVJ1WxLZHxJfHN/sOGbTTXCapBzOofX4i8yBRmHTMZQ7IaMs7UktvJeknHEUJaUZY X-Received: by 10.84.233.199 with SMTP id m7mr6321670pln.25.1490139821311; Tue, 21 Mar 2017 16:43:41 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:ac8c:c9d5:2972:e3ff? ([2601:647:4601:ec84:ac8c:c9d5:2972:e3ff]) by smtp.gmail.com with ESMTPSA id g64sm41628074pfc.57.2017.03.21.16.43.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 16:43:39 -0700 (PDT) From: Nils Ohlmeier Message-Id: <9A3F5BE1-169D-43F0-85F6-BFEB0FBE4D62@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8DC580A7-5E8B-4263-84A0-689686435A85"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 21 Mar 2017 16:43:37 -0700 In-Reply-To: Cc: perc@ietf.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Double questions 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, 21 Mar 2017 23:43:44 -0000 --Apple-Mail=_8DC580A7-5E8B-4263-84A0-689686435A85 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Mar 21, 2017, at 15:58, Eric Rescorla wrote: > - Normal header > - Non-modifiable Extensions > - OHB > - Modifiable Extensions > - Encrypted Payload > > And now you encrypt that. As I understand it, the OHB, if present, > must replicate the inner header: > > The OHB MUST replicate the information found in the > RTP header following the application of the inner cryptographic > transform. > > Does that mean it must be of 3-byte length? If so, why, because the > outer transform shouldn't be changing any of these values. I.e., > at the point where the packet gets to the media relay, PT and SEQ > should match between the header and OHB. Yes that is my current reading of the draft that if the originating client adds the OHB it needs to duplicate PT and SEQ even though it has obviously not modified these. I guess the question here is if it is worth to have a shorter OHB header for the scenarios where PT and SEQ are the same (which could be used by originating client as well as relays which don't change any of this)? > > DECRYPTION > Finally, upon decryption, you strip the outer transform, and get: > > - Normal header > - Non-modifiable Extensions > - OHB' > - Modifiable Extensions' > - Encrypted Payload > > You then remove the modifiable extensions, stomp the stuff in the > normal header with the OHB, and then strip the inner transform. To be precise I think you need to take OHB and modifiable extensions out to make the decryption work. After the decryption you re-insert the modifiable extensions into the packet, because they might be of interest for your RTP stack. > I note that S 5.3. says: > > o The PT from the outer SRTP packet is used for normal matching to > SDP and codec selection. > > o The sequence number from the outer SRTP packet is used for normal > RTP ordering. > > So, does that mean that the original PT/SEQ (as reconstructed from > OHB) are not used for anything other than to make the decryption work? > They're totally discarded? That is my understanding, yes. Nils --Apple-Mail=_8DC580A7-5E8B-4263-84A0-689686435A85 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----- iQIcBAEBCgAGBQJY0bqqAAoJEJ3NnGfOORkkbW4P/01SlMIN5JiVqUi/3OZEMxiW HLe+efG5MQDwVyqssEtpiB4SYVwWUROXd6Qb48NdEl2YyYfcD7/9cna0GEMnlFlX qNXgQsTHNPH6ZynIqy+4YpRITVV4oOQ1aBnksFcod5T01ufLPgL7uBjt0yDaPsom hvq3zy+MziCG2JIimQuFOx9XR77r/7T5BP9LZvFyMIA2iuM3qel3Xw77oQNX5IxQ j11GqkSnoP0k8JK422EAZTALB9TQ4sVqdxvZbkymB9X17xhXbbRWGUSEc2Cnjl6t F91LXvLW505eIH7Mh5KvXR4YL+gYMU6woruT/2zZtchVSX1fdPU5XN+y9MBp3GFM CVWQNZwUCcsgpRiE7FdPWPxmUPk2weZk0+gwychP9NT1fkrG6egHmpFOjhR+Qp69 aSha0buFy71HBrM7EER9vKhzw7TvnxrNBSTVg5vj/nLdAP5NQ7n+1YDgNNjZzYwX twLmt8qX49hdf55tbj4a1mr3HZ7kA1SSjhTPYBKh3FcrFBT8bKKNb1n8D4W4+4yk Z5L8pZIvaAIUFWdInRXr6qPv1Wi28gaiwZCH7Q12jRiXmovIbLZofB45WlTNAK7D MRn2/XxvFSkMUEwZV7h7JU3QguipTBo5Foy3t8TZ5wAcxhvHJKdBlDViRykR2Sgo P5chTWd0+c29IL5sQwts =iw5r -----END PGP SIGNATURE----- --Apple-Mail=_8DC580A7-5E8B-4263-84A0-689686435A85-- From nobody Tue Mar 21 16:48: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 74D9B128708 for ; Tue, 21 Mar 2017 16:48:36 -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 PgXybj7qcSv5 for ; Tue, 21 Mar 2017 16:48:33 -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 BED9C129409 for ; Tue, 21 Mar 2017 16:48:33 -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 v2LNmVKZ016081 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Mar 2017 19:48:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490140112; bh=ZsaR8OmrAkVXKtY2Yu5pG0JvAUdQchHJGiBB8HiG/+o=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=AxwIr9dKmnzm3i2i51l9ObTve7wCZS+/Rn1Wm/tqjEZFoED4HpApc71MPyFcYowwr guIhpOyNkJElayvc9/fCmD33VJUuyVml6WxfIi5z17yyemAGLXbDpLn9wONfQuNV6s 51kqXhhgt49RHrt8u9HbSemDvViy7s6wCH3NaDNU= From: "Paul E. Jones" To: "Eric Rescorla" , perc@ietf.org Date: Tue, 21 Mar 2017 23:48:31 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB86B4C182-59F2-4C4E-A81F-509C6740757A" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Tue, 21 Mar 2017 19:48:32 -0400 (EDT) Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 21 Mar 2017 23:48:36 -0000 --------=_MB86B4C182-59F2-4C4E-A81F-509C6740757A Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ekr, For each endpoint, a HBH key is established using DTLS-SRTP (RFC 5764)=20 procedures via an association established between the endpoint and key=20 distributor. Those procedures are (mostly) unaltered from the=20 endpoint's perspective and independent of EKT. The only aspect that is=20 "alternated" is that, since we're using a "double" cipher, half of the=20 bits generated for the HBH key are discarded (as they're not used). In=20 the framework document, this is referred to as Key(j). For simplicity=20 in keeping your notation below, let's call this K_h. This is the SRTP=20 master key. There is also an SRTP master salt S_h created via the=20 DTLS-SRTP procedures. Over that DTLS association, the key distributor will send an "EKTKey"=20 message containing the conference key (what you called the group key,=20 K_g). The same conference key is given to each endpoint in the=20 conference. In the same message, an SRTP master salt S_g is provided by=20 the key distributor. As the "EKTKey" message is transmitted to the endpoint, the values {K_h,=20 S_h} are delivered to the media distributor via the tunnel protocol. At this point, the endpoint has {K_h, S_h, K_g, S_g} and the media=20 distributor has {K_h, S_h}. For every endpoint i, the K_h and S_h=20 values differ. Each endpoint then manufacturers a random SRTP master key E_i used for=20 E2E encryption. The endpoint then generates the various keys for RTP=20 encryption, RTP authentication, RTCP encryption, and RTCP authentication=20 using the KDF defined in RFC 3711 from the pair {E_i, S_g}. This=20 produces k_e, k_a, k_s (Section 4.3.1 of RFC 3711). Since we will have=20 these for both E2E and HBH, let's suffix whese with _e (for E2E). So,=20 we'll have K_e_e. The endpoint then generates the various keys for RTP encryption, RTP=20 authentication, RTCP encryption, and RTCP authentication using the KDF=20 defined in RFC 3711 from the pair {K_h, S_h}. As above, we'll have k_e,=20 k_a, k_s, which let's suffix as k_e_h (for HBH). The endpoint then performs these steps: 1) encrypts the RTP packet using the keys derived via the KDF for E2E,= =20 K_e_e and salt k_s_e. 2) encrypts the RTP packet using the keys derives via the KDF for HBH,= =20 namely K_e_h and k_s_h. The EKT field is then added to the end of the packet. If it's the=20 "short EKT field", it has no keying material inside. It would just be a=20 single 0 octet. The long EKT field is used periodically to allow the endpoint to=20 transmit E_i to other endpoints. The plaintext of this field is=20 constructed and then encrypted using AESKeyWrap(K_g, ekt_field). The=20 ciphertext is then appended to the packet, along with a few plaintext=20 fields indicating the field type and length. As the media distributor receives the packet, it removes the EKT field,=20 then decrypts the packet using the keys derived from {K_h,S_h}. It then=20 re-encrypts the packet using {K_h',S_h'} (where ' denotes the HBH keys=20 shared with the endpoint to which the media distributor intends to=20 forward the packet) and then attached the EKT field to the end=20 untouched. Upon receipt of the packet, the receiving endpoint first processes the=20 EKT field. It decrypts the field using K_g. It extracts the SRTP=20 master key E_i. It already has S_g via the EKTKey message from its own=20 exchange with the key distributor. So, using its own HBH keying=20 material {K_h',S_h'} and the E2E keying material {E_i,S_g}, it can=20 perform HBH and E2E decryption of the packet. I hope that helps. As you can see, EKT plays a very limited role in the=20 overall architecture. We're still very much relying on DTLS-SRTP=20 procedures and on standard SRTP procedures. Juggling all these keys is=20 certainly confusing, though. I guess a pretty picture showing all the=20 pieces would be useful. Paul ------ Original Message ------ From: "Eric Rescorla" To: perc@ietf.org Sent: 3/21/2017 5:48:17 PM Subject: [Perc] Question on diet Design? >I've read this document and I'm finding it hard to understand the >basic design. Ignoring all the details, we have a node i which >connects to the Key Distributor (KD), and we want to establish a >shared key for each node i =3D 0, 1, ... n (this is just to establish >E2E keys. I'm ignoring HBH keys for now). So, as I read it, the system >works like this. > >- Node i connects to KD and establishes a DTLS connection which=20 >establishes > a pairwise key K_d_i. >- The KD then generates a fresh EKT key K_e_i and sends it to i=20 >encrypted > under K_d_i. >- The KD then generates a shared group key K_g and sends it=20 >individually > to all i in SRTP/EKT encrypted under K_e_i. > >Is that correct so far? > >If so, my question is why you need K_e_i? You have already established >a shared secret via the DTLS connection and you can make as many fresh >pairwise encryption keys as you want from that, so why do you need >to make a new encryption key K_e_i and send it from KD to i? > >-Ekr > --------=_MB86B4C182-59F2-4C4E-A81F-509C6740757A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ekr,

For each endpoint, a HBH key is established using DTLS-SRTP (RF= C 5764) procedures via an association established between the endpoint and= key distributor. =C2=A0Those procedures are (mostly) unaltered from the end= point's perspective and independent of EKT. =C2=A0 The only aspect that is= "alternated" is that, since we're using a "double" cipher, half of the bits = generated for the HBH key are discarded (as they're not used). =C2=A0In th= e framework document, this is referred to as Key(j). =C2=A0For simplicity i= n keeping your notation below, let's call this K_h. =C2=A0This is the SRTP= master key. There is also an SRTP master salt S_h created via the DTLS-SRTP = procedures.

Over that DTLS association, the key = distributor will send an "EKTKey" message containing the conference key (w= hat you called the group key, K_g). =C2=A0The same conference key is given= to each endpoint in the conference. =C2=A0In the same message, an SRTP mast= er salt S_g is provided by the key distributor.

As the "EKTKey" message is transmitted to the end= point, the values {K_h, S_h} are delivered to the media distributor via the = tunnel protocol.

At this point, the endpoint ha= s {K_h, S_h, K_g, S_g} and the media distributor has=C2=A0{K_h, S_h}. =C2=A0F= or every endpoint i, the K_h and S_h values differ.

=
Each endpoint then manufacturers a ran= dom SRTP master key E_i used for E2E encryption. =C2=A0The endpoint then ge= nerates the various keys for RTP encryption, RTP authentication, RTCP encry= ption, and RTCP authentication using the KDF defined in RFC 3711 from the p= air {E_i, S_g}. =C2=A0This produces k_e, k_a, k_s (Section 4.3.1 of RFC 371= 1). =C2=A0Since we will have these for both E2E and HBH, let's suffix whese = with _e (for E2E). =C2=A0So, we'll have K_e_e.

The endpoint then generates the various = keys for RTP encryption, RTP authentication, RTCP encryption, and RTCP aut= hentication using the KDF defined in RFC 3711 from the pair {K_h, S_h}. =C2= =A0As above, we'll have=C2=A0k_e, k_a, k_s= , which let's suffix as k_e_h (for HBH).

The e= ndpoint then performs these steps:
=C2= =A0 1) encrypts the RTP packet using the keys derived via the KDF for E2E,= K_e_e and salt k_s_e.
=C2=A0 2) encrypt= s the RTP packet using the keys derives via the KDF for HBH, namely K_e_h a= nd k_s_h.

The EKT field is then added to the end = of the packet. =C2=A0If it's the "short EKT field", it has no keying mater= ial inside. It would just be a single 0 octet.

The long EKT field is used periodically to allow t= he endpoint to transmit E_i to other endpoints. =C2=A0The plaintext of this = field is constructed and then encrypted using AESKeyWrap(K_g, ekt_field). = =C2=A0The ciphertext is then appended to the packet, along with a few plai= ntext fields indicating the field type and length.

As the media distrib= utor receives the packet, it removes the EKT field, then decrypts the packe= t using the keys derived from {K_h,S_h}. =C2=A0It then re-encrypts the pack= et using {K_h',S_h'} (where ' denotes the HBH keys shared with the endpoint = to which the media distributor intends to forward the packet) and then att= ached the EKT field to the end untouched.

Upon receipt of the packet, t= he receiving endpoint first processes the EKT field. =C2=A0It decrypts the= field using K_g. =C2=A0It extracts the SRTP master key E_i. =C2=A0It alread= y has S_g via the EKTKey message from its own exchange with the key distrib= utor. =C2=A0 So, using its own HBH keying material {K_h',S_h'} and the E2E= keying material {E_i,S_g}, it can perform HBH and E2E decryption of the pac= ket.

I hope that helps. =C2=A0As you can see, EKT plays a very limited= role in the overall architecture. =C2=A0We're still very much relying on DT= LS-SRTP procedures and on standard SRTP procedures. =C2=A0Juggling all thes= e keys is certainly confusing, though. =C2=A0I guess a pretty picture showi= ng all the pieces would be useful.
Paul

------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com= >
Sent: 3/21/2017 5:48:17 PM
Subject: [Perc] Question on diet Design?

I've read this document and I'm finding it hard to un= derstand the
basic design. Ignoring all the details, we have a no= de i which
connects to the Key Distributor (KD), and we want to e= stablish a
shared key for each node i =3D 0, 1, ... n (this is ju= st to establish
E2E keys. I'm ignoring HBH keys for now). So, as= I read it, the system
works like this.

- Node i connects to KD and establishes a DTLS connection which establishe= s
=C2=A0 a pairwise key K_d_i.
- The KD then generates= a fresh EKT key K_e_i and sends it to i encrypted
=C2=A0 under K_= d_i.
- The KD then generates a shared group key K_g and sends it= individually
=C2=A0 to all i in SRTP/EKT encrypted under K_e_i.

Is that correct so far?

If so, my question is why you need K_e_i? You have already established
a shared secret via the DTLS connection and you can make as many fr= esh
pairwise encryption keys as you want from that, so why do you = need
to make a new encryption key K_e_i and send it from KD to i= ?

-Ekr

--------=_MB86B4C182-59F2-4C4E-A81F-509C6740757A-- From nobody Tue Mar 21 16:57: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 8C02012940A for ; Tue, 21 Mar 2017 16:57:17 -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 4Xg-mNzPRXeB for ; Tue, 21 Mar 2017 16:57:16 -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 355041293E9 for ; Tue, 21 Mar 2017 16:57:16 -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 v2LNvE9F016886 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Mar 2017 19:57:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490140635; bh=i/sWrS3ME9aOWnXajeWZAaaPh2hGP1dNab1f4Ntl2Ew=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=GJjUKo0iD8MmMwP5jLHLbE4u3/HPB1hb1AW+PYng/zxT2cjcuWCfjDbYoXFkpQrua EtlLW/Zko+0KCDwi9t+CsDqnwrF9Cc9aJigoNrzBhbeKPD5CIjOAkCUy16C9L9pzX4 OrcT3lkI2T6QKlDeRgq59NvvwgNCcLOzsi5kgdEY= From: "Paul E. Jones" To: "Eric Rescorla" , perc@ietf.org Date: Tue, 21 Mar 2017 23:57:15 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBE8898DC1-9840-451B-B96A-499E55F3D65F" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Tue, 21 Mar 2017 19:57:15 -0400 (EDT) Archived-At: Subject: Re: [Perc] Double questions 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, 21 Mar 2017 23:57:17 -0000 --------=_MBE8898DC1-9840-451B-B96A-499E55F3D65F Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ekr, >So, does that mean that the original PT/SEQ (as reconstructed from >OHB) are not used for anything other than to make the decryption work? >They're totally discarded? Yes, I think you described it all correctly. The PT and SEQ are=20 necessary only because they were originally there when the transmitting=20 endpoint performed HBH authenticated encryption. Thus, we need those=20 original values to properly authenticate the packet when decrypting. No=20 other reason for keeping them. Paul --------=_MBE8898DC1-9840-451B-B96A-499E55F3D65F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ekr,

So, does that mean that the original PT/= SEQ (as reconstructed from
OHB) are not used for anything= other than to make the decryption work?
They're totally discarded= ?

Yes, I think you described it all correctly. =C2=A0Th= e PT and SEQ are necessary only because they were originally there when the = transmitting endpoint performed HBH authenticated encryption. =C2=A0Thus,= we need those original values to properly authenticate the packet when decr= ypting. =C2=A0No other reason for keeping them.

Paul

--------=_MBE8898DC1-9840-451B-B96A-499E55F3D65F-- From nobody Tue Mar 21 17:05: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 67E3F128708 for ; Tue, 21 Mar 2017 17:04:58 -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=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 pvzrVCZPoAAn for ; Tue, 21 Mar 2017 17:04:55 -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 828CB127977 for ; Tue, 21 Mar 2017 17:04:55 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i203so5788149ywc.3 for ; Tue, 21 Mar 2017 17:04:55 -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=ghyHUhXjom0AUPGCINSOZp+M6IHG3e+ARvl/f7jS9Ow=; b=2AGGRG90EZxUOLT74plyuCaKmNcEgsupAL2n7oVWJUHl0jDNpcYJH4hlz3RvnCa7en d/RLeoqAm4HcG641E9fhT2x+2sA75S3UH+54TerPr8JffBLCaBcfxsbd8TGTX8hJ8uYM 5PVSRgfBYuoqEqHZd4eIR4mpgNgO7mO3uVAHoqqzXf1gD1UxGoKoBt0C/PpxR2p81gAV G0NN+Z2iuU5sGjtJB1nVpsBB8vpMdYGlDesEt+ymDpUT4v8G4wXAtt2Kfz+g3Kg7sStm NMzdq4snt7V5BXAnXRJYyKjmYFeEIFAjkqZJ83IC9APGElkyYTR0lrAglMSL2d/E3nnF 2lkg== 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=ghyHUhXjom0AUPGCINSOZp+M6IHG3e+ARvl/f7jS9Ow=; b=Mlnpi3ras5zltu9vnZCcPIbv/fgMW/1cxqZgNtq5LIjRhRIqfSWpqMZMZb0oRiWmRE p2/83Bqd2RH+78jqSt5Z5wGbcH5gfX0Nc06qwqpo6ROTpBMBG4qbIjst3OQj+nyVIFaA vigWCXUFr5yo9K6KECzPh7DO3h/ct3SZFLe3qAXA+bZNZNHTu+/KcvV7WKv5icMcaFWc Xvk2CeCmy7F485UNmUtycr+VC5hJU/7lpHpIVHnvq9wTBMiBTGt7F/wUbfYz9AXMg8Ag 9AlD7yuLTDadZ19ftPajUxzfW5UWSYyVfLd+oBDy1+Wx0blYOGtSg0AxKfBfJQnyt2yI ljbA== X-Gm-Message-State: AFeK/H3Razxjk7txZhjrNAJwmvFKEWaG0t/kn2zK/YsN5QBPUlGJBxxUtWgT55Quz9TArNTTaiLoJ9cpH2cp1w== X-Received: by 10.13.204.142 with SMTP id o136mr750564ywd.87.1490141094641; Tue, 21 Mar 2017 17:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 21 Mar 2017 17:04:14 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 21 Mar 2017 17:04:14 -0700 Message-ID: To: "Paul E. Jones" Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114f12a49cea5c054b468202 Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 22 Mar 2017 00:04:58 -0000 --001a114f12a49cea5c054b468202 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 21, 2017 at 4:48 PM, Paul E. Jones wrote: > Ekr, > > For each endpoint, a HBH key is established using DTLS-SRTP (RFC 5764) > procedures via an association established between the endpoint and key > distributor. Those procedures are (mostly) unaltered from the endpoint's > perspective and independent of EKT. The only aspect that is "alternated" > is that, since we're using a "double" cipher, half of the bits generated > for the HBH key are discarded (as they're not used). In the framework > document, this is referred to as Key(j). For simplicity in keeping your > notation below, let's call this K_h. This is the SRTP master key. There is > also an SRTP master salt S_h created via the DTLS-SRTP procedures. > > Over that DTLS association, the key distributor will send an "EKTKey" > message containing the conference key (what you called the group key, > K_g). The same conference key is given to each endpoint in the > conference. In the same message, an SRTP master salt S_g is provided by > the key distributor. > Let's ignore salts for now. I'd also like to ignore all the hop-by-hop keys, because I'm primarily concerned with the e2e keys. As the "EKTKey" message is transmitted to the endpoint, the values {K_h, > S_h} are delivered to the media distributor via the tunnel protocol. > > At this point, the endpoint has {K_h, S_h, K_g, S_g} and the media > distributor has {K_h, S_h}. For every endpoint i, the K_h and S_h values > differ. > > Each endpoint then manufacturers a random SRTP master key E_i used for E2E > encryption. The endpoint then generates the various keys for RTP > encryption, RTP authentication, RTCP encryption, and RTCP authentication > using the KDF defined in RFC 3711 from the pair {E_i, S_g}. This produces > k_e, k_a, k_s (Section 4.3.1 of RFC 3711). Since we will have these for > both E2E and HBH, let's suffix whese with _e (for E2E). So, we'll have > K_e_e. > > The endpoint then generates the various keys for RTP encryption, RTP > authentication, RTCP encryption, and RTCP authentication using the KDF > defined in RFC 3711 from the pair {K_h, S_h}. As above, we'll have k_e, > k_a, k_s, which let's suffix as k_e_h (for HBH). > > The endpoint then performs these steps: > 1) encrypts the RTP packet using the keys derived via the KDF for E2E, > K_e_e and salt k_s_e. > 2) encrypts the RTP packet using the keys derives via the KDF for HBH, > namely K_e_h and k_s_h. > > The EKT field is then added to the end of the packet. If it's the "short > EKT field", it has no keying material inside. It would just be a single 0 > octet. > > The long EKT field is used periodically to allow the endpoint to transmit > E_i to other endpoints. The plaintext of this field is constructed and > then encrypted using AESKeyWrap(K_g, ekt_field). The ciphertext is then > appended to the packet, along with a few plaintext fields indicating the > field type and length. > I'm going to stop here, because I think this is the relevant point, that I had misunderstood and I want to summarize looking just at the E2E portion. 1. You start out with every agent i having a pairwise key K_d_i (the DTLS traffic key) with the KD. 2. The KD then generates a single shared key K_g which it provides to each agent i under K_d_i (in DTLS). 2. Each agent then generates its own transmission key E_i which it transmits to everyone under K_g. Do I have this right? If so, my question is. Why? In particular, why can't we use K_g directly to encrypt SRTP packets (i.e., as one ginormous SRTP session). I am assuming your answer here is going to be that then if you have SSRC collisions then we get two-time pad [0]? If not, then is there some other reason I am missing? -Ekr [0] If so, I have another way to address this. As the media distributor receives the packet, it removes the EKT field, > then decrypts the packet using the keys derived from {K_h,S_h}. It then > re-encrypts the packet using {K_h',S_h'} (where ' denotes the HBH keys > shared with the endpoint to which the media distributor intends to forward > the packet) and then attached the EKT field to the end untouched. > > Upon receipt of the packet, the receiving endpoint first processes the EKT > field. It decrypts the field using K_g. It extracts the SRTP master key > E_i. It already has S_g via the EKTKey message from its own exchange with > the key distributor. So, using its own HBH keying material {K_h',S_h'} > and the E2E keying material {E_i,S_g}, it can perform HBH and E2E > decryption of the packet. > > I hope that helps. As you can see, EKT plays a very limited role in the > overall architecture. We're still very much relying on DTLS-SRTP > procedures and on standard SRTP procedures. Juggling all these keys is > certainly confusing, though. I guess a pretty picture showing all the > pieces would be useful. > > Paul > > ------ Original Message ------ > From: "Eric Rescorla" > To: perc@ietf.org > Sent: 3/21/2017 5:48:17 PM > Subject: [Perc] Question on diet Design? > > I've read this document and I'm finding it hard to understand the > basic design. Ignoring all the details, we have a node i which > connects to the Key Distributor (KD), and we want to establish a > shared key for each node i = 0, 1, ... n (this is just to establish > E2E keys. I'm ignoring HBH keys for now). So, as I read it, the system > works like this. > > - Node i connects to KD and establishes a DTLS connection which establishes > a pairwise key K_d_i. > - The KD then generates a fresh EKT key K_e_i and sends it to i encrypted > under K_d_i. > - The KD then generates a shared group key K_g and sends it individually > to all i in SRTP/EKT encrypted under K_e_i. > > Is that correct so far? > > If so, my question is why you need K_e_i? You have already established > a shared secret via the DTLS connection and you can make as many fresh > pairwise encryption keys as you want from that, so why do you need > to make a new encryption key K_e_i and send it from KD to i? > > -Ekr > > --001a114f12a49cea5c054b468202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 21, 2017 at 4:48 PM, Paul E. Jones <paulej@packetizer.= com> wrote:
Ekr,

For each endpoint, = a HBH key is established using DTLS-SRTP (RFC 5764) procedures via an assoc= iation established between the endpoint and key distributor.=C2=A0 Those pr= ocedures are (mostly) unaltered from the endpoint's perspective and ind= ependent of EKT. =C2=A0 The only aspect that is "alternated" is t= hat, since we're using a "double" cipher, half of the bits ge= nerated for the HBH key are discarded (as they're not used).=C2=A0 In t= he framework document, this is referred to as Key(j).=C2=A0 For simplicity = in keeping your notation below, let's call this K_h.=C2=A0 This is the = SRTP master key. There is also an SRTP master salt S_h created via the DTLS= -SRTP procedures.

Over that DTLS association, the = key distributor will send an "EKTKey" message containing the conf= erence key (what you called the group key, K_g).=C2=A0 The same conference = key is given to each endpoint in the conference.=C2=A0 In the same message,= an SRTP master salt S_g is provided by the key distributor.

Let's ignore salts for now. I'd also = like to ignore all the hop-by-hop keys, because I'm
primarily= concerned with the e2e keys.


As the "EKTKey&= quot; message is transmitted to the endpoint, the values {K_h, S_h} are del= ivered to the media distributor via the tunnel protocol.

At this point, the endpoint has {K_h, S_h, K_g, S_g} and the media d= istributor has=C2=A0{K_h, S_h}.=C2=A0 For every endpoint i, the K_h and S_h value= s differ.

Each endp= oint then manufacturers a random SRTP master key E_i used for E2E encryptio= n.=C2=A0 The endpoint then generates the various keys for RTP encryption, R= TP authentication, RTCP encryption, and RTCP authentication using the KDF d= efined in RFC 3711 from the pair {E_i, S_g}.=C2=A0 This produces k_e, k_a, = k_s (Section 4.3.1 of RFC 3711).=C2=A0 Since we will have these for both E2= E and HBH, let's suffix whese with _e (for E2E).=C2=A0 So, we'll ha= ve K_e_e.

The endpoint then generates the various k= eys for RTP encryption, RTP authentication, RTCP encryption, and RTCP authe= ntication using the KDF defined in RFC 3711 from the pair {K_h, S_h}.=C2=A0= As above, we'll have=C2=A0k_e, k_a, k_s= , which let's suffix as k_e_h (for HBH).
=

The end= point then performs these steps:
=C2=A0 1= ) encrypts the RTP packet using the keys derived via the KDF for E2E, K_e_e= and salt k_s_e.
=C2=A0 2) encrypts the R= TP packet using the keys derives via the KDF for HBH, namely K_e_h and k_s_= h.

The EKT field is then added to the end of the p= acket.=C2=A0 If it's the "short EKT field", it has no keying = material inside. It would just be a single 0 octet.

The long EKT field is used periodically to allow = the endpoint to transmit E_i to other endpoints.=C2=A0 The plaintext of thi= s field is constructed and then encrypted using AESKeyWrap(K_g, ekt_field).= =C2=A0 The ciphertext is then appended to the packet, along with a few plai= ntext fields indicating the field type and length.
=

I'm going to stop here, because I think this is the= relevant point, that I had misunderstood
and I want to summarize= looking just at the E2E portion.

1. You start out= with every agent i having a pairwise key K_d_i (the DTLS traffic key) with= the
KD.

2. The KD then generates a sing= le shared key K_g which it provides to each agent i under
K_d_i (= in DTLS).

2. Each agent then generates its own tra= nsmission key E_i which it transmits to everyone
under K_g.
=

Do I have this right?

If so, m= y question is. Why? In particular, why can't we use K_g directly to enc= rypt SRTP
packets (i.e., as one ginormous SRTP session). I am ass= uming your answer here is going
to be that then if you have SSRC = collisions then we get two-time pad [0]? If not, then
is there so= me other reason I am missing?

-Ekr

<= /div>


[0] If so, I have another way to ad= dress this.














As the m= edia distributor receives the packet, it removes the EKT field, then decryp= ts the packet using the keys derived from {K_h,S_h}.=C2=A0 It then re-encry= pts the packet using {K_h',S_h'} (where ' denotes the HBH keys = shared with the endpoint to which the media distributor intends to forward = the packet) and then attached the EKT field to the end untouched.

Upon receip= t of the packet, the receiving endpoint first processes the EKT field.=C2= =A0 It decrypts the field using K_g.=C2=A0 It extracts the SRTP master key = E_i.=C2=A0 It already has S_g via the EKTKey message from its own exchange = with the key distributor. =C2=A0 So, using its own HBH keying material {K_h= ',S_h'} and the E2E keying material {E_i,S_g}, it can perform HBH a= nd E2E decryption of the packet.

I hope that helps.=C2=A0 As you can see, EKT= plays a very limited role in the overall architecture.=C2=A0 We're sti= ll very much relying on DTLS-SRTP procedures and on standard SRTP procedure= s.=C2=A0 Juggling all these keys is certainly confusing, though.=C2=A0 I gu= ess a pretty picture showing all the pieces would be useful.

Paul

------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com>
Sent: 3/21/2017 5:48:17 PM
Subject: [Perc] Question on diet Design?

I've read this document and I'm finding it ha= rd to understand the
basic design. Ignoring all the details, we h= ave a node i which
connects to the Key Distributor (KD), and we w= ant to establish a
shared key for each node i =3D 0, 1, ... n (th= is is just to establish
E2E keys. I'm ignoring HBH keys for n= ow). So, as I read it, the system
works like this.

=
- Node i connects to KD and establishes a DTLS connection which = establishes
=C2=A0 a pairwise key K_d_i.
- The KD then = generates a fresh EKT key K_e_i and sends it to i encrypted
=C2= =A0 under K_d_i.
- The KD then generates a shared group key K_g a= nd sends it individually
=C2=A0 to all i in SRTP/EKT encrypted un= der K_e_i.

Is that correct so far?

<= /div>
If so, my question is why you need K_e_i? You have already establ= ished
a shared secret via the DTLS connection and you can make as= many fresh
pairwise encryption keys as you want from that, so wh= y do you need
to make a new encryption key K_e_i and send it from= KD to i?

-Ekr


--001a114f12a49cea5c054b468202-- From nobody Tue Mar 21 17:35: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 79BBA129410 for ; Tue, 21 Mar 2017 17:35:36 -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 lfFiBjasSSkg for ; Tue, 21 Mar 2017 17:35:34 -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 69EA7130A97 for ; Tue, 21 Mar 2017 17:35:33 -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 v2M0ZVAr020368 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Mar 2017 20:35:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490142932; bh=dUx49EjhmJkE7nl8c2aORQq9kmpjZWgQaZydaRgoOzw=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=onOI0fipu/tAtECR9gnBfX82E7+YIwf0C+zQfXLFBidp0Y50qrZ0rXyE856A9B19U 4vtXc0cqq/rLEjWGZ9sXj08SY8H1ivVZ44TXzvXOqhi2KEgFz9UBHRIRvrnmO7rS7y IQaxoDlvHsACbjrl/fF+ZIrYuAqKZdDgFwyF79m8= From: "Paul E. Jones" To: "Eric Rescorla" Cc: perc@ietf.org Date: Wed, 22 Mar 2017 00:35:32 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB36F73331-2D13-4404-8F09-FDE6561E1A39" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Tue, 21 Mar 2017 20:35:32 -0400 (EDT) Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 22 Mar 2017 00:35:36 -0000 --------=_MB36F73331-2D13-4404-8F09-FDE6561E1A39 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ekr, >> >>Each endpoint then manufacturers a random SRTP master key E_i used for=20 >>E2E encryption. The endpoint then generates the various keys for RTP=20 >>encryption, RTP authentication, RTCP encryption, and RTCP=20 >>authentication using the KDF defined in RFC 3711 from the pair {E_i,=20 >>S_g}. This produces k_e, k_a, k_s (Section 4.3.1 of RFC 3711). Since=20 >>we will have these for both E2E and HBH, let's suffix whese with _e=20 >>(for E2E). So, we'll have K_e_e. >> >>The endpoint then generates the various keys for RTP encryption, RTP=20 >>authentication, RTCP encryption, and RTCP authentication using the KDF=20 >>defined in RFC 3711 from the pair {K_h, S_h}. As above, we'll have=20 >>k_e, k_a, k_s, which let's suffix as k_e_h (for HBH). >> >>The endpoint then performs these steps: >> 1) encrypts the RTP packet using the keys derived via the KDF for=20 >>E2E, K_e_e and salt k_s_e. >> 2) encrypts the RTP packet using the keys derives via the KDF for=20 >>HBH, namely K_e_h and k_s_h. >> >>The EKT field is then added to the end of the packet. If it's the=20 >>"short EKT field", it has no keying material inside. It would just be=20 >>a single 0 octet. >> >>The long EKT field is used periodically to allow the endpoint to=20 >>transmit E_i to other endpoints. The plaintext of this field is=20 >>constructed and then encrypted using AESKeyWrap(K_g, ekt_field). The=20 >>ciphertext is then appended to the packet, along with a few plaintext=20 >>fields indicating the field type and length. > >I'm going to stop here, because I think this is the relevant point,=20 >that I had misunderstood >and I want to summarize looking just at the E2E portion. > >1. You start out with every agent i having a pairwise key K_d_i (the=20 >DTLS traffic key) with the >KD. Yea, but the key is only used for DTLS exchanges, so independent of=20 anything SRTP related (except for the DTLS-SRTP key derivation for HBH=20 that you wanted to ignore for now). >2. The KD then generates a single shared key K_g which it provides to=20 >each agent i under >K_d_i (in DTLS). Correct. >2. Each agent then generates its own transmission key E_i which it=20 >transmits to everyone >under K_g. > >Do I have this right? Yes, that's correct. >If so, my question is. Why? In particular, why can't we use K_g=20 >directly to encrypt SRTP >packets (i.e., as one ginormous SRTP session). I am assuming your=20 >answer here is going >to be that then if you have SSRC collisions then we get two-time pad=20 >[0]? If not, then >is there some other reason I am missing? Avoiding the one-time pad is a primary concern, but not the only issue. =20 A secondary issue is that in a conferencing environment where each=20 sender is transmitting independently, endpoints need to be able to=20 synchronize the crypto context of the sender. The ROC value is conveyed=20 in the EKT field, which facilitates this synchronization. (The ROC for=20 the HBH encryption always starts at 0, so no synchronization is=20 required. But, the ROC for any transmitted flow in an existing=20 conferencing might be any value. So, EKT carries the E2E cipher and the=20 ROC for that flow.) >[0] If so, I have another way to address this. > Assuming we could still convey the ROC in the clear (it's not really=20 secret), then I'd like to hear your suggestion. I'll note that there was an alternative some time ago=20 (draft-mcgrew-srtp-aero), but that work did not progress. Since I=20 wasn't involved, I do not know why. Perhaps because it moved away from=20 SRTP and defining an SRTP replacement would have been a pretty high=20 barrier? Paul --------=_MB36F73331-2D13-4404-8F09-FDE6561E1A39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ekr,


Each endpoint then manufacturers a random SRTP master key E_i used for= E2E encryption.=C2=A0 The endpoint then generates the various keys for RTP= encryption, RTP authentication, RTCP encryption, and RTCP authentication us= ing the KDF defined in RFC 3711 from the pair {E_i, S_g}.=C2=A0 This produc= es k_e, k_a, k_s (Section 4.3.1 of RFC 3711).=C2=A0 Since we will have thes= e for both E2E and HBH, let's suffix whese with _e (for E2E).=C2=A0 So, we'= ll have K_e_e.

The endpoint then generates the various k= eys for RTP encryption, RTP authentication, RTCP encryption, and RTCP authe= ntication using the KDF defined in RFC 3711 from the pair {K_h, S_h}.=C2=A0 = As above, we'll have=C2=A0k_e, k_a, k_s, wh= ich let's suffix as k_e_h (for HBH).

The endpoint= then performs these steps:
=C2=A0 1) encr= ypts the RTP packet using the keys derived via the KDF for E2E, K_e_e and s= alt k_s_e.
=C2=A0 2) encrypts the RTP pac= ket using the keys derives via the KDF for HBH, namely K_e_h and k_s_h.

The EKT field is then added to the end of the packe= t.=C2=A0 If it's the "short EKT field", it has no keying material inside. I= t would just be a single 0 octet.

The long EKT field is used periodically to allow the endpoint to= transmit E_i to other endpoints.=C2=A0 The plaintext of this field is const= ructed and then encrypted using AESKeyWrap(K_g, ekt_field).=C2=A0 The ciphe= rtext is then appended to the packet, along with a few plaintext fields ind= icating the field type and length.

I'm going to stop here, because I think this is the relevant point, t= hat I had misunderstood
and I want to summarize looking just at t= he E2E portion.

1. You start out with every agen= t i having a pairwise key K_d_i (the DTLS traffic key) with the
K= D.

<= /div>
Yea, but the key is only used for DTLS ex= changes, so independent of anything SRTP related (except for the DTLS-SRTP= key derivation for HBH that you wanted to ignore for now).


2. The KD then generates a single = shared key K_g which it provides to each agent i under
K_= d_i (in DTLS).

Correct.


=
2. Each agent then generates its own= transmission key E_i which it transmits to everyone
under= K_g.

Do I have this right?

Yes, that's correct.


<= div class=3D"gmail_extra">
If so, my question is. Why? In particular, why can't we use = K_g directly to encrypt SRTP
packets (i.e., as one ginorm= ous SRTP session). I am assuming your answer here is going
to be= that then if you have SSRC collisions then we get two-time pad [0]? If not, = then
is there some other reason I am missing?
<= /div>

Avoiding the one-time pad is a prima= ry concern, but not the only issue. =C2=A0A secondary issue is that in a co= nferencing environment where each sender is transmitting independently, end= points need to be able to synchronize the crypto context of the sender. =C2= =A0The ROC value is conveyed in the EKT fi= eld, which facilitates this synchronization. =C2=A0(The ROC for the HBH enc= ryption always starts at 0, so no synchronization is required. =C2=A0But, t= he ROC for any transmitted flow in an existing conferencing might be any va= lue. =C2=A0So, EKT carries the E2E cipher and the ROC for that flow.)


[0] If so, I ha= ve another way to address this.


Assuming we could still convey the ROC in the clear (it's not r= eally secret), then I'd like to hear your suggestion.

I'll note that there= was an alternative some time ago (draft-mc= grew-srtp-aero), but that work did not progress. =C2=A0Since I wasn't invol= ved, I do not know why. =C2=A0Perhaps because it moved away from SRTP and d= efining an SRTP replacement would have been a pretty high barrier?

Pau= l

--------=_MB36F73331-2D13-4404-8F09-FDE6561E1A39-- From nobody Tue Mar 21 17:57:25 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 9B9AD1241FC for ; Tue, 21 Mar 2017 17:57:23 -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] 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 MWJ4fGlZTmpE for ; Tue, 21 Mar 2017 17:57:21 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219E91292F4 for ; Tue, 21 Mar 2017 17:57:21 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id a12so92379213ota.0 for ; Tue, 21 Mar 2017 17:57:21 -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=WCjCwX7t7baGL0pDFlBGTnTgp9Knq36QfIGo/O8B+OY=; b=nUFCFJCssMTQ44WR2gp5MTgjMfFHp3cjTFItg/mms75f5uWuThZwWXUbIBe81TFsgh A4g1iSJABMfrPTSWCl7G+8l17PYEcsGopXbaDw/1uzZt7gLh7mmhB+MEWWeIP3Nfg/Jd NZ8UOh6jBQAjqtAQPR0UrFsOoUSkp6vtp4eEbX7JfL2Of6lqV46EdFPjjw/9XI7mWV5C Iq1Ar4RXPEBSpF0TLDucstPzMoAzyeZuocZ7rDmgolDyqiJtxq35/VB64EF69rEVMmhp Y31kbpN/e3GlRTxPUbMsr2suOOpwiygpk1yVAbmKWQVsHwdvOd71yewvu99q/Fh07DAN HGEA== 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=WCjCwX7t7baGL0pDFlBGTnTgp9Knq36QfIGo/O8B+OY=; b=CpKP2WBNthNCKqe64m5jHbEYRvEYr4tOPdiq2MNDElqQ+X2mmKJ4nYdCq8mFfV9ZWq dcBoKE1jFwMytZFc0A1sYxDyPVR01VH0muqv4t0qvMlkUy8N8k8kwq3EgZ8TU59+oR2p OjIXYQ90NSeyMniYiMJ20SF7+PFDx2ke3Xwxqy/hYaFpUfcvCZ9DAaX/fQLPLc8NZ8sK rTRrTe9VsoIAWr4OwhOmB9NDoFDAHoegrqNgOz72pYpQninlCWUm7W9+QJx6bn9ocP+g pXKaQMY3DSgB3hZffDDZ6r7lFPNOFTlj6y3ClM2jpAblhjFQQjTeCAYm7SnVmg8tXri4 gY7g== X-Gm-Message-State: AFeK/H3o7Fy6iabrKUR3EL6JuTQMunK4DLABRnWlN2jZAPV1gNYNsWor6/aeEF5Q2tPJbzb5pdMdo6tvOIVkFg== X-Received: by 10.157.68.234 with SMTP id p42mr19148758otg.46.1490144240461; Tue, 21 Mar 2017 17:57:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.167 with HTTP; Tue, 21 Mar 2017 17:56:40 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 21 Mar 2017 17:56:40 -0700 Message-ID: To: "Paul E. Jones" Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=f403043c50201dfdf9054b473e91 Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 22 Mar 2017 00:57:24 -0000 --f403043c50201dfdf9054b473e91 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 21, 2017 at 5:35 PM, Paul E. Jones wrote: > Ekr, > > >> Each endpoint then manufacturers a random SRTP master key E_i used for >> E2E encryption. The endpoint then generates the various keys for RTP >> encryption, RTP authentication, RTCP encryption, and RTCP authentication >> using the KDF defined in RFC 3711 from the pair {E_i, S_g}. This produces >> k_e, k_a, k_s (Section 4.3.1 of RFC 3711). Since we will have these for >> both E2E and HBH, let's suffix whese with _e (for E2E). So, we'll have >> K_e_e. >> >> The endpoint then generates the various keys for RTP encryption, RTP >> authentication, RTCP encryption, and RTCP authentication using the KDF >> defined in RFC 3711 from the pair {K_h, S_h}. As above, we'll have k_e, >> k_a, k_s, which let's suffix as k_e_h (for HBH). >> >> The endpoint then performs these steps: >> 1) encrypts the RTP packet using the keys derived via the KDF for E2E, >> K_e_e and salt k_s_e. >> 2) encrypts the RTP packet using the keys derives via the KDF for HBH, >> namely K_e_h and k_s_h. >> >> The EKT field is then added to the end of the packet. If it's the "short >> EKT field", it has no keying material inside. It would just be a single 0 >> octet. >> >> The long EKT field is used periodically to allow the endpoint to transmit >> E_i to other endpoints. The plaintext of this field is constructed and >> then encrypted using AESKeyWrap(K_g, ekt_field). The ciphertext is then >> appended to the packet, along with a few plaintext fields indicating the >> field type and length. >> > > I'm going to stop here, because I think this is the relevant point, that I > had misunderstood > and I want to summarize looking just at the E2E portion. > > 1. You start out with every agent i having a pairwise key K_d_i (the DTLS > traffic key) with the > KD. > > > Yea, but the key is only used for DTLS exchanges, so independent of > anything SRTP related (except for the DTLS-SRTP key derivation for HBH that > you wanted to ignore for now). > Well, you're using it to encipher K_g. Right now, I'm primarily concerned with the key hierarchy and not which specific protocol is being used. 2. The KD then generates a single shared key K_g which it provides to each > agent i under > K_d_i (in DTLS). > > > Correct. > > > 2. Each agent then generates its own transmission key E_i which it > transmits to everyone > under K_g. > > Do I have this right? > > > Yes, that's correct. > > > If so, my question is. Why? In particular, why can't we use K_g directly > to encrypt SRTP > packets (i.e., as one ginormous SRTP session). I am assuming your answer > here is going > to be that then if you have SSRC collisions then we get two-time pad [0]? > If not, then > is there some other reason I am missing? > > > Avoiding the one-time pad is a primary concern, but not the only issue. A > secondary issue is that in a conferencing environment where each sender is > transmitting independently, endpoints need to be able to synchronize the > crypto context of the sender. The ROC value is conveyed in the EKT > field, which facilitates this synchronization. (The ROC for the HBH > encryption always starts at 0, so no synchronization is required. But, the > ROC for any transmitted flow in an existing conferencing might be any > value. So, EKT carries the E2E cipher and the ROC for that flow.) > > > [0] If so, I have another way to address this. > > > Assuming we could still convey the ROC in the clear (it's not really > secret), then I'd like to hear your suggestion. > Replace EKT with a fixed block consisting of: 1. A centrally assigned endpoint ID [you need this to avoid two-time pad] 2. The ROC (if needed) The per-sender key then can be computed as KDF(K_g, ID) [0]. Note that you don't need to send this block that frequently, you can use the same algorithm you use for EKT, though it's also pretty small, so maybe easier to just send all the time. I haven't been thinking about this for very long, so I could of course have something grievously wrong and insecure, in which people should point and laugh. One potential concern is that an attacker can send some incredibly large ROC and thus cause you to crank the KDF forward a zillion times. I believe that currently anyone who has K_g can do this, so requiring this block to be MACed with K_g should address this problem. -Ekr [0] Note, this assumes I am remembering how the ROC works, which, IIRC, is just that it tells you which generation of SRTP keys to derive from the master. --f403043c50201dfdf9054b473e91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 21, 2017 at 5:35 PM, Paul E. Jones <paulej@packetizer.= com> wrote:
Ekr,


Each en= dpoint then manufacturers a random SRTP master key E_i used for E2E encrypt= ion.=C2=A0 The endpoint then generates the various keys for RTP encryption,= RTP authentication, RTCP encryption, and RTCP authentication using the KDF= defined in RFC 3711 from the pair {E_i, S_g}.=C2=A0 This produces k_e, k_a= , k_s (Section 4.3.1 of RFC 3711).=C2=A0 Since we will have these for both = E2E and HBH, let's suffix whese with _e (for E2E).=C2=A0 So, we'll = have K_e_e.

The endpoint then generates the various k= eys for RTP encryption, RTP authentication, RTCP encryption, and RTCP authe= ntication using the KDF defined in RFC 3711 from the pair {K_h, S_h}.=C2=A0= As above, we'll have=C2=A0k_e, k_a, k_s= , which let's suffix as k_e_h (for HBH).
=

The end= point then performs these steps:
=C2=A0 1= ) encrypts the RTP packet using the keys derived via the KDF for E2E, K_e_e= and salt k_s_e.
=C2=A0 2) encrypts the R= TP packet using the keys derives via the KDF for HBH, namely K_e_h and k_s_= h.

The EKT field is then added to the end of the p= acket.=C2=A0 If it's the "short EKT field", it has no keying = material inside. It would just be a single 0 octet.

The long EKT field is used periodically to allow = the endpoint to transmit E_i to other endpoints.=C2=A0 The plaintext of thi= s field is constructed and then encrypted using AESKeyWrap(K_g, ekt_field).= =C2=A0 The ciphertext is then appended to the packet, along with a few plai= ntext fields indicating the field type and length.
=

I'm going to stop here, because I think this is the= relevant point, that I had misunderstood
and I want to summarize= looking just at the E2E portion.

1. You start out= with every agent i having a pairwise key K_d_i (the DTLS traffic key) with= the
KD.

Yea, but the key is only used for DTLS exchanges, so in= dependent of anything SRTP related (except for the DTLS-SRTP key derivation= for HBH that you wanted to ignore for now).
=
=C2=A0

Well, you're using it to encipher = K_g. Right now, I'm primarily concerned with the key hierarchy
and not which specific protocol is being used.

2. The KD then generat= es a single shared key K_g which it provides to each agent i under
K_d_i (in DTLS).

Correct.


2. Each agent then generates its own transmission key E_i which it tra= nsmits to everyone
under K_g.

Do = I have this right?

Yes, that's correct.


If so, my question is. Why? In particular, why can't we use= K_g directly to encrypt SRTP
packets (i.e., as one ginorm= ous SRTP session). I am assuming your answer here is going
to be = that then if you have SSRC collisions then we get two-time pad [0]? If not,= then
is there some other reason I am missing?
<= /div>

Avoiding the one-time pad is a primary concern, but not the only iss= ue.=C2=A0 A secondary issue is that in a conferencing environment where eac= h sender is transmitting independently, endpoints need to be able to synchr= onize the crypto context of the sender. =C2=A0The ROC value is conveyed in the EKT field, which facilitates this synchr= onization. =C2=A0(The ROC for the HBH encryption always starts at 0, so no = synchronization is required.=C2=A0 But, the ROC for any transmitted flow in= an existing conferencing might be any value.=C2=A0 So, EKT carries the E2E= cipher and the ROC for that flow.)


[0] If so, I have another way to address this.

Assuming we could still convey the ROC in the clear (it's not reall= y secret), then I'd like to hear your suggestion.

Replace EKT with a fixed block consisting of:<= br>

1. A centrally assigned endpoint ID [you need = this to avoid two-time pad]
2. The ROC (if needed)

=
The per-sender key then can be computed as KDF(K_g, ID) [0]. Not= e that you don't need to
send this block that frequently, you= can use the same algorithm you use for EKT, though it's
also= pretty small, so maybe easier to just send all the time.=C2=A0
<= br>
I haven't been thinking about this for very long, so I co= uld of course have something grievously
wrong and insecure, in wh= ich people should point and laugh. One potential concern is
that = an attacker can send some incredibly large ROC and thus cause you to crank = the KDF
forward a zillion times. I believe that currently anyone = who has K_g can do this, so requiring
this block to be MACed with= K_g should address this problem.

-Ekr
<= br>
[0] Note, this assumes I am remembering how the ROC works, wh= ich, IIRC, is
just that it tells you which generation of SRTP key= s to derive from the master.




--f403043c50201dfdf9054b473e91-- From nobody Wed Mar 22 10:42: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 B187A129BB5 for ; Wed, 22 Mar 2017 10:42:47 -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 Gx5mDSxN6cQh for ; Wed, 22 Mar 2017 10:42:46 -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 DD902129B81 for ; Wed, 22 Mar 2017 10:42:45 -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 v2MHgiXZ013874 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Mar 2017 13:42:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490204564; bh=i/f9Bk9w24LG8JX2CP+Z/NJjwSt9eOvZukY8HkNxGKY=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=e3XTI0TRLe+giIgb+myeS89NDU0BJlTTPsszHsxHbQyb4XP3P9vqXwim6l6KCqbxn 1/jS85lW8UFgxZ/R5Gqu2rQF4yzrqVzugn5yMELwAL9XnxcAXK+ek3uK+sOA5Ji9gf zGWb1CsrqGVhHvaXNJusQtLnWDZjmHvl0Wyhc/MU= From: "Paul E. Jones" To: "Eric Rescorla" Cc: perc@ietf.org Date: Wed, 22 Mar 2017 17:42:46 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBDA9245E9-BC38-4D68-8DF1-9C7C49381DA1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Wed, 22 Mar 2017 13:42:44 -0400 (EDT) Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 22 Mar 2017 17:42:48 -0000 --------=_MBDA9245E9-BC38-4D68-8DF1-9C7C49381DA1 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ekr, >> >>Assuming we could still convey the ROC in the clear (it's not really=20 >>secret), then I'd like to hear your suggestion. > >Replace EKT with a fixed block consisting of: > >1. A centrally assigned endpoint ID [you need this to avoid two-time=20 >pad] >2. The ROC (if needed) > >The per-sender key then can be computed as KDF(K_g, ID) [0]. Note that=20 >you don't need to >send this block that frequently, you can use the same algorithm you use=20 >for EKT, though it's >also pretty small, so maybe easier to just send all the time. > >I haven't been thinking about this for very long, so I could of course=20 >have something grievously >wrong and insecure, in which people should point and laugh. One=20 >potential concern is >that an attacker can send some incredibly large ROC and thus cause you=20 >to crank the KDF >forward a zillion times. I believe that currently anyone who has K_g=20 >can do this, so requiring >this block to be MACed with K_g should address this problem. > >-Ekr > >[0] Note, this assumes I am remembering how the ROC works, which, IIRC,=20 >is >just that it tells you which generation of SRTP keys to derive from the=20 >master. I think what you propose would work, but each stream from a given=20 endpoint would need to have a unique key since we do not want the any=20 two media flows using the same key. Thus, I think we'd need: KDF(K_g, ID || stream_id) The ID, steam_id, and ROC values would need to be conveyed in the RTP=20 packet (or RTCP packet -- though I'd prefer to try to avoid putting such=20 info into RTCP) to ensure that the receiver gets the information it=20 needs to decrypt the flow. So, it's not clear that there is an=20 advantage to this approach. The size of the EKT field might be smaller,=20 but we could make it smaller now if we wanted (removing extensibility=20 and length fields). Perhaps I'm missing an important advantage? Paul --------=_MBDA9245E9-BC38-4D68-8DF1-9C7C49381DA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ekr,


Assuming we could still convey t= he ROC in the clear (it's not really secret), then I'd like to hear your su= ggestion.

Replace EKT w= ith a fixed block consisting of:

1. A cent= rally assigned endpoint ID [you need this to avoid two-time pad]
= 2. The ROC (if needed)

The per-sender key then c= an be computed as KDF(K_g, ID) [0]. Note that you don't need to
s= end this block that frequently, you can use the same algorithm you use for= EKT, though it's
also pretty small, so maybe easier to just send= all the time.=C2=A0

I haven't been thinking abou= t this for very long, so I could of course have something grievously
<= div>wrong and insecure, in which people should point and laugh. One potenti= al concern is
that an attacker can send some incredibly large ROC = and thus cause you to crank the KDF
forward a zillion times. I b= elieve that currently anyone who has K_g can do this, so requiring
this block to be MACed with K_g should address this problem.
-Ekr

[0] Note, this assumes I am= remembering how the ROC works, which, IIRC, is
just that it tells = you which generation of SRTP keys to derive from the master.

I think what you propose would work, b= ut each stream from a given endpoint would need to have a unique key since= we do not want the any two media flows using the same key. Thus, I think we= 'd need:
=C2=A0 KDF(K_g, ID || st= ream_id)

The ID, steam_id, and ROC values = would need to be conveyed in the RTP packet (or RTCP packet -- though I'd= prefer to try to avoid putting such info into RTCP) to ensure that the rece= iver gets the information it needs to decrypt the flow. =C2=A0So, it's not= clear that there is an advantage to this approach. =C2=A0The size of the EK= T field might be smaller, but we could make it smaller now if we wanted (re= moving extensibility and length fields).

Perhaps I'm missing an important advantage?

Paul

--------=_MBDA9245E9-BC38-4D68-8DF1-9C7C49381DA1-- From nobody Wed Mar 22 11:34:44 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 1BD0B12986E for ; Wed, 22 Mar 2017 11:34:43 -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 Fzb8dCqTWvr1 for ; Wed, 22 Mar 2017 11:34:41 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 84BF91294E1 for ; Wed, 22 Mar 2017 11:34:41 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id v76so133074103ywg.0 for ; Wed, 22 Mar 2017 11:34:41 -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=92BfiFlydZMqIpCeYPK8JqdygrQEEDn+yo1hCz/TrLQ=; b=fShj8xveGzGtZzelz3zXs/Ft9+MefISvf7Fm4W3pGRmShpeENgKQzJIB9X0c0pPQOT 7dYk1BiyzoTxsDxV2bARoSpFZCQ30C+70kdRrEUTilxp6jZjd8LW0FtHdynvpkV2+FlP 4rAo80TVXPG5/dMgGxzFl54vBXYNTp75RRaMVo8aI8++r7oMzMr7ZzoTUGL8Awib9sbE DgygNk09Va92YF1PdEYXEFF/VyilHmy74lhoaBsfQ6WqnYqYVmiTEIK43oy8zRQC8yjL KRzbBn4UCHzLHtZNEEd+5RyHqSJQ8kRDmcvOwKh6EUvoKz5hYkEqoyJw6T34jw/Dp8yq bAYw== 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=92BfiFlydZMqIpCeYPK8JqdygrQEEDn+yo1hCz/TrLQ=; b=D2/7NwKFaCXBE99LCOxqowKnILAC+IQyJI3bAa94Xh29nMoKRFwT/pBWW+TGI6CU94 jCB8yleCnVChnlh2pttWMLZR/1wo7QrZZEKMXDXNJ+MKVnu9lnFGwDNFcp3lOZMZ5+Mh xaETi0bA1hxo50A79NFiEQPAVOBBsLzyN/iJLrl50Gwxni49oqUR+bQwBlUSwzn/jn2l 3d8kn4fXyp/0bN6VYD4mqGw3vIKWzNWppOjtAzdJ5PNuAO9k1ZU7rpwPglzzqQ7mzNq5 Y0K6+e2PDBV5a2G+4rtunKT097sD4o86HyLB9MAlrzVGmnOikuUlM4NITxECTg+xHGsr 8wVA== X-Gm-Message-State: AFeK/H1fzpKRjULEGB7aFlrM/ahh1dm6c4l1ARTFMgYxOW4KgPAgM6oL0uTr1GPr2WiW2cakhNLxVlwnOAzfeA== X-Received: by 10.37.224.81 with SMTP id x78mr26985499ybg.80.1490207680624; Wed, 22 Mar 2017 11:34:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 22 Mar 2017 11:33:59 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 22 Mar 2017 11:33:59 -0700 Message-ID: To: "Paul E. Jones" Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0873587270c5054b5603ea Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 22 Mar 2017 18:34:43 -0000 --94eb2c0873587270c5054b5603ea Content-Type: text/plain; charset=UTF-8 On Wed, Mar 22, 2017 at 10:42 AM, Paul E. Jones wrote: > Ekr, > > >> Assuming we could still convey the ROC in the clear (it's not really >> secret), then I'd like to hear your suggestion. >> > > Replace EKT with a fixed block consisting of: > > 1. A centrally assigned endpoint ID [you need this to avoid two-time pad] > 2. The ROC (if needed) > > The per-sender key then can be computed as KDF(K_g, ID) [0]. Note that you > don't need to > send this block that frequently, you can use the same algorithm you use > for EKT, though it's > also pretty small, so maybe easier to just send all the time. > > I haven't been thinking about this for very long, so I could of course > have something grievously > wrong and insecure, in which people should point and laugh. One potential > concern is > that an attacker can send some incredibly large ROC and thus cause you to > crank the KDF > forward a zillion times. I believe that currently anyone who has K_g can > do this, so requiring > this block to be MACed with K_g should address this problem. > > -Ekr > > [0] Note, this assumes I am remembering how the ROC works, which, IIRC, is > just that it tells you which generation of SRTP keys to derive from the > master. > > > I think what you propose would work, but each stream from a given endpoint > would need to have a unique key since we do not want the any two media > flows using the same key. Thus, I think we'd need: > KDF(K_g, ID || stream_id) > The SSRC addresses that, no? -Ekr The ID, steam_id, and ROC values would need to be conveyed in the RTP > packet (or RTCP packet -- though I'd prefer to try to avoid putting such > info into RTCP) to ensure that the receiver gets the information it needs > to decrypt the flow. So, it's not clear that there is an advantage to this > approach. The size of the EKT field might be smaller, but we could make it > smaller now if we wanted (removing extensibility and length fields). > > Perhaps I'm missing an important advantage? > > Paul > > --94eb2c0873587270c5054b5603ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 22, 2017 at 10:42 AM, Paul E. Jones <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:
Ekr,


Assuming we co= uld still convey the ROC in the clear (it's not really secret), then I&= #39;d like to hear your suggestion.

=
Replace EKT with a fixed block consisting of:

=
1. A centrally assigned endpoint ID [you need this to avoid two-= time pad]
2. The ROC (if needed)

The per= -sender key then can be computed as KDF(K_g, ID) [0]. Note that you don'= ;t need to
send this block that frequently, you can use the same = algorithm you use for EKT, though it's
also pretty small, so = maybe easier to just send all the time.=C2=A0

I ha= ven't been thinking about this for very long, so I could of course have= something grievously
wrong and insecure, in which people should = point and laugh. One potential concern is
that an attacker can se= nd some incredibly large ROC and thus cause you to crank the KDF
= forward a zillion times. I believe that currently anyone who has K_g can do= this, so requiring
this block to be MACed with K_g should addres= s this problem.

-Ekr

[0] = Note, this assumes I am remembering how the ROC works, which, IIRC, is
just that it tells you which generation of SRTP keys to derive from t= he master.

I think what you propose would work, but= each stream from a given endpoint would need to have a unique key since we= do not want the any two media flows using the same key. Thus, I think we&#= 39;d need:
=C2=A0 KDF(K_g, ID || st= ream_id)

The = SSRC addresses that, no?

-Ekr

=
The ID, steam_id, and ROC values = would need to be conveyed in the RTP packet (or RTCP packet -- though I'= ;d prefer to try to avoid putting such info into RTCP) to ensure that the r= eceiver gets the information it needs to decrypt the flow.=C2=A0 So, it'= ;s not clear that there is an advantage to this approach.=C2=A0 The size of= the EKT field might be smaller, but we could make it smaller now if we wan= ted (removing extensibility and length fields).

Perhaps I'm missing = an important advantage?

=


Paul<= /div>


--94eb2c0873587270c5054b5603ea-- From nobody Wed Mar 22 21:42: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 E151E12943D for ; Wed, 22 Mar 2017 21:42:10 -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 zsWUb2YfnA92 for ; Wed, 22 Mar 2017 21:42:09 -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 67FC112943A for ; Wed, 22 Mar 2017 21:42:09 -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 v2N4g7T8005873 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 00:42:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490244128; bh=Cf+TVcagLwwvMkcxdDdjG+h3uAexG6ffFMtswQzUQoc=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=KqzYZ5cV+Es+w1xGK2WGG/62f83we/p+dcmgP1jLX//bttYZLZyA7mQAxmQgNV6GC SBIyuLUyCIJOEfB7VeFt/Lwk8aIVAm4hzdRNiC+x9De6yqyWvM0/b6Wqb8wqTEt/R0 XyfIXS1Dccd/QJl3tAqlHo7cH/W30i5F5xaBhURA= From: "Paul E. Jones" To: "Eric Rescorla" Cc: perc@ietf.org Date: Thu, 23 Mar 2017 04:42:07 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB310DFA81-53F7-4AF1-8033-B0CB196EA413" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 23 Mar 2017 00:42:08 -0400 (EDT) Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 23 Mar 2017 04:42:11 -0000 --------=_MB310DFA81-53F7-4AF1-8033-B0CB196EA413 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric, >>I think what you propose would work, but each stream from a given=20 >>endpoint would need to have a unique key since we do not want the any=20 >>two media flows using the same key. Thus, I think we'd need: >> KDF(K_g, ID || stream_id) > >The SSRC addresses that, no? Yeah, SSRC is fine for that. We just need to ensure it is a part of the=20 KDF input. Paul --------=_MB310DFA81-53F7-4AF1-8033-B0CB196EA413 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eric,

I think what you propose would work, but = each stream from a given endpoint would need to have a unique key since we = do not want the any two media flows using the same key. Thus, I think we'd = need:
=C2=A0 KDF(K_g, ID || stream= _id)

The SS= RC addresses that, no?

Yeah, SSRC is fine for that. =C2=A0We just need to ensure it is a part = of the KDF input.

Paul=
--------=_MB310DFA81-53F7-4AF1-8033-B0CB196EA413-- From nobody Thu Mar 23 04:13: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 0CB8C131591 for ; Thu, 23 Mar 2017 04:13:35 -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=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 0m_GBrnAu3TQ for ; Thu, 23 Mar 2017 04:13:33 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 12CD813158C for ; Thu, 23 Mar 2017 04:13:33 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id p77so143792913ywg.1 for ; Thu, 23 Mar 2017 04:13:33 -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=AXOHg7MQW/b1Jwl5GfWQ7jwblIdK9iSlcet/yq8E2EI=; b=dSQJhUGOZl7NWECI/b4175JLV9WyogFpmtkdc/ON2XFdS0xA9ekXJ2WO1/HyMpENjl TeaO/bJSfO2G9WcwpPbj613azPPgw95ng+xGGChzuq70HjH8/LFmPh5Xzv72dt3ancKl d5wutWGjHGdWS/NMEJhckMiwTuqOk5fIA7Rf3tb2h40oCjFrQpZlFHYUHouU9j77W/3O vy/+kxBgB+pVwAFtKosL097nxLfvMZ+SNzif6v/KEzZBPB4m10S2mjUZIPT6/pC7kraM euTZTvtm6UcSSIGAdZgvTrzGSWsLH85HXUnX2fxh/PSc54P2g0aNyNSI82M7j66kWM5P WJtg== 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=AXOHg7MQW/b1Jwl5GfWQ7jwblIdK9iSlcet/yq8E2EI=; b=pvqqNCQF0TntJZSdxVdhtJELGIrWVcvKQw/uwTwsx1F4Qbh6np6Oe/gyqJ3BkF2pXo 9SYyxEdEzrjUGc+V1jno5T8D6vZmxCwjV82emdYia4DBtbEqyU1KQ9wqq8GQ0dSUbEKh HYb20i9f+4Ofc7A/eYMvKWbh2COk6XILbbLr6cohvnF9K2ZAse9QCLJO6JEvz/7NOXCs 8kWK3Xr6BGbhSVoKybKCSrFOKwoFXrUjQxrIgAL/cFTP5VBEeqrsNyvj9omrZ8VVUM6k 2wiYe8Vg/DWTv4FZqkofsxiZexmCSTj6/CN/LdFfZWyP4JBzyZF7EnQfqFzHwaPhHA9n pTPA== X-Gm-Message-State: AFeK/H2klTkMgDUWHWM9snzAW5bUtwQluNYcOdgP6QWn7y47Pi2xNuiEnl43BCHq2dQmA2W+aLfi0BJ0eWeQng== X-Received: by 10.37.115.201 with SMTP id o192mr1295041ybc.107.1490267612319; Thu, 23 Mar 2017 04:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 23 Mar 2017 04:12:51 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 23 Mar 2017 04:12:51 -0700 Message-ID: To: "Paul E. Jones" Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c097eb2a73260054b63f72e Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 23 Mar 2017 11:13:35 -0000 --94eb2c097eb2a73260054b63f72e Content-Type: text/plain; charset=UTF-8 It's part of the SRTP KDF. -Ekr On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones wrote: > Eric, > > I think what you propose would work, but each stream from a given endpoint >> would need to have a unique key since we do not want the any two media >> flows using the same key. Thus, I think we'd need: >> KDF(K_g, ID || stream_id) >> > > The SSRC addresses that, no? > > > Yeah, SSRC is fine for that. We just need to ensure it is a part of the > KDF input. > > Paul > --94eb2c097eb2a73260054b63f72e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's part of the SRTP KDF.

-Ekr


On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones <= paulej@packetize= r.com> wrote:
<= div>Eric,

I think what you propose would work, but= each stream from a given endpoint would need to have a unique key since we= do not want the any two media flows using the same key. Thus, I think we&#= 39;d need:
=C2=A0 KDF(K_g, ID || st= ream_id)

The = SSRC addresses that, no?

Yeah, SSRC is fine for = that.=C2=A0 We just need to ensure it is a part of the KDF input.

Paul
=

--94eb2c097eb2a73260054b63f72e-- From nobody Thu Mar 23 16:31: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 9AFF7129991 for ; Thu, 23 Mar 2017 16:31: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, 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 HkqewpBsj6GJ for ; Thu, 23 Mar 2017 16:31:09 -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 34A201273E2 for ; Thu, 23 Mar 2017 16:31:09 -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 v2NNV7og011732 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 19:31:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490311868; bh=ORdO6ut8WsXsHn8ct0tueyl4ANYD8YRfWL6tQlcs1eo=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=SrLmvlwYVDsZed+2CqQJtvYcxlEWMNb9iCdGZkv8Vf2EMnkCMtT2UJkHgbE2m0gpa iLDz9zBKOsvAU60sVS1Vl1NfmO0hOmYteHcVxhtb1Dv2dsA9j5QrwPEoP6x+lacRO5 ZXFFU0RIv9pNYA8VfRFYXCDt/feLhqmsw4ffTMCM= From: "Paul E. Jones" To: "Eric Rescorla" Cc: perc@ietf.org Date: Thu, 23 Mar 2017 23:31:09 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBA7094869-EA45-4D72-98AD-2332E7CBEA07" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 23 Mar 2017 19:31:08 -0400 (EDT) Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 23 Mar 2017 23:31:12 -0000 --------=_MBA7094869-EA45-4D72-98AD-2332E7CBEA07 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ekr, The SSRC is used in the IV when encrypting packets, but not directly in=20 the KDF to derive k_e, k_a, or k_s. That said, that will avoid the=20 two-time pad problem. Current guidance is that a given key should not be used more than 2^48=20 times. By how much would having 1,000 participants in a conference=20 sending a total of 2,000 media flows using keys derived from the same=20 K_g reduce key lifetime? I'm still struggling with the overall benefit, though. With both, we=20 have a need to exchange keying material, thus a need for DTLS-SRTP + EKT=20 (or other) procedures. With EKT, an endpoint sends its SRTP master key and ROC periodically. =20 AES_Keywrap() doesn't have to be called on every packet, since the=20 ciphertext is static. Other than the size of the EKT field (which we=20 could reduce and which is only sent periodically), it doesn't seem like=20 a burden. What you're proposing will require assignment of a unique participant=20 identifier (which we can do over the DTLS tunnel) and sending that ID=20 and the ROC periodically in packets. It seems roughly the same in terms of complexity, with the K_g approach=20 (ID || ROC) perhaps using slightly fewer bits on the wire compared to=20 the the EKT field. I'd like to hear others weigh in on pros/cons. I don't want to send=20 negative signals if others favor this approach. Other than my question=20 on key lifetime impact, the K_g approach seems fine. Paul ------ Original Message ------ From: "Eric Rescorla" To: "Paul E. Jones" Cc: perc@ietf.org Sent: 3/23/2017 7:12:51 AM Subject: Re: [Perc] Question on diet Design? >It's part of the SRTP KDF. > >-Ekr > > >On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones =20 >wrote: >>Eric, >> >>>>I think what you propose would work, but each stream from a given=20 >>>>endpoint would need to have a unique key since we do not want the=20 >>>>any two media flows using the same key. Thus, I think we'd need: >>>> KDF(K_g, ID || stream_id) >>> >>>The SSRC addresses that, no? >> >>Yeah, SSRC is fine for that. We just need to ensure it is a part of=20 >>the KDF input. >> >>Paul > --------=_MBA7094869-EA45-4D72-98AD-2332E7CBEA07 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ekr,

The SSRC is used in the IV when encrypting packets, but not dir= ectly in the KDF to derive k_e, k_a, or k_s. =C2=A0That said, that will avo= id the two-time pad problem.

Current guidance is that a given key shoul= d not be used more than 2^48 times. =C2=A0By how much would having 1,000 pa= rticipants in a conference sending a total of 2,000 media flows using keys= derived from the same K_g reduce key lifetime?

I'm still struggling wit= h the overall benefit, though. =C2=A0With both, we have a need to exchange= keying material, thus a need for DTLS-SRTP + EKT (or other) procedures.

With EKT, an endpoint sends its SRTP mast= er key and ROC =C2=A0periodica= lly. =C2=A0AES_Keywrap() doesn't ha= ve to be called on every packet, since the ciphertext is static. =C2=A0Othe= r than the size of the EKT field (which we could reduce and which is only s= ent periodically), it doesn't seem like a burden.

What you're prop= osing will require assignment of a unique participant identifier (which we= can do over the DTLS tunnel) and sending that ID and the ROC periodically i= n packets.=C2=A0

It seems roughly the same in terms of complexity, = with the K_g approach (ID || ROC) perhaps using slightly fewer bits on the = wire compared to the the EKT field.

I'd like to hear others weigh = in on pros/cons. =C2=A0I don't want to send negative signals if others fav= or this approach. =C2=A0Other than my question on key lifetime impact, the= K_g approach seems fine.

<= /div>
Paul

------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com= >
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 3/23/2017 7:12:51 AM
Subject: Re: [Perc] Question on diet Design?

It's part of the SRTP KDF.

-Ekr
=


On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones &l= t;paulej@packetizer.com> wrote:
Eric,

I think what you propose would work, but = each stream from a given endpoint would need to have a unique key since we = do not want the any two media flows using the same key. Thus, I think we'd = need:
=C2=A0 KDF(K_g, ID || stream= _id)

The SS= RC addresses that, no?

Yeah, SSRC is fine for= that.=C2=A0 We just need to ensure it is a part of the KDF input.

Paul

--------=_MBA7094869-EA45-4D72-98AD-2332E7CBEA07-- From nobody Thu Mar 23 16:46: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 7724A129516 for ; Thu, 23 Mar 2017 16:46:13 -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=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 a1UHgObaiXym for ; Thu, 23 Mar 2017 16:46:11 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 44991129A8C for ; Thu, 23 Mar 2017 16:46:09 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id d191so30999710ywe.2 for ; Thu, 23 Mar 2017 16:46:09 -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=LKRiBvewd9ir0iA8kW8hb4JT0xGMkRP/9cWOT1Wi37U=; b=C4C+Mp1mXvgm2czODIe7mhBi7xBMx5jrqMG1GCjavJ4z2FcVdwhd3SiTaIoJhqNRRB 484cMNZL3nK8f+uJ3Pco/9GZvYB/IQ0M0hfpvRpmbDgJCCV1PfKBcniIlTBr668HG/HI akwWGYKI1rXIf0zYHkDcUI0l1e/A5kQ+a9o9uB5Mn8VTdWheWi8rMeXx0FAeTB2YcxA5 hyZqhT/m92DC1JIETmGtDAk0JM2rgWdUvLu/6ipGPj/PsLFQyANN9MYJKdl6HaNnCjJe yTH5ryhbQNeVULY1ikImxkHMSn/q110hWDrB/c//JWpDDpAkCbCeqvTPh9fD5oekN+AR zqmg== 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=LKRiBvewd9ir0iA8kW8hb4JT0xGMkRP/9cWOT1Wi37U=; b=YHqzQ3rBHPJNwjGGEGU4Elmq2+3lOcJ6Wt0ZwLIaIU9QDtxkNHJJKzzuys7Mwr7uge VtXehCTgddOi12/HCT2gfC/MZdsR57fcM/PUImh2ddB+r3tDN2Q3K5/cDQqdjgVZnLUO yNq9Z2TKK8vw73xR9WoHmai3Pk/IfNWc1SFgLi9JCgsdTBbZU8ARJJUe5TdYGD72ydwr qxc2MDS4zHsicBpGpeOsLyLMP/Qv+/jkZontuhwwvCnLdr2evhyQmX3ecwzhazKqixAF CbDZeTaJXNEx8XEzeyohju6LzBWNxeqMeH6c+IpJiz2pCuxj118FB7yKIg/fm1sF1bsO VB3A== X-Gm-Message-State: AFeK/H3dnyKimPBKUImVxwbkJoU88Vhf17aT9K1YNNJLOqmGc2t7LP3V1vGskGDorXp2Sci3fepIw6yc0dR6Pg== X-Received: by 10.13.204.206 with SMTP id o197mr4076892ywd.87.1490312768429; Thu, 23 Mar 2017 16:46:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 23 Mar 2017 16:45:27 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 23 Mar 2017 16:45:27 -0700 Message-ID: To: "Paul E. Jones" Cc: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114e6b3c2abcf3054b6e7bbf Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 23 Mar 2017 23:46:13 -0000 --001a114e6b3c2abcf3054b6e7bbf Content-Type: text/plain; charset=UTF-8 On Thu, Mar 23, 2017 at 4:31 PM, Paul E. Jones wrote: > Ekr, > > The SSRC is used in the IV when encrypting packets, but not directly in > the KDF to derive k_e, k_a, or k_s. That said, that will avoid the > two-time pad problem. > Sure, my mistake. In any case, it's not a problem for multiple SSRCs. Current guidance is that a given key should not be used more than 2^48 > times. By how much would having 1,000 participants in a conference sending > a total of 2,000 media flows using keys derived from the same K_g reduce > key lifetime? > These are totally unrelated. The guidance is about the lifetime of a single GCM key, not about the keying material from which it was derived. I'm still struggling with the overall benefit, though. With both, we have > a need to exchange keying material, thus a need for DTLS-SRTP + EKT (or > other) procedures. > > With EKT, an endpoint sends its SRTP master key and ROC periodically. > AES_Keywrap() doesn't have to be called on every packet, since the > ciphertext is static. Other than the size of the EKT field (which we could > reduce and which is only sent periodically), it doesn't seem like a burden. > > What you're proposing will require assignment of a unique participant > identifier (which we can do over the DTLS tunnel) and sending that ID and > the ROC periodically in packets. > > It seems roughly the same in terms of complexity, with the K_g approach > (ID || ROC) perhaps using slightly fewer bits on the wire compared to the > the EKT field. > > I'd like to hear others weigh in on pros/cons. I don't want to send > negative signals if others favor this approach. Other than my question on > key lifetime impact, the K_g approach seems fine. > Well, at the moment, I'm just trying to understand what the current design is supposed to achieve, and that means getting clear on what keying material you are trying to establish. In that process, I am seeing some things that make me sad in particular; - Having two key transport phases, which is pretty hard to wrap your head around, though perhaps it's just a writing issue. - Grabbing a DTLS code point (why can't you just shove this in the application data), so I'm trying to remove that [0]. So I'm trying to push on what's really needed. -Ekr [0] I concede that what I wrote above doesn't do that, but reducing the number of key wrap phases might let us do so, for instance by carrying K_g in EKT. > Paul > > ------ Original Message ------ > From: "Eric Rescorla" > To: "Paul E. Jones" > Cc: perc@ietf.org > Sent: 3/23/2017 7:12:51 AM > Subject: Re: [Perc] Question on diet Design? > > It's part of the SRTP KDF. > > -Ekr > > > On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones > wrote: > >> Eric, >> >> I think what you propose would work, but each stream from a given >>> endpoint would need to have a unique key since we do not want the any two >>> media flows using the same key. Thus, I think we'd need: >>> KDF(K_g, ID || stream_id) >>> >> >> The SSRC addresses that, no? >> >> >> Yeah, SSRC is fine for that. We just need to ensure it is a part of the >> KDF input. >> >> Paul >> > > --001a114e6b3c2abcf3054b6e7bbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 23, 2017 at 4:31 PM, Paul E. Jones <paulej@packetizer.= com> wrote:
Ekr,

The SSRC is used in= the IV when encrypting packets, but not directly in the KDF to derive k_e,= k_a, or k_s.=C2=A0 That said, that will avoid the two-time pad problem.

Sure, my mistake. In any case, it= 's not a problem for multiple SSRCs.


Current g= uidance is that a given key should not be used more than 2^48 times.=C2=A0 = By how much would having 1,000 participants in a conference sending a total= of 2,000 media flows using keys derived from the same K_g reduce key lifet= ime?

These are totally unrelate= d. The guidance is about the lifetime of a single GCM key, not about
<= div>the keying material from which it was derived.


I'm still struggling with the overall benefit, though.=C2=A0 With both= , we have a need to exchange keying material, thus a need for DTLS-SRTP + E= KT (or other) procedures.

With EKT, an endpoin= t sends its SRTP master key and ROC =C2=A0periodically.=C2=A0 AES_Key= wrap() doesn't have to be called on every packet, since the ciphertext = is static.=C2=A0 Other than the size of the EKT field (which we could reduc= e and which is only sent periodically), it doesn't seem like a burden.<= /span>
W= hat you're proposing will require assignment of a unique participant id= entifier (which we can do over the DTLS tunnel) and sending that ID and the= ROC periodically in packets.=C2=A0

It seems roughly the same in terms of co= mplexity, with the K_g approach (ID || ROC) perhaps using slightly fewer bi= ts on the wire compared to the the EKT field.

I'd like to hear others we= igh in on pros/cons.=C2=A0 I don't want to send negative signals if oth= ers favor this approach.=C2=A0 Other than my question on key lifetime impac= t, the K_g approach seems fine.

Well, at the moment, I'm just trying to understand what the cur= rent design is supposed
to achieve, and that means getting clear = on what keying material you are trying to
establish.=C2=A0
<= div>
In that process, I am seeing some things that make me sa= d in particular;

- Having two key transport phases= , which is pretty hard to wrap your head around,
though perhaps i= t's just a writing issue.
- Grabbing a DTLS code point (why c= an't you just shove this in the application data),
so I'm= trying to remove that [0].=C2=A0

So I'm tryin= g to push on what's really needed.

-Ekr

[0] I concede that what I wrote above doesn't do= that, but reducing the number of
key wrap phases might let us do= so, for instance by carrying K_g in EKT.


Paul

------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com>
To: "Paul E. J= ones" <p= aulej@packetizer.com>
Sent: 3/23/2017 7:12:51 AM
Subject: Re: [Perc] Question on diet Design?

It's part of the SRTP KDF.

-Ekr


On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones <= paulej@packetize= r.com> wrote:
<= div>Eric,

I think what you propose would work, but= each stream from a given endpoint would need to have a unique key since we= do not want the any two media flows using the same key. Thus, I think we&#= 39;d need:
=C2=A0 KDF(K_g, ID || st= ream_id)

The = SSRC addresses that, no?

Yeah, SSRC is = fine for that.=C2=A0 We just need to ensure it is a part of the KDF input.<= /div>

Paul


--001a114e6b3c2abcf3054b6e7bbf-- From nobody Thu Mar 23 17:04:32 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 CD5AF128B4E for ; Thu, 23 Mar 2017 17:04:30 -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 ptqiQ_IupsGm for ; Thu, 23 Mar 2017 17:04:29 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 11E0D1275C5 for ; Thu, 23 Mar 2017 17:04:29 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id v76so158149308ywg.0 for ; Thu, 23 Mar 2017 17:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JyclcgiFj67DKURsYC5kIEn9Kqaha2LMHyiu9erLL2A=; b=Eud+2QsrTzgYgj/ll9BEHyKUYJ+Hml6veOqhCHOQDwq22JCo4axXQ5dFu+HUgJR1Dj QhenbCI5QxtI+IqGbu9t21SqrOW2l59tlW/TMtGPZe0e8pBJIoI6vvu8SQuuJ7KNsDKW 9qL9nAduuC0MtssG9H5KgMWLKj31f673WsPK1c72ftPrZte626GxBWqQ+XhmrLKBwnej oRf0s8COB2PfvDsgTBIKyDB9ePzgeHWO7oHp9AZ1kZIoQMpe5wF4q1SCeKK9iava0wsT gS/7lrEhDKxwRYzpFytVt9Sc8w4YKvFV/kp1XnGUHzWN+kO7+KSZ79YSuP5uB53BK/tB Qx2A== 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=JyclcgiFj67DKURsYC5kIEn9Kqaha2LMHyiu9erLL2A=; b=oHszRUTXBbhlekwXEIfD2gpOOlga2c0EEBsilxleDwtZ7gPa0WYqyUczm1RFFf0azX ciW5QgoG+ZaWbO6VEJ5sW07d7JASIjpJX0lqQ/2IQ83cUoyTk7JMKOxHywtr4JOJq1D3 maSNOyFSojWEAbJZxQTVzOc1Au0hbn5WpMAkud6LFUQQWTZiJnrRLtpzPevJQCtdNVy6 tLjTIvvK24l+l0RlmMTekP6M+U+K8uWw5sWKh25xo+SoN6YHlz/OY4LQ40mY912qzvxz AkfV5VJ7D9Ie8ZOujZz5BN+hjDRo8wi19OccjNUPNRhRU31QKCAoG8/TrOmGOMWzdk3y 4bRA== X-Gm-Message-State: AFeK/H0Ybmn7iKjJGLe9h/agMTt1WobxhyWAyEkv+nkSX/O10R8Av6/BlEtJ95ceJ458oWtKHFsJyJNjUKyiXg== X-Received: by 10.129.152.22 with SMTP id p22mr4259964ywg.276.1490313868013; Thu, 23 Mar 2017 17:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 23 Mar 2017 17:03:47 -0700 (PDT) From: Eric Rescorla Date: Thu, 23 Mar 2017 17:03:47 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0b8fb4b5160f054b6ebc08 Archived-At: Subject: [Perc] Comments on: draft-ietf-perc-dtls-tunnel-00.txt 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, 24 Mar 2017 00:04:31 -0000 --94eb2c0b8fb4b5160f054b6ebc08 Content-Type: text/plain; charset=UTF-8 This looks mostly OK. Comments below. I'm not sure I'm excited about having the version # in every message. That seems like a recipe for mess. Why not just have it in the first message? S 5.4. subsequently include this identifier in all messages it sends so that the media distributor can map messages received via a tunnel and forward those messages to the correct endpoint. The association identifier SHOULD be randomly assigned and values not be re-used for a short period of time (e.g., five minutes) to ensure any residual state in the key distributor is clear and to ensure any packets already transmitted from the key distributor are not directed to the wrong endpoint. Why don't you just generate a longer identifier and guarantee non-reuse? It's not like you are short on bandwidth in this channel. S 6.1. enum { unsupported_version(1), supported_profiles(2), media_keys(3), tunneled_dtls(4), endpoint_disconnect(5), (255) } MsgType; struct { uint8 version; MsgType msg_type; select (MsgType) { case unsupported_version: UnsupportedVersion; case supported_profiles: SupportedProfiles; case media_keys: MediaKeys; case tunneled_dtls: TunneledDtls; case endpoint_disconnect: EndpointDisconnect; } body; } TunnelMessage; Generally, it's a good idea to have TunnelMessages have a length in a deterministic place as this allows one to make a generic message parser before you look at the type. Nit: This message contains this single element: * protection_profiles: The list of two-octet SRTP protection profile values as per [RFC5764] supported by the media distributor. You have a formatting glitch here. --94eb2c0b8fb4b5160f054b6ebc08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks mostly OK.=C2=A0 Comments below.

I'm not sure I'm excited about having the version #= in every message.
That seems like a recipe for mess. Why not jus= t have it in the first
message?


S 5.4.
=C2=A0 =C2=A0subsequently include this identifier i= n all messages it sends so that
=C2=A0 =C2=A0the media distributo= r can map messages received via a tunnel and
=C2=A0 =C2=A0forward= those messages to the correct endpoint.=C2=A0 The association
= =C2=A0 =C2=A0identifier SHOULD be randomly assigned and values not be re-us= ed for
=C2=A0 =C2=A0a short period of time (e.g., five minutes) t= o ensure any residual
=C2=A0 =C2=A0state in the key distributor i= s clear and to ensure any packets
=C2=A0 =C2=A0already transmitte= d from the key distributor are not directed to the
=C2=A0 =C2=A0w= rong endpoint.

Why don't you just generate a l= onger identifier and guarantee non-reuse?
It's not like you a= re short on bandwidth in this channel.


<= div>S 6.1.
=C2=A0 =C2=A0enum {
=C2=A0 =C2=A0 =C2=A0= =C2=A0unsupported_version(1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0support= ed_profiles(2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0media_keys(3),
=C2=A0 =C2=A0 =C2=A0 =C2=A0tunneled_dtls(4),
=C2=A0 =C2=A0 =C2= =A0 =C2=A0endpoint_disconnect(5),
=C2=A0 =C2=A0 =C2=A0 =C2=A0(255= )
=C2=A0 =C2=A0} MsgType;

=C2=A0 =C2=A0s= truct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint8 version;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0MsgType msg_type;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0select (MsgType) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0case unsupported_version: UnsupportedVersion;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0case supported_profiles: =C2=A0SupportedProfiles= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case media_keys: =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MediaKeys;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0case tunneled_dtls: =C2=A0 =C2=A0 =C2=A0 TunneledDtls;<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case endpoint_disconnect= : EndpointDisconnect;
=C2=A0 =C2=A0 =C2=A0} body;
=C2= =A0 =C2=A0} TunnelMessage;

Generally, it's a g= ood idea to have TunnelMessages have a length in
a deterministic = place as this allows one to make a generic message
parser before = you look at the type.

Nit:
=C2=A0 =C2=A0= This message contains this single element: * protection_profiles: The
=
=C2=A0 =C2=A0list of two-octet SRTP protection profile values as per [= RFC5764]
=C2=A0 =C2=A0supported by the media distributor.

You have a formatting glitch here.

--94eb2c0b8fb4b5160f054b6ebc08-- From nobody Thu Mar 23 19:09: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 633C1129C27 for ; Thu, 23 Mar 2017 19:09:34 -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, MIME_QP_LONG_LINE=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 yHLQVozdBLx4 for ; Thu, 23 Mar 2017 19:09:32 -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 11444129A7C for ; Thu, 23 Mar 2017 19:09:31 -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 v2O29U13025370 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 22:09:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490321371; bh=dh8c8faJ5ruhMC6aur0OYWlxBiPucM6sZt+MhF+axbg=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=O1YJ2EDFfpXS96d480SSBtKRevZARtf1ZsTtd2KrqayH5gERExmG468h8BkwLQSqn ijaL6ylYqsaquZkesQwHhK6/f2S1qI6N8mBlxcjsrD35m6r/cV8h3yO6uYDCSCSWtB 4gn5KQQ9X+XVqQSPVlckmyZ/PrAfSwOgYmvjTsWA= From: "Paul E. Jones" To: "Eric Rescorla" , perc@ietf.org Date: Fri, 24 Mar 2017 02:09:32 +0000 Message-Id: In-Reply-To: References: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB7A3116D3-C1DB-4795-8617-71F475B2DB23" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 23 Mar 2017 22:09:31 -0400 (EDT) Archived-At: Subject: Re: [Perc] Comments on: draft-ietf-perc-dtls-tunnel-00.txt 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, 24 Mar 2017 02:09:34 -0000 --------=_MB7A3116D3-C1DB-4795-8617-71F475B2DB23 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ekr, >I'm not sure I'm excited about having the version # in every message. >That seems like a recipe for mess. Why not just have it in the first >message? Yeah, that could be done. We could move the version field to the=20 "SupportedProfiles" message and require that the key distributor send=20 the version error if that message contains an incompatible version. =20 Then, we could put a version field into the "UnsupportedVersion" message=20 I think that would be sufficient. >S 5.4. > subsequently include this identifier in all messages it sends so=20 >that > the media distributor can map messages received via a tunnel and > forward those messages to the correct endpoint. The association > identifier SHOULD be randomly assigned and values not be re-used for > a short period of time (e.g., five minutes) to ensure any residual > state in the key distributor is clear and to ensure any packets > already transmitted from the key distributor are not directed to the > wrong endpoint. > >Why don't you just generate a longer identifier and guarantee=20 >non-reuse? >It's not like you are short on bandwidth in this channel. Something like a 128-bit random value? A UUID? We could do that and=20 avoid state maintenance. >S 6.1. > enum { > unsupported_version(1), > supported_profiles(2), > media_keys(3), > tunneled_dtls(4), > endpoint_disconnect(5), > (255) > } MsgType; > > struct { > uint8 version; > MsgType msg_type; > select (MsgType) { > case unsupported_version: UnsupportedVersion; > case supported_profiles: SupportedProfiles; > case media_keys: MediaKeys; > case tunneled_dtls: TunneledDtls; > case endpoint_disconnect: EndpointDisconnect; > } body; > } TunnelMessage; > >Generally, it's a good idea to have TunnelMessages have a length in >a deterministic place as this allows one to make a generic message >parser before you look at the type. Good point. I think this was a left-over from when we assumed use of=20 DTLS to tunnel DTLS, so length was the length of the packet. We do need=20 something for TLS, so I'll put in a length field before or after=20 msg_type. >Nit: > This message contains this single element: * protection_profiles:=20 >The > list of two-octet SRTP protection profile values as per [RFC5764] > supported by the media distributor. > >You have a formatting glitch here. Indeed. Well, that sucks. My markdown tool failed me. I'll hack the=20 text or fix the markdown tool. :) Paul --------=_MB7A3116D3-C1DB-4795-8617-71F475B2DB23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ekr,

I'm not sure I'm excited about having th= e version # in every message.
That seems like a recipe for = mess. Why not just have it in the first
message?

Yeah, that could be done. We could move the version field to the "Suppo= rtedProfiles" message and require that the key distributor send the version = error if that message contains an incompatible version. =C2=A0Then, we cou= ld put a version field into the "UnsupportedVersion" message =C2=A0I think= that would be sufficient.

S 5.4.
=C2=A0 =C2=A0subsequently inc= lude this identifier in all messages it sends so that
=C2=A0 =C2= =A0the media distributor can map messages received via a tunnel and
=C2=A0 =C2=A0forward those messages to the correct endpoint.=C2=A0 The a= ssociation
=C2=A0 =C2=A0identifier SHOULD be randomly assigned an= d values not be re-used for
=C2=A0 =C2=A0a short period of time (= e.g., five minutes) to ensure any residual
=C2=A0 =C2=A0state in= the key distributor is clear and to ensure any packets
=C2=A0 =C2= =A0already transmitted from the key distributor are not directed to the
=C2=A0 =C2=A0wrong endpoint.

Why don't yo= u just generate a longer identifier and guarantee non-reuse?
It's = not like you are short on bandwidth in this channel.

Something like a 128-bit random value? =C2= =A0A UUID? =C2=A0We could do that and avoid state maintenance.=C2=A0=


S 6.1.
=C2=A0 =C2=A0enum {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0unsupported_version(1),
=C2=A0 =C2=A0 =C2=A0 = =C2=A0supported_profiles(2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0media_ke= ys(3),
=C2=A0 =C2=A0 =C2=A0 =C2=A0tunneled_dtls(4),
=C2= =A0 =C2=A0 =C2=A0 =C2=A0endpoint_disconnect(5),
=C2=A0 =C2=A0 =C2= =A0 =C2=A0(255)
=C2=A0 =C2=A0} MsgType;

=C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0uint8 version;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0MsgType msg_type;
=C2=A0= =C2=A0 =C2=A0 =C2=A0select (MsgType) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0case unsupported_version: UnsupportedVersion;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case supported_profiles: =C2=A0Suppor= tedProfiles;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case media_= keys: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MediaKeys;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0case tunneled_dtls: =C2=A0 =C2=A0 =C2=A0 Tunnel= edDtls;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case endpoint_di= sconnect: EndpointDisconnect;
=C2=A0 =C2=A0 =C2=A0} body;
=C2=A0 =C2=A0} TunnelMessage;

Generally, it's = a good idea to have TunnelMessages have a length in
a determinis= tic place as this allows one to make a generic message
parser bef= ore you look at the type.

Good point. I think this was a = left-over from when we assumed use of DTLS to tunnel DTLS, so length was t= he length of the packet. =C2=A0We do need something for TLS, so I'll put in = a length field before or after msg_type.


Nit:
=C2=A0= =C2=A0This message contains this single element: * protection_profiles: The
=C2=A0 =C2=A0list of two-octet SRTP protection profile values as p= er [RFC5764]
=C2=A0 =C2=A0supported by the media distributor.

You have a formatting glitch here.

Indeed. =C2=A0Well, that sucks. =C2=A0My markdown tool failed me. =C2=A0= I'll hack the text or fix the markdown tool. :)

Paul

--------=_MB7A3116D3-C1DB-4795-8617-71F475B2DB23-- From nobody Sat Mar 25 13:32: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 64CDB124D68 for ; Sat, 25 Mar 2017 13:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 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, 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 8hW_1GB-lxs9 for ; Sat, 25 Mar 2017 13:32:26 -0700 (PDT) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.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 AA7BF127011 for ; Sat, 25 Mar 2017 13:32:26 -0700 (PDT) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C86DD24A59; Sat, 25 Mar 2017 16:32:23 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp27.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 752F9249E1; Sat, 25 Mar 2017 16:32:23 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn3-150.cisco.com ([UNAVAILABLE]. [173.38.117.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sat, 25 Mar 2017 16:32:23 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDB3C598-6C91-49D0-A665-B596C029EA5B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Sat, 25 Mar 2017 15:32:22 -0500 Cc: Paul Jones , perc@ietf.org Message-Id: <37B48DF7-C267-402D-ABA0-68195CA89E21@iii.ca> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Perc] Question on diet Design? 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, 25 Mar 2017 20:32:29 -0000 --Apple-Mail=_CDB3C598-6C91-49D0-A665-B596C029EA5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii EKT was deployed and shipped before the PERC WG was started. It was easy = to reuse it from an implementation point of view and it remains useful = for conferencing even without PERC or DTLS-SRTP because it allows the = conference server to move all the participants to same same key to = reduce outbound encryption load.=20 The other issue driving the design is scheduling when to use keys. We = can't easily synchronize when key changes happen, but we can make sure = that everyone gets the intermedia key over DTLS and waits a few seconds = before they start using it. That way they know everyone has likely = received it before thy start using it.=20 > On Mar 23, 2017, at 6:45 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, Mar 23, 2017 at 4:31 PM, Paul E. Jones > wrote: > Ekr, >=20 > The SSRC is used in the IV when encrypting packets, but not directly = in the KDF to derive k_e, k_a, or k_s. That said, that will avoid the = two-time pad problem. >=20 > Sure, my mistake. In any case, it's not a problem for multiple SSRCs. >=20 >=20 > Current guidance is that a given key should not be used more than 2^48 = times. By how much would having 1,000 participants in a conference = sending a total of 2,000 media flows using keys derived from the same = K_g reduce key lifetime? >=20 > These are totally unrelated. The guidance is about the lifetime of a = single GCM key, not about > the keying material from which it was derived. >=20 >=20 > I'm still struggling with the overall benefit, though. With both, we = have a need to exchange keying material, thus a need for DTLS-SRTP + EKT = (or other) procedures. >=20 > With EKT, an endpoint sends its SRTP master key and ROC periodically. = AES_Keywrap() doesn't have to be called on every packet, since the = ciphertext is static. Other than the size of the EKT field (which we = could reduce and which is only sent periodically), it doesn't seem like = a burden. >=20 > What you're proposing will require assignment of a unique participant = identifier (which we can do over the DTLS tunnel) and sending that ID = and the ROC periodically in packets.=20 >=20 > It seems roughly the same in terms of complexity, with the K_g = approach (ID || ROC) perhaps using slightly fewer bits on the wire = compared to the the EKT field. >=20 > I'd like to hear others weigh in on pros/cons. I don't want to send = negative signals if others favor this approach. Other than my question = on key lifetime impact, the K_g approach seems fine. >=20 > Well, at the moment, I'm just trying to understand what the current = design is supposed > to achieve, and that means getting clear on what keying material you = are trying to > establish.=20 >=20 > In that process, I am seeing some things that make me sad in = particular; >=20 > - Having two key transport phases, which is pretty hard to wrap your = head around, > though perhaps it's just a writing issue. > - Grabbing a DTLS code point (why can't you just shove this in the = application data), > so I'm trying to remove that [0].=20 >=20 > So I'm trying to push on what's really needed. >=20 > -Ekr >=20 > [0] I concede that what I wrote above doesn't do that, but reducing = the number of > key wrap phases might let us do so, for instance by carrying K_g in = EKT. >=20 >=20 > Paul >=20 > ------ Original Message ------ > From: "Eric Rescorla" > > To: "Paul E. Jones" > > Cc: perc@ietf.org > Sent: 3/23/2017 7:12:51 AM > Subject: Re: [Perc] Question on diet Design? >=20 >> It's part of the SRTP KDF. >>=20 >> -Ekr >>=20 >>=20 >> On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones > wrote: >> Eric, >>=20 >>> I think what you propose would work, but each stream from a given = endpoint would need to have a unique key since we do not want the any = two media flows using the same key. Thus, I think we'd need: >>> KDF(K_g, ID || stream_id) >>>=20 >>> The SSRC addresses that, no? >>=20 >> Yeah, SSRC is fine for that. We just need to ensure it is a part of = the KDF input. >>=20 >> Paul >>=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_CDB3C598-6C91-49D0-A665-B596C029EA5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

EKT was deployed and = shipped before the PERC WG was started. It was easy to reuse it from an = implementation point of view and it remains useful for conferencing even = without PERC or DTLS-SRTP because it allows the conference server to = move all the participants to same same key to reduce outbound encryption = load. 

The = other issue driving the design is scheduling when to use keys. We can't = easily synchronize when key changes happen, but we can make sure that = everyone gets the intermedia key over DTLS and waits a few seconds = before they start using it. That way they know everyone has likely = received it before thy start using it. 


On Mar 23, 2017, at 6:45 PM, = Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Mar 23, 2017 at 4:31 PM, Paul E. Jones = <paulej@packetizer.com> = wrote:
Ekr,

The SSRC is used in the IV when encrypting packets, but not = directly in the KDF to derive k_e, k_a, or k_s.  That said, that = will avoid the two-time pad problem.

Sure, my mistake. In any = case, it's not a problem for multiple SSRCs.


Current guidance is that a given key should not be used more = than 2^48 times.  By how much would having 1,000 participants in a = conference sending a total of 2,000 media flows using keys derived from = the same K_g reduce key lifetime?

These are totally = unrelated. The guidance is about the lifetime of a single GCM key, not = about
the keying material from which it was = derived.


I'm still struggling with the overall = benefit, though.  With both, we have a need to exchange keying = material, thus a need for DTLS-SRTP + EKT (or other) = procedures.

With EKT, an endpoint sends its SRTP = master key and ROC  periodically.  AES_Keywrap() doesn't have to be called on every = packet, since the ciphertext is static.  Other than the size of the = EKT field (which we could reduce and which is only sent periodically), = it doesn't seem like a burden.

What you're proposing will require = assignment of a unique participant identifier (which we can do over the = DTLS tunnel) and sending that ID and the ROC periodically in = packets. 

It seems roughly the same in terms of complexity, with the = K_g approach (ID || ROC) perhaps using slightly fewer bits on the wire = compared to the the EKT field.

I'd like to hear others weigh in on = pros/cons.  I don't want to send negative signals if others favor = this approach.  Other than my question on key lifetime impact, the = K_g approach seems fine.

Well, at the moment, I'm = just trying to understand what the current design is supposed
to achieve, and that means getting clear on what keying = material you are trying to
establish. 

In that process, I am = seeing some things that make me sad in particular;

- Having two key = transport phases, which is pretty hard to wrap your head = around,
though perhaps it's just a writing = issue.
- Grabbing a DTLS code point (why can't you = just shove this in the application data),
so I'm = trying to remove that [0]. 

So I'm trying to push on what's really = needed.

-Ekr

[0] = I concede that what I wrote above doesn't do that, but reducing the = number of
key wrap phases might let us do so, for = instance by carrying K_g in EKT.


Paul

------ Original Message ------
From: "Eric Rescorla" <ekr@rtfm.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: perc@ietf.org
Sent: 3/23/2017 7:12:51 AM
Subject: Re: [Perc] Question on diet Design?

It's part of the SRTP KDF.

-Ekr


On Wed, Mar 22, 2017 at 9:42 PM, Paul E. Jones = <paulej@packetizer.com> = wrote:
Eric,

I think what you propose = would work, but each stream from a given endpoint would need to have a = unique key since we do not want the any two media flows using the same = key. Thus, I think we'd need:
  KDF(K_g, ID || = stream_id)

The SSRC addresses that, = no?

Yeah, SSRC is fine for = that.  We just need to ensure it is a part of the KDF = input.

Paul


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

= --Apple-Mail=_CDB3C598-6C91-49D0-A665-B596C029EA5B-- From nobody Mon Mar 27 13:09:56 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 92B4212956E for ; Mon, 27 Mar 2017 13:09:54 -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 yAjzmp4vkX1n for ; Mon, 27 Mar 2017 13:09:53 -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 3F31412948E for ; Mon, 27 Mar 2017 13:09:53 -0700 (PDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9F8995A6D; Mon, 27 Mar 2017 16:09:49 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5A38C5A34; Mon, 27 Mar 2017 16:09:49 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn2-462.cisco.com ([UNAVAILABLE]. [173.38.117.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 27 Mar 2017 16:09:49 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_B85B4AB1-2A83-4FE0-B4B1-786AFC6E0E36" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <9A3F5BE1-169D-43F0-85F6-BFEB0FBE4D62@mozilla.com> Date: Mon, 27 Mar 2017 15:09:48 -0500 Cc: Eric Rescorla , perc@ietf.org Message-Id: <62C268C8-B361-4218-97F1-34FD0D4E4EE9@iii.ca> References: <9A3F5BE1-169D-43F0-85F6-BFEB0FBE4D62@mozilla.com> To: Nils Ohlmeier X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Perc] Double questions 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, 27 Mar 2017 20:09:55 -0000 --Apple-Mail=_B85B4AB1-2A83-4FE0-B4B1-786AFC6E0E36 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Mar 21, 2017, at 6:43 PM, Nils Ohlmeier wrote: > >> So, does that mean that the original PT/SEQ (as reconstructed from >> OHB) are not used for anything other than to make the decryption work? >> They're totally discarded? > > That is my understanding, yes. Pretty much .. but they might get used for various stats at e2e level --Apple-Mail=_B85B4AB1-2A83-4FE0-B4B1-786AFC6E0E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 21, 2017, at 6:43 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

So, does that mean that the original PT/SEQ (as reconstructed = from
OHB) are not used for anything other than to make the = decryption work?
They're totally discarded?

That is my understanding, = yes.

Pretty much .. but they might get used for various stats at = e2e level 

= --Apple-Mail=_B85B4AB1-2A83-4FE0-B4B1-786AFC6E0E36-- From nobody Tue Mar 28 12:03: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 9F7381270A7 for ; Tue, 28 Mar 2017 12:03:44 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLtlRcSNizSu for ; Tue, 28 Mar 2017 12:03:43 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 99C061270FC for ; Tue, 28 Mar 2017 11:58:13 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p22so74076833qka.3 for ; Tue, 28 Mar 2017 11:58:13 -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=8jE5mZ59z9qZyBek+QuGibuSVLi5b8n+3wQZTlZzVx4=; b=X5+CitI8T34L6bAdiuIOW58pzTXbSY8iVQd22GWcKjNPTbY6B/jeNeLXCLXaesVpvJ yeg0e825HXCWL95mZ9pQKgt0oGKD2V/PdWKfPP23MtTQtXAf3YqzUjZ/JOM6u309m1xJ KjaDGlS7nt9ufmp+9NNCnM/CT7Rc+jHz0moHOmcTmmgw+c40hM4gBaM+q1i9rA6TmT8y 43C04v/eSYSS3kwv9tVOSuI6TiUlparA6N5Ncngm0G/evGACtu9/QEnxOMMRoEYg2eQe WW2VlihOo4T9SPvsiodA9H8zMykIZyo575o35T3+8NXeHs0rC8HgAHa8jHP2KWwl9Qkn S6gg== 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=8jE5mZ59z9qZyBek+QuGibuSVLi5b8n+3wQZTlZzVx4=; b=rMiKji590xIBpByQdmVQ5yGTZgby408uKjoaKdcuuzLnXoXP+stkJ5VMWNx9nwkhNS RCQIMZx/FRH/KIot7RDXP653p6S9LiRWLK4AX7+AW+GgyQkgaj+qOPncuoZFzBQXfPF3 6euxR49G2LAULJzaKgkpdRBdvcuhn2HbpUziq1qZI+tRPcHuqtkW0T5LIXyLFbE4vaiZ InkIvw5nUjb8uQp6/KA/u5YRrvx+xMXH/2mKRrJ6B7aGVaIN+XWJimJdU/gMB6za2rD6 ba2BpmilTa3zwvwPqhHCsnBFrXZbtGBW3GDb3taFdx84xfsroa1d6D0OgcjArqCWPyqy Wtmg== X-Gm-Message-State: AFeK/H1xlvlDVFbJ0rhtdkokqkWoSj10omaPFXuzO19cGanjd1sEq5pdteIutcTzUts9Vg== X-Received: by 10.233.222.69 with SMTP id s66mr29527966qkf.126.1490727492076; Tue, 28 Mar 2017 11:58:12 -0700 (PDT) Received: from camionet.local ([104.192.142.137]) by smtp.googlemail.com with ESMTPSA id a21sm3226741qkj.54.2017.03.28.11.58.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 11:58:10 -0700 (PDT) To: "perc@ietf.org" References: From: Emil Ivov Message-ID: <30dea427-aec2-f535-f612-a3b2c40d7d6c@jitsi.org> Date: Tue, 28 Mar 2017 13:58:10 -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=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] SSRC rewrite. Was: RTX 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, 28 Mar 2017 19:03:44 -0000 On 3/15/17 11:52 PM, Emil Ivov wrote: > Hey folks, > > Boris and I thought we'd put a couple of thoughts on RTX use down on > paper. Didn't make it for cut off but you can check it out here: > > https://github.com/bgrozev/perc-rtx/blob/master/draft-ietf-ivov-double-rtx-01 Now available here: https://tools.ietf.org/html/draft-grozev-double-rtx-00 > Will present it in Chicago together with the SSRC one (that is still in > the queue). Just got this ready too: https://tools.ietf.org/html/draft-grozev-perc-ssrc I realize it's coming in late but it's rather short and I'll make sure I go through it fully tomorrow. Cheers, Emil -- https://jitsi.org From nobody Thu Mar 30 08: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 011FE1296B6 for ; Thu, 30 Mar 2017 08:16:15 -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 sdzDmDnIOQno for ; Thu, 30 Mar 2017 08:16:13 -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 EB5F0129681 for ; Thu, 30 Mar 2017 08:16:12 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h125so29322078lfe.0 for ; Thu, 30 Mar 2017 08:16:12 -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; bh=P62GO0hYhubnp49h/E7zzuG8iWbQqKh/ugLLSBuY9V4=; b=Vg8tnmwDm6NUtdvZdVqTAWZFS2mPLfys7/aE0PqBe3Ks29BYcjFZqAVWiskBV99q28 yEjJlsTD6hxyjy5f7tgJtEMBizBgYnmn8pM6/+AyTJFjw9uuJTT0e0Pu6PqY7BMWSVhf VuepnFGL9ZdngONuEd+K0jElJdmEJqdUgz5CB8iSW5Bv1nWnMhR7FT0tMIfd229kUX/1 68Bces3X+RH1Dl/eKtJ6n7vd9s6sst9qqbXKyFEFVOD8rLhkVLiLMuIPkeMXPx3nEbXS qYrl7fsxe1lXEscV4ZXCRUI1PdfqFFxzlVEIbCessCu0zaHgWFLMr5oTYGBoeyT16Cln GeWg== 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; bh=P62GO0hYhubnp49h/E7zzuG8iWbQqKh/ugLLSBuY9V4=; b=pBiYJ/BkDh+9+Z7sgmsh10rIZDlrxZo9UJBrbFf/H9Tg984O2wHYdCrM237SvLUWKz fVYnqWnYRhx9h/dZJNQoBREQpnwUlfmbLwyMJzvo2GE7t999Em0T4aOu2yb5Xx9zTjr8 lJZ7QwWFuza6bwlM0c5mFLB4tBFeAtRXS7wEdig5kQR5maD+AyZ+cDmu8CSbteLnvvoU Opf70wPDQcHT2Q4cidWNhB2yGhQcZFcGOZgWkJmbhp9bxXs9g/ktpx5SuGzq9oRWOjGP hu5riVflUXl4+l1Prt/M5FD/hpznZAFIWFYfSzNntJ0U/bCsxQ8WGgzjRY7cF13tkg/h IqQQ== X-Gm-Message-State: AFeK/H1vu4D4o0CzN06TT6R8qQ9U7Yw8P0Hv09c/fRyEVbxCTKSKzq4QV1FNLDxIfGPnaw== X-Received: by 10.28.45.212 with SMTP id t203mr3839321wmt.37.1490886970957; Thu, 30 Mar 2017 08:16:10 -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 140sm3615123wmk.12.2017.03.30.08.16.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 08:16:10 -0700 (PDT) To: perc@ietf.org From: Sergio Garcia Murillo Message-ID: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> Date: Thu, 30 Mar 2017 17:16:11 +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: multipart/alternative; boundary="------------9EEE5A7CA46A25CD5E4E858E" Archived-At: Subject: [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: Thu, 30 Mar 2017 15:16:15 -0000 This is a multi-part message in MIME format. --------------9EEE5A7CA46A25CD5E4E858E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I have been reviewing the documentation for double encryption and I have serious doubts about how the header extensions are handled. If I have understood it (please correct me if I am wrong) the MD must rely all the header extensions present before the OHB to the other peers: The Media Distributor MUST NOT delete any header extensions before the OHB, but MAY add, delete, or modify any that follow the OHB. This is an obvious requirement, as to be able to decrypt the inner crypto, the end receiver must have the same original rtp packet, which includes header extensions. 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. Is there anything that I missing? Best regards Sergio --------------9EEE5A7CA46A25CD5E4E858E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

I have been reviewing the documentation for double encryption and I have serious doubts about how the header extensions are handled.

If I have understood it (please correct me if I am wrong) the MD must rely all the header extensions present before the OHB to the other peers:

      The Media Distributor MUST NOT delete any header extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.
This is an obvious requirement, as to be able to decrypt the inner crypto, the end receiver must have the same original rtp packet, which includes header extensions.

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.

Is there anything that I missing?

Best regards
Sergio
--------------9EEE5A7CA46A25CD5E4E858E-- From nobody Thu Mar 30 09:31:54 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 23C911299BD for ; Thu, 30 Mar 2017 09:31:49 -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 ML9BxS9k5LW1 for ; Thu, 30 Mar 2017 09:31:45 -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 DB07812996E for ; Thu, 30 Mar 2017 09:31:40 -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 v2UGVcCh020642 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 12:31:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490891499; bh=qxHlS3Ny1L/B26RjZBdbPOHHG95VXW7owUsHn1uqSbs=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=jWKFTwRL47AAQOuKWjwz8YnYrTmkozuzY+0o/noMRSp8TulapNddphkkkZP0ywdCY KwtXUTQbDaTl14Gp5C61RUgmUNHh8AHL90WvBXwFiDvlpXHS8f2wNIpBaJWIx2cixX TaIFxZ7L0plaFQQTJkMlAWVUCOKMZEDmtWrBK10M= From: "Paul E. Jones" To: "Sergio Garcia Murillo" , perc@ietf.org Date: Thu, 30 Mar 2017 16:31:39 +0000 Message-Id: In-Reply-To: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBFD84F592-3DBF-4D3F-889D-435E15BAB774" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 12:31:39 -0400 (EDT) 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: Thu, 30 Mar 2017 16:31:49 -0000 --------=_MBFD84F592-3DBF-4D3F-889D-435E15BAB774 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sergio, Your interpretation is correct, I think. When we submitted the original=20 proposal for PERC (that we called "PRIME"), the RTP payload itself was=20 encrypted using an E2E key, but the headers only authenticated with a=20 HBH key. That draft was this: https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00 This was proposed using a single crypto context with an additional E2E=20 key. Another way to have viewed this (which I think is perhaps easiest=20 to comprehend) is that there were two contexts, one for E2E and one for=20 HBH. The E2E context would have used, for example, AES-CM with null=20 authentication and the HBH context would have used null encryption and=20 HMAC-SHA1 for authentication. (Of course, any ciphers or auth functions=20 could have been used.) This would have allowed the middlebox to change=20 headers as it saw fit, so long as we retained the fields required to=20 re-construct the crypto contexts. However, the need to maintain SSRC=20 and sequence numbers to reconstruct the crypto context is where a lot of=20 discussion took place that forced some discussion on how we had proposed=20 to do the encryption. Double addressed the issue of changing certain critical fields, while=20 also moving toward authenticated encryption. There were concerns with=20 introducing a new RFC with a split in encryption and authentication, so=20 Double addressed those concerns, too. However, you're right that the negotiated values might present a=20 problem. I've not spent much time thinking about how to solve that. =20 During this meeting, there were also concerns raised with Double and how=20 it works with RTX and FEC. Obviously, we need to get that right and=20 perhaps those and the RTP header extension concerns you raise should=20 both be topics for discussion in an interim meeting that the chairs will=20 be arranging. Paul ------ Original Message ------ From: "Sergio Garcia Murillo" To: perc@ietf.org Sent: 3/30/2017 11:16:11 AM Subject: [Perc] Double Encryption and header extensions issue >Hi all, > >I have been reviewing the documentation for double encryption and I=20 >have serious doubts about how the header extensions are handled. > >If I have understood it (please correct me if I am wrong) the MD must=20 >rely all the header extensions present before the OHB to the other=20 >peers: > >The Media Distributor MUST NOT delete any header extensions before the=20 >OHB, but MAY add, delete, or modify any that follow the OHB. This is an=20 >obvious requirement, as to be able to decrypt the inner crypto, the end=20 >receiver must have the same original rtp packet, which includes header=20 >extensions. > >My concerns is that there are scenarios in which this is not possible: >Sender and receiver may not support same set of header extensionsSender=20 >and receiver may have negotiated a different id for same header=20 >extension >In any of the previous scenarios, the receiver will not be able to=20 >parse the packet correctly, and at best case scenario, it will ignore=20 >the header extension. > >Is there anything that I missing? > >Best regards >Sergio --------=_MBFD84F592-3DBF-4D3F-889D-435E15BAB774 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20
Sergio,

Your interpretation is corr= ect, I think. =C2=A0When we submitted the original proposal for PERC (that= we called "PRIME"), the RTP payload itself was encrypted using an E2E key,= but the headers only authenticated with a HBH key. =C2=A0That draft was thi= s:

This was proposed using a single crypto context with an additional E= 2E key. =C2=A0Another way to have viewed this (which I think is perhaps eas= iest to comprehend) is that there were two contexts, one for E2E and one fo= r HBH. =C2=A0The E2E context would have used, for example, AES-CM with null = authentication and the HBH context would have used null encryption and HMA= C-SHA1 for authentication. =C2=A0(Of course, any ciphers or auth functions= could have been used.) =C2=A0This would have allowed the middlebox to chang= e headers as it saw fit, so long as we retained the fields required to re-c= onstruct the crypto contexts. =C2=A0However, the need to maintain SSRC and= sequence numbers to reconstruct the crypto context is where=C2=A0a lot of discussion took place that= forced some discussion on how we had proposed to do the encryption.<= /div>

Double addressed the issue of changing certain critical fields, while a= lso moving toward authenticated encryption. =C2=A0There were concerns with= introducing a new RFC with a split in encryption and authentication, so Dou= ble addressed those concerns, too.
However, you're right that the negot= iated values might present a problem. =C2=A0I've not spent much time thinki= ng about how to solve that. =C2=A0During this meeting, there were also conc= erns raised with Double and how it works with RTX and FEC. Obviously, we ne= ed to get that right and perhaps those and the RTP header extension concern= s you raise should both be topics for discussion in an interim meeting that = the chairs will be arranging.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
Sent: 3/30/2017 11:16:11 AM
Subject: [Perc] Double Encryption and header extensions issue

Hi all,

I have been reviewing the documentation for double encryption and I have serious doubts about how the header extensions are handled.

If I have understood it (please correct me if I am wrong) the MD must rely all the header extensions present before the OHB to the other peers:

      The Media Distributor MUST NOT delete any header extensions b=
efore
      the OHB, but MAY add, delete, or modify any that follow the OHB.
This is an obvious requirement, as to be able to decrypt the inner crypto, the end receiver must have the same original rtp packet, which includes header extensions.

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.

Is there anything that I missing?

Best regards
Sergio

  




--------=_MBFD84F592-3DBF-4D3F-889D-435E15BAB774--


From nobody Thu Mar 30 10:02:51 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 C6DB31299E9 for ; Thu, 30 Mar 2017 10:02:49 -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 seirV09EW76G for ; Thu, 30 Mar 2017 10:02:47 -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 60B8C1299DE for ; Thu, 30 Mar 2017 10:02:41 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id l43so70482584wre.1 for ; Thu, 30 Mar 2017 10:02:41 -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=0qoE/5mkbq1/f48F5r2hUr6NLPC1YMD0rjFl3sPmxTE=; b=RIpyPcM1/2owWc4u+rWknmyTRc4Hw37W/2FpGQz3Fl783qf5schp3CF7UvC3kWd4Iz mKVNSy1U9VdP2Qj6rchkySo+F9R/AVCIpd6F0FqfJ9Ua6XgirjhC3e+7GNrAVfl16CdN vQgeY12nqt4X5ZJVkr3lsspqVxHqO9RWq/noAAO8TAegtrW/47AyczGeOq/KwfWoF3Lf ZTApgBODRV6UdYQhTW7JADotM/UCbi+8LUkt5VzVib1nZScAtSSJFehqUB5kYnFEQ6nu t/PVzpxG1W32AMqI1eVC4rPOJc+Ne15nVUcsmOp333GzfXOd+GmklwhFx918HkBCvbwO 6axQ==
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=0qoE/5mkbq1/f48F5r2hUr6NLPC1YMD0rjFl3sPmxTE=; b=nI4tebz9HtxTFtq/ABj69MxiB/ciEivTqWTtAGkQ6rh5bUOfmIqls+fydcIkvEv/53 IOgy77qxCBU8kCxjCkpC6tunmNuBvuOeyiqo3uab1AHoUR+SXq3D9dNlu90fdbzbOt0W +kYqNLJXI52T2whi3Lv2WZoKeBUfGVMMwBtQ0gGcWkNVDU0yojcbzjhH5K4VgJIs3/Nr v+JzxoYlmZI5DULagaa4dwSm4+XOybMoYhqJRfDA5wOVSLLs4C7wlXp0iuPufp0WAH3L /dd42apKCYTczy0sD2ufjTmkAsndre/3qdgysm0cxzck+9i+5eQa1eong7n/qlrkjfCR 91+A==
X-Gm-Message-State: AFeK/H0q6+n55dPucNMl+1K42xqJL6Zwp9E6g2BnRFRoCyvMffXwjOeb8M/wbEoi79esbw==
X-Received: by 10.223.170.200 with SMTP id i8mr701989wrc.142.1490893359637; Thu, 30 Mar 2017 10:02:39 -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 o66sm3896711wmg.33.2017.03.30.10.02.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 10:02:38 -0700 (PDT)
To: "Paul E. Jones" , perc@ietf.org
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>
Date: Thu, 30 Mar 2017 19:02:39 +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="------------0275EFEC5C563930DCE21FEE"
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: Thu, 30 Mar 2017 17:02:50 -0000

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

Maybe I am jumping to the conclusions too fast, but IMHO both RTX/FEC 
and header extensions should be HBH and not E2E.

For header extensions I don't see a feasible way of negotiating the 
minimum common header extension subsets and getting all clients use the 
same extensions with same id. Also, I don't see much value in having the 
rtp header extensions E2E, as except the video orientation one, most of 
them are meant to be terminated at the MD (except the video orientation 
which would just need to be copied by the SFU).

Also, I don't see any privacy issue doing extensions HBH, as they are 
transmitted in clear to the MD, and even more, the main purpose of the 
rfc6904 for encrypted header extensions was to protect the client to 
mixer/mixer to client audio indications, which by definition are not E2E 
and required by an SFU to operate.

So IMHO, the inner encryption should be done on a "cloned" packet 
without extensions, and even more, we could use that encoded packet as 
the media payload of the outer encryption and forget about OHB 
completely and solve the RTX/FEC issue altogether. After all, it would 
be just a matter of adding an extra 12 bytes overhead (the full rtp 
payload header) vs the current OHB header extension, which could get 
also up to those 12 bytes if we need to include ssrc and ts.

Best regards
Sergio

On 30/03/2017 18:31, Paul E. Jones wrote:
> Sergio,
>
> Your interpretation is correct, I think.  When we submitted the 
> original proposal for PERC (that we called "PRIME"), the RTP payload 
> itself was encrypted using an E2E key, but the headers only 
> authenticated with a HBH key.  That draft was this:
> https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00
>
> This was proposed using a single crypto context with an additional E2E 
> key.  Another way to have viewed this (which I think is perhaps 
> easiest to comprehend) is that there were two contexts, one for E2E 
> and one for HBH.  The E2E context would have used, for example, AES-CM 
> with null authentication and the HBH context would have used null 
> encryption and HMAC-SHA1 for authentication.  (Of course, any ciphers 
> or auth functions could have been used.)  This would have allowed the 
> middlebox to change headers as it saw fit, so long as we retained the 
> fields required to re-construct the crypto contexts.  However, the 
> need to maintain SSRC and sequence numbers to reconstruct the crypto 
> context is where a lot of discussion took place that forced some 
> discussion on how we had proposed to do the encryption.
>
> Double addressed the issue of changing certain critical fields, while 
> also moving toward authenticated encryption.  There were concerns with 
> introducing a new RFC with a split in encryption and authentication, 
> so Double addressed those concerns, too.
>
> However, you're right that the negotiated values might present a 
> problem.  I've not spent much time thinking about how to solve that. 
>  During this meeting, there were also concerns raised with Double and 
> how it works with RTX and FEC. Obviously, we need to get that right 
> and perhaps those and the RTP header extension concerns you raise 
> should both be topics for discussion in an interim meeting that the 
> chairs will be arranging.
>
> Paul
>
> ------ Original Message ------
> From: "Sergio Garcia Murillo"  >
> To: perc@ietf.org 
> Sent: 3/30/2017 11:16:11 AM
> Subject: [Perc] Double Encryption and header extensions issue
>
>> Hi all,
>>
>> I have been reviewing the documentation for double encryption and I 
>> have serious doubts about how the header extensions are handled.
>>
>> If I have understood it (please correct me if I am wrong) the MD must 
>> rely all the header extensions present before the OHB to the other peers:
>>
>>        The Media Distributor MUST NOT delete any header extensions before
>>        the OHB, but MAY add, delete, or modify any that follow the OHB.
>>
>> This is an obvious requirement, as to be able to decrypt the inner 
>> crypto, the end receiver must have the same original rtp packet, 
>> which includes header extensions.
>>
>> 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.
>>
>> Is there anything that I missing?
>>
>> Best regards
>> Sergio



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


  
    
  
  
    
Maybe I am jumping to the conclusions
      too fast, but IMHO both RTX/FEC and header extensions should be
      HBH and not E2E.

      

      For header extensions I don't see a feasible way of negotiating
      the minimum common header extension subsets and getting all
      clients use the same extensions with same id. Also, I don't see
      much value in having the rtp header extensions E2E, as except the
      video orientation one, most of them are meant to be terminated at
      the MD (except the video orientation which would just need to be
      copied by the SFU).

      

      Also, I don't see any privacy issue doing extensions HBH, as they
      are transmitted in clear to the MD, and even more, the main
      purpose of the rfc6904 for encrypted header extensions was to
      protect the client to mixer/mixer to client audio indications,
      which by definition are not E2E and required by an SFU to operate.

      

      So IMHO, the inner encryption should be done on a "cloned" packet
      without extensions, and even more, we could use that encoded
      packet as the media payload of the outer encryption and forget
      about OHB completely and solve the RTX/FEC issue altogether. After
      all, it would be just a matter of adding an extra 12 bytes
      overhead (the full rtp payload header) vs the current OHB header
      extension, which could get also up to those 12 bytes if we need to
      include ssrc and ts.

      

      Best regards

      Sergio

      

      On 30/03/2017 18:31, Paul E. Jones wrote:

    

    

      
      
Sergio,

      


      

      
Your interpretation is correct, I think.  When we submitted
        the original proposal for PERC (that we called "PRIME"), the RTP
        payload itself was encrypted using an E2E key, but the headers
        only authenticated with a HBH key.  That draft was this:

      
      


      

      
This was proposed using a single
        crypto context with an additional E2E key.  Another way to have
        viewed this (which I think is perhaps easiest to comprehend) is
        that there were two contexts, one for E2E and one for HBH.  The
        E2E context would have used, for example, AES-CM with null
        authentication and the HBH context would have used null
        encryption and HMAC-SHA1 for authentication.  (Of course, any
        ciphers or auth functions could have been used.)  This would
        have allowed the middlebox to change headers as it saw fit, so
        long as we retained the fields required to re-construct the
        crypto contexts.  However, the need to maintain SSRC and
        sequence numbers to reconstruct the crypto context is where a lot of discussion
          took place that forced some discussion on how we had proposed
          to do the encryption.

      


      

      
Double addressed the issue of
        changing certain critical fields, while also moving toward
        authenticated encryption.  There were concerns with introducing
        a new RFC with a split in encryption and authentication, so
        Double addressed those concerns, too.

      


      

      
However, you're right that the
        negotiated values might present a problem.  I've not spent much
        time thinking about how to solve that.  During this meeting,
        there were also concerns raised with Double and how it works
        with RTX and FEC. Obviously, we need to get that right and
        perhaps those and the RTP header extension concerns you raise
        should both be topics for discussion in an interim meeting that
        the chairs will be arranging.

      


      

      
Paul

      


      

      
------ Original Message ------

      
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

      
      
Sent: 3/30/2017 11:16:11 AM

      
Subject: [Perc] Double Encryption and header extensions issue

      


      

      

        

          
Hi all,

          
I have been reviewing the documentation for double
            encryption and I have serious doubts about how the header
            extensions are handled.

          
If I have understood it (please correct me if I am wrong)
            the MD must rely all the header extensions present before
            the OHB to the other peers:

          
      The Media Distributor MUST NOT delete any header extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



          This is an obvious requirement, as to be able to decrypt the
          inner crypto, the end receiver must have the same original rtp
          packet, which includes header extensions.

          

          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.

          

          
Is there anything that I missing?

          

          Best regards

          Sergio

        

      

    

    


    

  


--------------0275EFEC5C563930DCE21FEE--


From nobody Thu Mar 30 10:42:05 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 619B5129452 for ; Thu, 30 Mar 2017 10:42:04 -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 r028d8OKHiG1 for ; Thu, 30 Mar 2017 10:42:01 -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 9D075129430 for ; Thu, 30 Mar 2017 10:42:01 -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 v2UHfxkw026893 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 13:41:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490895720; bh=/RTcGqtstgoRDMthMPribyC0TBpM/rv1KfX9zZLLW0c=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=qjigxi+ZO8ecsEWS2Y1XIsWLqvc+H96ZaXH5QxxZhqcx1uzGEqpr2dBSWnmuyNkTC 8+Hg9DbL3uKSxKukaeYimwIseYwSrdz1rT2KuIEO0K/Ru7YgjUhVjpA6cfmvjCgzp7 vMvA2sy/zzLl3KpBfdabUaa4r9u2MGiisVlW6Di8=
From: "Paul E. Jones" 
To: "Sergio Garcia Murillo" , perc@ietf.org
Date: Thu, 30 Mar 2017 17:42:00 +0000
Message-Id: 
In-Reply-To: <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBB3401448-3A12-44B3-A8AB-52E4A062051F"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 13:42:00 -0400 (EDT)
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: Thu, 30 Mar 2017 17:42:04 -0000

--------=_MBB3401448-3A12-44B3-A8AB-52E4A062051F
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sergio,

For RTX and FEC, I wasn't referring to the header extensions, but rather=20
how those are handled in light of "double."

What you suggest is certainly possible.  We could have the endpoints=20
insert the OHB as the first extension and then have all others follow=20
it.  That would make all extensions HBH, effectively.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" 
To: "Paul E. Jones" ; perc@ietf.org
Sent: 3/30/2017 1:02:39 PM
Subject: Re: [Perc] Double Encryption and header extensions issue

>Maybe I am jumping to the conclusions too fast, but IMHO both RTX/FEC=20
>and header extensions should be HBH and not E2E.
>
>For header extensions I don't see a feasible way of negotiating the=20
>minimum common header extension subsets and getting all clients use the=20
>same extensions with same id. Also, I don't see much value in having=20
>the rtp header extensions E2E, as except the video orientation one,=20
>most of them are meant to be terminated at the MD (except the video=20
>orientation which would just need to be copied by the SFU).
>
>Also, I don't see any privacy issue doing extensions HBH, as they are=20
>transmitted in clear to the MD, and even more, the main purpose of the=20
>rfc6904 for encrypted header extensions was to protect the client to=20
>mixer/mixer to client audio indications, which by definition are not=20
>E2E and required by an SFU to operate.
>
>So IMHO, the inner encryption should be done on a "cloned" packet=20
>without extensions, and even more, we could use that encoded packet as=20
>the media payload of the outer encryption and forget about OHB=20
>completely and solve the RTX/FEC issue altogether. After all, it would=20
>be just a matter of adding an extra 12 bytes overhead (the full rtp=20
>payload header) vs the current OHB header extension, which could get=20
>also up to those 12 bytes if we need to include ssrc and ts.
>
>Best regards
>Sergio
>
>On 30/03/2017 18:31, Paul E. Jones wrote:
>>Sergio,
>>
>>Your interpretation is correct, I think.  When we submitted the=20
>>original proposal for PERC (that we called "PRIME"), the RTP payload=20
>>itself was encrypted using an E2E key, but the headers only=20
>>authenticated with a HBH key.  That draft was this:
>>https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-0=
0
>>
>>This was proposed using a single crypto context with an additional E2E=20
>>key.  Another way to have viewed this (which I think is perhaps=20
>>easiest to comprehend) is that there were two contexts, one for E2E=20
>>and one for HBH.  The E2E context would have used, for example, AES-CM=20
>>with null authentication and the HBH context would have used null=20
>>encryption and HMAC-SHA1 for authentication.  (Of course, any ciphers=20
>>or auth functions could have been used.)  This would have allowed the=20
>>middlebox to change headers as it saw fit, so long as we retained the=20
>>fields required to re-construct the crypto contexts.  However, the=20
>>need to maintain SSRC and sequence numbers to reconstruct the crypto=20
>>context is where a lot of discussion took place that forced some=20
>>discussion on how we had proposed to do the encryption.
>>
>>Double addressed the issue of changing certain critical fields, while=20
>>also moving toward authenticated encryption.  There were concerns with=20
>>introducing a new RFC with a split in encryption and authentication,=20
>>so Double addressed those concerns, too.
>>
>>However, you're right that the negotiated values might present a=20
>>problem.  I've not spent much time thinking about how to solve that. =20
>>During this meeting, there were also concerns raised with Double and=20
>>how it works with RTX and FEC. Obviously, we need to get that right=20
>>and perhaps those and the RTP header extension concerns you raise=20
>>should both be topics for discussion in an interim meeting that the=20
>>chairs will be arranging.
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Sergio Garcia Murillo" 
>>To: perc@ietf.org
>>Sent: 3/30/2017 11:16:11 AM
>>Subject: [Perc] Double Encryption and header extensions issue
>>
>>>Hi all,
>>>
>>>I have been reviewing the documentation for double encryption and I=20
>>>have serious doubts about how the header extensions are handled.
>>>
>>>If I have understood it (please correct me if I am wrong) the MD must=20
>>>rely all the header extensions present before the OHB to the other=20
>>>peers:
>>>
>>>The Media Distributor MUST NOT delete any header extensions before=20
>>>the OHB, but MAY add, delete, or modify any that follow the OHB. This=20
>>>is an obvious requirement, as to be able to decrypt the inner crypto,=20
>>>the end receiver must have the same original rtp packet, which=20
>>>includes header extensions.
>>>
>>>My concerns is that there are scenarios in which this is not=20
>>>possible:
>>>Sender and receiver may not support same set of header=20
>>>extensionsSender and receiver may have negotiated a different id for=20
>>>same header extension
>>>In any of the previous scenarios, the receiver will not be able to=20
>>>parse the packet correctly, and at best case scenario, it will ignore=20
>>>the header extension.
>>>
>>>Is there anything that I missing?
>>>
>>>Best regards
>>>Sergio
>
>
--------=_MBB3401448-3A12-44B3-A8AB-52E4A062051F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


   =20
  
  
Sergio,

For RTX and FEC, I wasn't r=
eferring to the header extensions, but rather how those are handled in ligh=
t of "double."

What you suggest is certainly pos=
sible. =C2=A0We could have the endpoints insert the OHB as the first extens=
ion and then have all others follow it. =C2=A0That would make all extension=
s HBH, effectively.

Paul



------ Original Message ------


From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>


To: "Paul E. Jones" <paule=
j@packetizer.com>; perc@ietf.org


Sent: 3/30/2017 1:02:39 PM


Subject: Re: [Perc] Double Encryption and header extensions issue





    
Maybe I am jumping to the conclusions
      too fast, but IMHO both RTX/FEC and header extensions should be
      HBH and not E2E.

      

      For header extensions I don't see a feasible way of negotiating
      the minimum common header extension subsets and getting all
      clients use the same extensions with same id. Also, I don't see
      much value in having the rtp header extensions E2E, as except the
      video orientation one, most of them are meant to be terminated at
      the MD (except the video orientation which would just need to be
      copied by the SFU).

      

      Also, I don't see any privacy issue doing extensions HBH, as they
      are transmitted in clear to the MD, and even more, the main
      purpose of the rfc6904 for encrypted header extensions was to
      protect the client to mixer/mixer to client audio indications,
      which by definition are not E2E and required by an SFU to operate.

      

      So IMHO, the inner encryption should be done on a "cloned" packet
      without extensions, and even more, we could use that encoded
      packet as the media payload of the outer encryption and forget
      about OHB completely and solve the RTX/FEC issue altogether. After
      all, it would be just a matter of adding an extra 12 bytes
      overhead (the full rtp payload header) vs the current OHB header
      extension, which could get also up to those 12 bytes if we need to
      include ssrc and ts.

      

      Best regards

      Sergio

      

      On 30/03/2017 18:31, Paul E. Jones wrote:

    

    

      
Sergio,

      


      

      
Your interpretation is correct, I think. =C2=A0When we submitted
        the original proposal for PERC (that we called "PRIME"), the RTP
        payload itself was encrypted using an E2E key, but the headers
        only authenticated with a HBH key. =C2=A0That draft was this:

      
      


      

      
This was proposed using a single
        crypto context with an additional E2E key. =C2=A0Another way to hav=
e
        viewed this (which I think is perhaps easiest to comprehend) is
        that there were two contexts, one for E2E and one for HBH. =C2=A0Th=
e
        E2E context would have used, for example, AES-CM with null
        authentication and the HBH context would have used null
        encryption and HMAC-SHA1 for authentication. =C2=A0(Of course, any
        ciphers or auth functions could have been used.) =C2=A0This would
        have allowed the middlebox to change headers as it saw fit, so
        long as we retained the fields required to re-construct the
        crypto contexts. =C2=A0However, the need to maintain SSRC and
        sequence numbers to reconstruct the crypto context is where=C2=A0a lot of discussion
          took place that forced some discussion on how we had proposed
          to do the encryption.

      


      

      
Double addressed the issue of
        changing certain critical fields, while also moving toward
        authenticated encryption. =C2=A0There were concerns with introducin=
g
        a new RFC with a split in encryption and authentication, so
        Double addressed those concerns, too.

      


      

      
However, you're right that the
        negotiated values might present a problem. =C2=A0I've not spent muc=
h
        time thinking about how to solve that. =C2=A0During this meeting,
        there were also concerns raised with Double and how it works
        with RTX and FEC. Obviously, we need to get that right and
        perhaps those and the RTP header extension concerns you raise
        should both be topics for discussion in an interim meeting that
        the chairs will be arranging.

      


      

      
Paul

      


      

      
------ Original Message ------

      
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.c=
om>

      
      
Sent: 3/30/2017 11:16:11 AM

      
Subject: [Perc] Double Encryption and header extensions issue
      


      

      

        

          
Hi all,

          
I have been reviewing the documentation for double
            encryption and I have serious doubts about how the header
            extensions are handled.

          
If I have understood it (please correct me if I am wrong)
            the MD must rely all the header extensions present before
            the OHB to the other peers:

          
      The Media Distributor MUST NOT delete any header extens=
ions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



          This is an obvious requirement, as to be able to decrypt the
          inner crypto, the end receiver must have the same original rtp
          packet, which includes header extensions.

          

          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.

          

          
Is there anything that I missing?

          

          Best regards

          Sergio

        

      

    

    


    

  




--------=_MBB3401448-3A12-44B3-A8AB-52E4A062051F--


From nobody Thu Mar 30 10:54: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 2C94112952F for ; Thu, 30 Mar 2017 10:54:12 -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 2JkfAeFok9Rs for ; Thu, 30 Mar 2017 10:54:09 -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 BF138126557 for ; Thu, 30 Mar 2017 10:54:08 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id w11so70119895wrc.3 for ; Thu, 30 Mar 2017 10:54:08 -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=IRCQDAJa9KqhOgCt3jPUElyj213hnzP8CHPIZlB7iiU=; b=RYsEWC884yz9StEv263VWadBKj09mk9w04NkMCe5/iJsviavY6VWRZyoHpdVkR+Vyb 6L1rjt3tW7GBods+RohDv3oO8ia1pkGjKIWKZbjZ3vwmgzgmP5+mUt/gb5Tj1DevNs8r jasqI3XfHvigP46LA3vUQkRTUg1l7vd4GW7ccrAUbIjZZztATPeJox/WUKGmYKts5HkH bb34HsH6HelNSx88tjqXBJSrdEpjsq1+On+8c8eC7W+OFs5UIJ7nuP+OQJZenBV7NIPX Mts2V+/HmhkB9Mt2PYjSkTSHyJnW83p2HYqPoNjvyITvYdeY/V0LdbDxrp9YPCCj+E40 DRHA==
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=IRCQDAJa9KqhOgCt3jPUElyj213hnzP8CHPIZlB7iiU=; b=knk7d1VikwQlJ7NSDUimny28d+2ujGxMNBbMbmywp0Gn4ZS+KEPtTEpfXlI3ZwDfCz 2khT1ZAMQ32fm325P7z6IDRP5T5rvplGFBpz07WqmUqyT8MMNne3cykcuW+kYMgH0fE4 7B8CYAdFc462ChsL+YsNGhIEiKcDQgswfIKQ2YAg66UIzEy276oPLgBzBSnfOH5rcJK0 2+uVy2xbaoAhuDkEXYtTInc/aB0bn0bHyQNreqCIY/HKI6cTCbju+xLHNcbsMUtJp1If KxQ1ExyWZYa3hNNg3hOBdI7lXgjR+2zvS+d1FMKryjBNn4fRvbYCBqpoyyBQR6BvMJrr UAEw==
X-Gm-Message-State: AFeK/H08DnJ3smdSK9WaUeFqGJDGaa1ZLhQyk+WW70z14EqrPV5ut/by7S38gBKO0xK9yA==
X-Received: by 10.28.111.151 with SMTP id c23mr4660565wmi.17.1490896447031; Thu, 30 Mar 2017 10:54:07 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id y69sm2441523wmh.27.2017.03.30.10.54.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 10:54:06 -0700 (PDT)
To: "Paul E. Jones" , perc@ietf.org
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: 
Date: Thu, 30 Mar 2017 19:54:07 +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="------------40D1FF1F2E2C3E534A770DEA"
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: Thu, 30 Mar 2017 17:54:12 -0000

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

Hi Paul

Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause and 
solution, but let's keep that discussion on a separate thread.

Regarding OHB, as a developer, changing meaning of rtp headers depending 
on the relative position of the OHB feels very unfriendly for me, 
specially if I have later have to reconstruct the packet and apply 
padding to keep boundaries. Doesn't seem a clean solution IMHO.

I would really prefer to not touch the header extensions and move the 
OHB to the packet payload, which is were it belongs IMHO (same as OSN in 
normal RTX). That brings another question, which I will open on a new email.

Best regards
Sergio

On 30/03/2017 19:42, Paul E. Jones wrote:
> Sergio,
>
> For RTX and FEC, I wasn't referring to the header extensions, but 
> rather how those are handled in light of "double."
>
> What you suggest is certainly possible.  We could have the endpoints 
> insert the OHB as the first extension and then have all others follow 
> it.  That would make all extensions HBH, effectively.
>
> Paul
>
> ------ Original Message ------
> From: "Sergio Garcia Murillo"  >
> To: "Paul E. Jones"  >; perc@ietf.org 
> Sent: 3/30/2017 1:02:39 PM
> Subject: Re: [Perc] Double Encryption and header extensions issue
>
>> Maybe I am jumping to the conclusions too fast, but IMHO both RTX/FEC 
>> and header extensions should be HBH and not E2E.
>>
>> For header extensions I don't see a feasible way of negotiating the 
>> minimum common header extension subsets and getting all clients use 
>> the same extensions with same id. Also, I don't see much value in 
>> having the rtp header extensions E2E, as except the video orientation 
>> one, most of them are meant to be terminated at the MD (except the 
>> video orientation which would just need to be copied by the SFU).
>>
>> Also, I don't see any privacy issue doing extensions HBH, as they are 
>> transmitted in clear to the MD, and even more, the main purpose of 
>> the rfc6904 for encrypted header extensions was to protect the client 
>> to mixer/mixer to client audio indications, which by definition are 
>> not E2E and required by an SFU to operate.
>>
>> So IMHO, the inner encryption should be done on a "cloned" packet 
>> without extensions, and even more, we could use that encoded packet 
>> as the media payload of the outer encryption and forget about OHB 
>> completely and solve the RTX/FEC issue altogether. After all, it 
>> would be just a matter of adding an extra 12 bytes overhead (the full 
>> rtp payload header) vs the current OHB header extension, which could 
>> get also up to those 12 bytes if we need to include ssrc and ts.
>>
>> Best regards
>> Sergio
>>
>> On 30/03/2017 18:31, Paul E. Jones wrote:
>>> Sergio,
>>>
>>> Your interpretation is correct, I think.  When we submitted the 
>>> original proposal for PERC (that we called "PRIME"), the RTP payload 
>>> itself was encrypted using an E2E key, but the headers only 
>>> authenticated with a HBH key.  That draft was this:
>>> https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00
>>>
>>> This was proposed using a single crypto context with an additional 
>>> E2E key.  Another way to have viewed this (which I think is perhaps 
>>> easiest to comprehend) is that there were two contexts, one for E2E 
>>> and one for HBH.  The E2E context would have used, for example, 
>>> AES-CM with null authentication and the HBH context would have used 
>>> null encryption and HMAC-SHA1 for authentication.  (Of course, any 
>>> ciphers or auth functions could have been used.)  This would have 
>>> allowed the middlebox to change headers as it saw fit, so long as we 
>>> retained the fields required to re-construct the crypto contexts. 
>>>  However, the need to maintain SSRC and sequence numbers to 
>>> reconstruct the crypto context is where a lot of discussion took 
>>> place that forced some discussion on how we had proposed to do the 
>>> encryption.
>>>
>>> Double addressed the issue of changing certain critical fields, 
>>> while also moving toward authenticated encryption.  There were 
>>> concerns with introducing a new RFC with a split in encryption and 
>>> authentication, so Double addressed those concerns, too.
>>>
>>> However, you're right that the negotiated values might present a 
>>> problem.  I've not spent much time thinking about how to solve that. 
>>>  During this meeting, there were also concerns raised with Double 
>>> and how it works with RTX and FEC. Obviously, we need to get that 
>>> right and perhaps those and the RTP header extension concerns you 
>>> raise should both be topics for discussion in an interim meeting 
>>> that the chairs will be arranging.
>>>
>>> Paul
>>>
>>> ------ Original Message ------
>>> From: "Sergio Garcia Murillo" >> >
>>> To: perc@ietf.org 
>>> Sent: 3/30/2017 11:16:11 AM
>>> Subject: [Perc] Double Encryption and header extensions issue
>>>
>>>> Hi all,
>>>>
>>>> I have been reviewing the documentation for double encryption and I 
>>>> have serious doubts about how the header extensions are handled.
>>>>
>>>> If I have understood it (please correct me if I am wrong) the MD 
>>>> must rely all the header extensions present before the OHB to the 
>>>> other peers:
>>>>
>>>>        The Media Distributor MUST NOT delete any header extensions before
>>>>        the OHB, but MAY add, delete, or modify any that follow the OHB.
>>>>
>>>> This is an obvious requirement, as to be able to decrypt the inner 
>>>> crypto, the end receiver must have the same original rtp packet, 
>>>> which includes header extensions.
>>>>
>>>> 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.
>>>>
>>>> Is there anything that I missing?
>>>>
>>>> Best regards
>>>> Sergio
>>
>>


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


  
    
  
  
    
Hi Paul

      

      Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause
      and solution, but let's keep that discussion on a separate thread.

      

      Regarding OHB, as a developer, changing meaning of rtp headers
      depending on the relative position of the OHB feels very
      unfriendly for me, specially if I have later have to reconstruct
      the packet and apply padding to keep boundaries. Doesn't seem a
      clean solution IMHO.

      

      I would really prefer to not touch the header extensions and move
      the OHB to the packet payload, which is were it belongs IMHO (same
      as OSN in normal RTX). That brings another question, which I will
      open on a new email.

      

      Best regards

      Sergio

      

      On 30/03/2017 19:42, Paul E. Jones wrote:

    

    

      
      
Sergio,

      


      

      
For RTX and FEC, I wasn't referring to the header extensions,
        but rather how those are handled in light of "double."

      


      

      
What you suggest is certainly possible.  We could have the
        endpoints insert the OHB as the first extension and then have
        all others follow it.  That would make all extensions HBH,
        effectively.

      


      

      
Paul

      


      

      
------ Original Message ------

      
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

      
To: "Paul E. Jones" <paulej@packetizer.com>;
        perc@ietf.org

      
Sent: 3/30/2017 1:02:39 PM

      
Subject: Re: [Perc] Double Encryption and header extensions
        issue

      


      

      

        

          
Maybe I am jumping to the
            conclusions too fast, but IMHO both RTX/FEC and header
            extensions should be HBH and not E2E.

            

            For header extensions I don't see a feasible way of
            negotiating the minimum common header extension subsets and
            getting all clients use the same extensions with same id.
            Also, I don't see much value in having the rtp header
            extensions E2E, as except the video orientation one, most of
            them are meant to be terminated at the MD (except the video
            orientation which would just need to be copied by the SFU).

            

            Also, I don't see any privacy issue doing extensions HBH, as
            they are transmitted in clear to the MD, and even more, the
            main purpose of the rfc6904 for encrypted header extensions
            was to protect the client to mixer/mixer to client audio
            indications, which by definition are not E2E and required by
            an SFU to operate.

            

            So IMHO, the inner encryption should be done on a "cloned"
            packet without extensions, and even more, we could use that
            encoded packet as the media payload of the outer encryption
            and forget about OHB completely and solve the RTX/FEC issue
            altogether. After all, it would be just a matter of adding
            an extra 12 bytes overhead (the full rtp payload header) vs
            the current OHB header extension, which could get also up to
            those 12 bytes if we need to include ssrc and ts.

            

            Best regards

            Sergio

            

            On 30/03/2017 18:31, Paul E. Jones wrote:

          

          

            
            
Sergio,

            


            

            
Your interpretation is correct, I think.  When we
              submitted the original proposal for PERC (that we called
              "PRIME"), the RTP payload itself was encrypted using an
              E2E key, but the headers only authenticated with a HBH
              key.  That draft was this:

            
            


            

            
This was proposed using a
              single crypto context with an additional E2E key.  Another
              way to have viewed this (which I think is perhaps easiest
              to comprehend) is that there were two contexts, one for
              E2E and one for HBH.  The E2E context would have used, for
              example, AES-CM with null authentication and the HBH
              context would have used null encryption and HMAC-SHA1 for
              authentication.  (Of course, any ciphers or auth functions
              could have been used.)  This would have allowed the
              middlebox to change headers as it saw fit, so long as we
              retained the fields required to re-construct the crypto
              contexts.  However, the need to maintain SSRC and sequence
              numbers to reconstruct the crypto context is where a lot of
                discussion took place that forced some discussion on how
                we had proposed to do the encryption.

            


            

            
Double addressed the issue of
              changing certain critical fields, while also moving toward
              authenticated encryption.  There were concerns with
              introducing a new RFC with a split in encryption and
              authentication, so Double addressed those concerns, too.

            


            

            
However, you're right that the
              negotiated values might present a problem.  I've not spent
              much time thinking about how to solve that.  During this
              meeting, there were also concerns raised with Double and
              how it works with RTX and FEC. Obviously, we need to get
              that right and perhaps those and the RTP header extension
              concerns you raise should both be topics for discussion in
              an interim meeting that the chairs will be arranging.

            


            

            
Paul

            


            

            
------ Original Message ------

            
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

            
            
Sent: 3/30/2017 11:16:11 AM

            
Subject: [Perc] Double Encryption and header extensions
              issue

            


            

            

              

                
Hi all,

                
I have been reviewing the documentation for double
                  encryption and I have serious doubts about how the
                  header extensions are handled.

                
If I have understood it (please correct me if I am
                  wrong) the MD must rely all the header extensions
                  present before the OHB to the other peers:

                
      The Media Distributor MUST NOT delete any header extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



                This is an obvious requirement, as to be able to decrypt
                the inner crypto, the end receiver must have the same
                original rtp packet, which includes header extensions.

                

                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.

                

                
Is there anything that I missing?

                

                Best regards

                Sergio

              

            

          

          


          

        

      

    

    


    

  


--------------40D1FF1F2E2C3E534A770DEA--


From nobody Thu Mar 30 11:01: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 1953B1292C5 for ; Thu, 30 Mar 2017 11:01:09 -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 KE8nyuS6eA9R for ; Thu, 30 Mar 2017 11:01:07 -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 67679126557 for ; Thu, 30 Mar 2017 11:01:07 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id k6so65950147wre.2 for ; Thu, 30 Mar 2017 11:01:07 -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=1YXQqvdCsCVIrVghPSTCQ3aZs5ql5UgC+7w51X3wjBU=; b=bpgL7r8j7VlWwLsLR5SvVc1zDuZaU/h2G/WAo0FjLkRaLMwDuhwF4opr+ibVESLJLv 1ZpxcZg5W8yVHSt/0FrPEVIo+3WSy54ZSXntogvIkkfIxWkZIzHVa+I7ZH59uuRmoSlc 5buG687EvufVeR/b+IA5RwddlnlOAhnIxFdV91lorvSFzMzhvwl3svPobG6vJRXrueup 2fDNwVcc/TVzK+8TJqFx11/iRpgE5YrgRc04Lipscfa7C3nWtRClDrhGTJuN6B7LGjPD HWaZq1WJBWKsRb46C493+vGiQihpshqHCOZKM1nlpdf9SpeTXLnBxrBKq3/zgTKvqi0m yNQQ==
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=1YXQqvdCsCVIrVghPSTCQ3aZs5ql5UgC+7w51X3wjBU=; b=qb5mYa8/1pbbAOwFzjpvrp5b93Bamy16wsrONnAdc8N3hSp1Nu2Q/5lMv9HU6stHUB cOS4ng+2k5xW2SujV7cQMLYI/K6sc/xM5YZPEi3JA6AJ+vIursK/XQV7K3An6LS3qz4x 37h8er8lNYZyZtwz8ZZn7rgzwCKzJNN1AYfL7lzJvdlAurfUg3KkwAiDB9oB0tqFMSIg p7qv6LTM7TmOhOvQD8oQk/EcmLYKUdG1k1jhmTQwtdSXYH/ruutuHgWPbP8rmcoDnwdT /Pq7T522/FciB6IqmXEq5mJxHyiK5FgUTbB46jjV2y8LG3W7ZG9Twgl8mO15Cgukdr9l +vAw==
X-Gm-Message-State: AFeK/H2EZ9qVog3jHA+NjnX20lLJqTEQ8r9uTFgdraIVjETlcWQvX4qS5HP103NLt5L1Sw==
X-Received: by 10.28.107.14 with SMTP id g14mr4834551wmc.106.1490896865450; Thu, 30 Mar 2017 11:01:05 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id m29sm3661612wrm.4.2017.03.30.11.01.04 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 11:01:04 -0700 (PDT)
To: perc@ietf.org
From: Sergio Garcia Murillo 
Message-ID: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>
Date: Thu, 30 Mar 2017 20:01: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
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [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: Thu, 30 Mar 2017 18:01:09 -0000

Hi all,

I have another doubt about double encryption, which payload should it 
use. If I read the specs correctly the original media payload should be 
used for carrying the inner encrypted packet.

This doesn't seem very correct to me, as it breaks the semantic of the 
SDP. How about using an new codec/payload type for carrying that 
information and use an apt-like semantic for signaling the PT of the 
inner packet?

Best regards

Sergio


From nobody Thu Mar 30 13:04: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 10070127B31 for ; Thu, 30 Mar 2017 13:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 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, 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 SbNq8UzrnE7i for ; Thu, 30 Mar 2017 13:03:57 -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 3C9DB126B72 for ; Thu, 30 Mar 2017 13:03:57 -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 v2UK3seK007320 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 16:03:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490904235; bh=3I+jpsYfvrLTdEWaZEiPSDXWky/mu9c8MDdnJwg2nTE=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=gXifIsesTmtwyF4jesWTWcsxyTla7W9HdSRv1jRTyLfKsvco6n+iV7V+pkLVy9LXr 464SS+0oCpOcS/Hl3DicgssF693YALZR9N3PXLjnog59AL5PuOC0X0lJ6A1LvCXo8L vSwIHpxyTx8btZUu52HQe5CoGRpd3oNJs2KCFzms=
From: "Paul E. Jones" 
To: "Sergio Garcia Murillo" , perc@ietf.org
Date: Thu, 30 Mar 2017 20:03:56 +0000
Message-Id: 
In-Reply-To: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 16:03:55 -0400 (EDT)
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: Thu, 30 Mar 2017 20:03:59 -0000

Sergio,

I don't fully understand your question, since we did not define an=20
"inner packet".  There are two encryption passes over the packet using=20
two different keys, so I guess you're referring to the first encryption=20
pass.

We do not change the PT when we apply SRTP, so applying "double" should=20
not result in a new PT, either.  It's just a new "transform".

So, I'm not sure what you mean here.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" 
To: perc@ietf.org
Sent: 3/30/2017 2:01:06 PM
Subject: [Perc] Double encryption codec/payload type

>Hi all,
>
>I have another doubt about double encryption, which payload should it=20
>use. If I read the specs correctly the original media payload should be=20
>used for carrying the inner encrypted packet.
>
>This doesn't seem very correct to me, as it breaks the semantic of the=20
>SDP. How about using an new codec/payload type for carrying that=20
>information and use an apt-like semantic for signaling the PT of the=20
>inner packet?
>
>Best regards
>
>Sergio
>
>_______________________________________________
>Perc mailing list
>Perc@ietf.org
>https://www.ietf.org/mailman/listinfo/perc


From nobody Thu Mar 30 13:20: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 180D41293D9 for ; Thu, 30 Mar 2017 13:20:35 -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 dn7tzwcTWmrA for ; Thu, 30 Mar 2017 13:20:32 -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 DB0121292FD for ; Thu, 30 Mar 2017 13:20:30 -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 v2UKKSLT008939 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 16:20:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490905229; bh=4uCJW7F3WDIOG7Itr+D+//tbDgthzDOyA+Qw8UNTMmM=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=VbmpEGo1xe6EIX6iUOBsF+O1JP/gvNWXRmkTzOAlCNVF/GAq96PmK9/LiJ6papNAU FCYmci0nbFel/wlhFJITYT6JBkhEGRWdHJQ1tCZpmoSFXBqiSmPHN7ibJIhBHlBiDf pWFH8Hiuls0qus4UlKvR/m5GIXuBaJJuW+BBEmDk=
From: "Paul E. Jones" 
To: "Sergio Garcia Murillo" , perc@ietf.org
Date: Thu, 30 Mar 2017 20:20:30 +0000
Message-Id: 
In-Reply-To: 
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>  
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBCB98D5D7-1DF8-4A01-B435-CD7AFBDE496F"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 16:20:29 -0400 (EDT)
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: Thu, 30 Mar 2017 20:20:35 -0000

--------=_MBCB98D5D7-1DF8-4A01-B435-CD7AFBDE496F
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sergio,

Moving the OHB to the payload is doable, but perhaps a better solution=20
is simply have the endpoint always insert the OHB as the first header=20
extension.  We could also pre-populate that with every single value that=20
we might ever want to change (i.e., allow it to be a fixed size). =20
Having a fixed-size was suggested yesterday in the meeting.  It would=20
mean, though, that the header extensions are not E2E authenticated or=20
encrypted.  I don't know how important that might be to anyone.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" 
To: "Paul E. Jones" ; perc@ietf.org
Sent: 3/30/2017 1:54:07 PM
Subject: Re: [Perc] Double Encryption and header extensions issue

>Hi Paul
>
>Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause and=20
>solution, but let's keep that discussion on a separate thread.
>
>Regarding OHB, as a developer, changing meaning of rtp headers=20
>depending on the relative position of the OHB feels very unfriendly for=20
>me, specially if I have later have to reconstruct the packet and apply=20
>padding to keep boundaries. Doesn't seem a clean solution IMHO.
>
>I would really prefer to not touch the header extensions and move the=20
>OHB to the packet payload, which is were it belongs IMHO (same as OSN=20
>in normal RTX). That brings another question, which I will open on a=20
>new email.
>
>Best regards
>Sergio
>
>On 30/03/2017 19:42, Paul E. Jones wrote:
>>Sergio,
>>
>>For RTX and FEC, I wasn't referring to the header extensions, but=20
>>rather how those are handled in light of "double."
>>
>>What you suggest is certainly possible.  We could have the endpoints=20
>>insert the OHB as the first extension and then have all others follow=20
>>it.  That would make all extensions HBH, effectively.
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Sergio Garcia Murillo" 
>>To: "Paul E. Jones" ; perc@ietf.org
>>Sent: 3/30/2017 1:02:39 PM
>>Subject: Re: [Perc] Double Encryption and header extensions issue
>>
>>>Maybe I am jumping to the conclusions too fast, but IMHO both RTX/FEC=20
>>>and header extensions should be HBH and not E2E.
>>>
>>>For header extensions I don't see a feasible way of negotiating the=20
>>>minimum common header extension subsets and getting all clients use=20
>>>the same extensions with same id. Also, I don't see much value in=20
>>>having the rtp header extensions E2E, as except the video orientation=20
>>>one, most of them are meant to be terminated at the MD (except the=20
>>>video orientation which would just need to be copied by the SFU).
>>>
>>>Also, I don't see any privacy issue doing extensions HBH, as they are=20
>>>transmitted in clear to the MD, and even more, the main purpose of=20
>>>the rfc6904 for encrypted header extensions was to protect the client=20
>>>to mixer/mixer to client audio indications, which by definition are=20
>>>not E2E and required by an SFU to operate.
>>>
>>>So IMHO, the inner encryption should be done on a "cloned" packet=20
>>>without extensions, and even more, we could use that encoded packet=20
>>>as the media payload of the outer encryption and forget about OHB=20
>>>completely and solve the RTX/FEC issue altogether. After all, it=20
>>>would be just a matter of adding an extra 12 bytes overhead (the full=20
>>>rtp payload header) vs the current OHB header extension, which could=20
>>>get also up to those 12 bytes if we need to include ssrc and ts.
>>>
>>>Best regards
>>>Sergio
>>>
>>>On 30/03/2017 18:31, Paul E. Jones wrote:
>>>>Sergio,
>>>>
>>>>Your interpretation is correct, I think.  When we submitted the=20
>>>>original proposal for PERC (that we called "PRIME"), the RTP payload=20
>>>>itself was encrypted using an E2E key, but the headers only=20
>>>>authenticated with a HBH key.  That draft was this:
>>>>https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework=
-00
>>>>
>>>>This was proposed using a single crypto context with an additional=20
>>>>E2E key.  Another way to have viewed this (which I think is perhaps=20
>>>>easiest to comprehend) is that there were two contexts, one for E2E=20
>>>>and one for HBH.  The E2E context would have used, for example,=20
>>>>AES-CM with null authentication and the HBH context would have used=20
>>>>null encryption and HMAC-SHA1 for authentication.  (Of course, any=20
>>>>ciphers or auth functions could have been used.)  This would have=20
>>>>allowed the middlebox to change headers as it saw fit, so long as we=20
>>>>retained the fields required to re-construct the crypto contexts. =20
>>>>However, the need to maintain SSRC and sequence numbers to=20
>>>>reconstruct the crypto context is where a lot of discussion took=20
>>>>place that forced some discussion on how we had proposed to do the=20
>>>>encryption.
>>>>
>>>>Double addressed the issue of changing certain critical fields,=20
>>>>while also moving toward authenticated encryption.  There were=20
>>>>concerns with introducing a new RFC with a split in encryption and=20
>>>>authentication, so Double addressed those concerns, too.
>>>>
>>>>However, you're right that the negotiated values might present a=20
>>>>problem.  I've not spent much time thinking about how to solve that.=20
>>>>  During this meeting, there were also concerns raised with Double=20
>>>>and how it works with RTX and FEC. Obviously, we need to get that=20
>>>>right and perhaps those and the RTP header extension concerns you=20
>>>>raise should both be topics for discussion in an interim meeting=20
>>>>that the chairs will be arranging.
>>>>
>>>>Paul
>>>>
>>>>------ Original Message ------
>>>>From: "Sergio Garcia Murillo" 
>>>>To: perc@ietf.org
>>>>Sent: 3/30/2017 11:16:11 AM
>>>>Subject: [Perc] Double Encryption and header extensions issue
>>>>
>>>>>Hi all,
>>>>>
>>>>>I have been reviewing the documentation for double encryption and I=20
>>>>>have serious doubts about how the header extensions are handled.
>>>>>
>>>>>If I have understood it (please correct me if I am wrong) the MD=20
>>>>>must rely all the header extensions present before the OHB to the=20
>>>>>other peers:
>>>>>
>>>>>The Media Distributor MUST NOT delete any header extensions before=20
>>>>>the OHB, but MAY add, delete, or modify any that follow the OHB.=20
>>>>>This is an obvious requirement, as to be able to decrypt the inner=20
>>>>>crypto, the end receiver must have the same original rtp packet,=20
>>>>>which includes header extensions.
>>>>>
>>>>>My concerns is that there are scenarios in which this is not=20
>>>>>possible:
>>>>>Sender and receiver may not support same set of header=20
>>>>>extensionsSender and receiver may have negotiated a different id=20
>>>>>for same header extension
>>>>>In any of the previous scenarios, the receiver will not be able to=20
>>>>>parse the packet correctly, and at best case scenario, it will=20
>>>>>ignore the header extension.
>>>>>
>>>>>Is there anything that I missing?
>>>>>
>>>>>Best regards
>>>>>Sergio
>>>
>>>
>
>
--------=_MBCB98D5D7-1DF8-4A01-B435-CD7AFBDE496F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


   =20
  
  
Sergio,

Moving the OHB to the paylo=
ad is doable, but perhaps a better solution is simply have the endpoint alw=
ays insert the OHB as the first header extension. =C2=A0We could also pre-p=
opulate that with every single value that we might ever want to change (i.e=
., allow it to be a fixed size). =C2=A0Having a fixed-size was suggested ye=
sterday in the meeting. =C2=A0It would mean, though, that the header extens=
ions are not E2E authenticated or encrypted. =C2=A0I don't know how importa=
nt that might be to anyone.

Paul



------ Original Message ------


From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>


To: "Paul E. Jones" <paule=
j@packetizer.com>; perc@ietf.org


Sent: 3/30/2017 1:54:07 PM


Subject: Re: [Perc] Double Encryption and header extensions issue





    
Hi Paul

      

      Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause
      and solution, but let's keep that discussion on a separate thread.

      

      Regarding OHB, as a developer, changing meaning of rtp headers
      depending on the relative position of the OHB feels very
      unfriendly for me, specially if I have later have to reconstruct
      the packet and apply padding to keep boundaries. Doesn't seem a
      clean solution IMHO.

      

      I would really prefer to not touch the header extensions and move
      the OHB to the packet payload, which is were it belongs IMHO (same
      as OSN in normal RTX). That brings another question, which I will
      open on a new email.

      

      Best regards

      Sergio

      

      On 30/03/2017 19:42, Paul E. Jones wrote:

    

    

      
Sergio,

      


      

      
For RTX and FEC, I wasn't referring to the header extensions,
        but rather how those are handled in light of "double."

      


      

      
What you suggest is certainly possible. =C2=A0We could have the
        endpoints insert the OHB as the first extension and then have
        all others follow it. =C2=A0That would make all extensions HBH,
        effectively.

      


      

      
Paul

      


      

      
------ Original Message ------

      
      
To: "Paul E. Jones" <paulej@packetizer.com>;
        perc@ietf=
.org

      
Sent: 3/30/2017 1:02:39 PM

      
Subject: Re: [Perc] Double Encryption and header extensions
        issue

      


      

      

        

          
Maybe I am jumping to the
            conclusions too fast, but IMHO both RTX/FEC and header
            extensions should be HBH and not E2E.

            

            For header extensions I don't see a feasible way of
            negotiating the minimum common header extension subsets and
            getting all clients use the same extensions with same id.
            Also, I don't see much value in having the rtp header
            extensions E2E, as except the video orientation one, most of
            them are meant to be terminated at the MD (except the video
            orientation which would just need to be copied by the SFU).
            

            Also, I don't see any privacy issue doing extensions HBH, as
            they are transmitted in clear to the MD, and even more, the
            main purpose of the rfc6904 for encrypted header extensions
            was to protect the client to mixer/mixer to client audio
            indications, which by definition are not E2E and required by
            an SFU to operate.

            

            So IMHO, the inner encryption should be done on a "cloned"
            packet without extensions, and even more, we could use that
            encoded packet as the media payload of the outer encryption
            and forget about OHB completely and solve the RTX/FEC issue
            altogether. After all, it would be just a matter of adding
            an extra 12 bytes overhead (the full rtp payload header) vs
            the current OHB header extension, which could get also up to
            those 12 bytes if we need to include ssrc and ts.

            

            Best regards

            Sergio

            

            On 30/03/2017 18:31, Paul E. Jones wrote:

          

          

            
            
Sergio,

            


            

            
Your interpretation is correct, I think. =C2=A0When we
              submitted the original proposal for PERC (that we called
              "PRIME"), the RTP payload itself was encrypted using an
              E2E key, but the headers only authenticated with a HBH
              key. =C2=A0That draft was this:

            
            


            

            
This was proposed using a
              single crypto context with an additional E2E key. =C2=A0Anoth=
er
              way to have viewed this (which I think is perhaps easiest
              to comprehend) is that there were two contexts, one for
              E2E and one for HBH. =C2=A0The E2E context would have used, f=
or
              example, AES-CM with null authentication and the HBH
              context would have used null encryption and HMAC-SHA1 for
              authentication. =C2=A0(Of course, any ciphers or auth functio=
ns
              could have been used.) =C2=A0This would have allowed the
              middlebox to change headers as it saw fit, so long as we
              retained the fields required to re-construct the crypto
              contexts. =C2=A0However, the need to maintain SSRC and sequen=
ce
              numbers to reconstruct the crypto context is where=C2=A0a lot of
                discussion took place that forced some discussion on how
                we had proposed to do the encryption.

            


            

            
Double addressed the issue of
              changing certain critical fields, while also moving toward
              authenticated encryption. =C2=A0There were concerns with
              introducing a new RFC with a split in encryption and
              authentication, so Double addressed those concerns, too.
            


            

            
However, you're right that the
              negotiated values might present a problem. =C2=A0I've not spe=
nt
              much time thinking about how to solve that. =C2=A0During this
              meeting, there were also concerns raised with Double and
              how it works with RTX and FEC. Obviously, we need to get
              that right and perhaps those and the RTP header extension
              concerns you raise should both be topics for discussion in
              an interim meeting that the chairs will be arranging.

            


            

            
Paul

            


            

            
------ Original Message ------

            
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@g=
mail.com>

            
            
Sent: 3/30/2017 11:16:11 AM

            
Subject: [Perc] Double Encryption and header extensions
              issue

            


            

            

              

                
Hi all,

                
I have been reviewing the documentation for double
                  encryption and I have serious doubts about how the
                  header extensions are handled.

                
If I have understood it (please correct me if I am
                  wrong) the MD must rely all the header extensions
                  present before the OHB to the other peers:

                
      The Media Distributor MUST NOT delete any header=
 extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



                This is an obvious requirement, as to be able to decrypt
                the inner crypto, the end receiver must have the same
                original rtp packet, which includes header extensions.

                

                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.

                

                
Is there anything that I missing?

                

                Best regards

                Sergio

              

            

          

          


          

        

      

    

    


    

  




--------=_MBCB98D5D7-1DF8-4A01-B435-CD7AFBDE496F--


From nobody Thu Mar 30 13:22: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 EC944126B72 for ; Thu, 30 Mar 2017 13:22:47 -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 h7sxOxCiPQr3 for ; Thu, 30 Mar 2017 13:22:46 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 0B885129476 for ; Thu, 30 Mar 2017 13:22:45 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id w43so76699896wrb.0 for ; Thu, 30 Mar 2017 13:22:45 -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=kHwWpoRSeI61zPlvDNi+1ZrUfdj3ydyno8JMxwFgHjw=; b=VhyFV0OY9HJFzUa0pHW/UJrLc4GBJJCkyNw1S4GCdLRrRnwxPPGvOiy80GGM8/IMTC 5mLcVDAc6UvFtH9TPh15icVh8F0N2HvlGGSv31z1hxZZngU0aqW3AtcMez5Nm55QjVii VM30YlzIwQvDIiM9JyTpmn8xW3jeZP9TcZi+IOUgxYdSGCeoaxdNJlPrLFWLvxzd/yOk bNOdHxo3tJ7vhUrUoaE9a9femuRa0jqO3sJuAiYIPYaqqQUZ9Wiw/BLoptjVZ/isFdgf 1kBAUD+npQ7gxGqxDSZ6uQFcOCT+m+eUCIKC0dRF+NoHBgIoTIx5INuwJJeX7ELPW54c QgDA==
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=kHwWpoRSeI61zPlvDNi+1ZrUfdj3ydyno8JMxwFgHjw=; b=gwGF0FO0YGnTD+G/54XjtpNmkpMlvTlVKKwF2wYW19+MUf01olG9pmctVohjxtKWxx J2FfON03stZaUyZ0HNYszWBKPfD49JrWpbZrR0c3Ltq2dl6nDSKlURV2HI9cN5Zcmrcq hcuoWDdFvOiyCm8dWputtktRMxQ/Q5pCQnk5/mwjE7DF87zi5jcPJyTV5uFsrMNYGKeT 9xqdzo0eeT+NmfYf+GrLE4TOwbrIsxiYIo5/1AZSa/ApL27x4SsF65oStpG/tazvC120 ZmMfAM4jl+CA9bu6el0LBv2/iBy0+u1IkfmiiZqFLaBxe2756XH7VhGrEEp9YBEelpP2 aCnA==
X-Gm-Message-State: AFeK/H2kpNfDPuPaXM6E/rE8d5Ggw+qozIB8dEZCLTVXNgdGk5phrsCTILFQTRv6DOd7Wg==
X-Received: by 10.223.153.142 with SMTP id y14mr1346358wrb.193.1490905364166;  Thu, 30 Mar 2017 13:22:44 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id q1sm4004172wra.65.2017.03.30.13.22.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 13:22:43 -0700 (PDT)
To: "Paul E. Jones" , perc@ietf.org
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com>
Date: Thu, 30 Mar 2017 22:22: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: text/plain; charset=utf-8; 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: Thu, 30 Mar 2017 20:22:48 -0000

For me conceptually you are just tunneling an rtp over rtp, at least 
this is how I am implementing it. Let me explain.

For applying the first crypto, you need an rtp packet (my "inner 
packet), of the resulting srtp packet, you are creating another rtp 
packet ("outher packet) with happens to have same rtp header, copy the 
encrypted payload of the encrypted inner packet, encrypt it again and 
send it to the MD.

The MD then decrypts the  it, removes the "outher packet", and 
creates/encrypts another "outher packet"  with the payload, to send it 
to the receiver, but the receiver in order decrypt it, needs to recreate 
the original "inner packet", that's why we are sending the the OHB data.

At the end this is a very similar mechanism to RED/FEC or even RTX, so 
that's why I think that it could make sense to use a new codec/payload 
to signal it.

The other alternative to signal this on the SDP would be to change the 
transport to somthing like UDP/TLS/RTP/TLS/RTP/SAVPF (or whatever) but I 
don't think that would be semantically correct, as the inner encryption 
can't be terminated at the MD. So in fact, what you are transporting on 
the RTP packet is an encrypted payload, whin in SDP semantics requires a 
codec and a payload.

What is your view about this?

Best regards
Sergio



On 30/03/2017 22:03, Paul E. Jones wrote:
> Sergio,
>
> I don't fully understand your question, since we did not define an 
> "inner packet".  There are two encryption passes over the packet using 
> two different keys, so I guess you're referring to the first 
> encryption pass.
>
> We do not change the PT when we apply SRTP, so applying "double" 
> should not result in a new PT, either.  It's just a new "transform".
>
> So, I'm not sure what you mean here.
>
> Paul
>
> ------ Original Message ------
> From: "Sergio Garcia Murillo" 
> To: perc@ietf.org
> Sent: 3/30/2017 2:01:06 PM
> Subject: [Perc] Double encryption codec/payload type
>
>> Hi all,
>>
>> I have another doubt about double encryption, which payload should it 
>> use. If I read the specs correctly the original media payload should 
>> be used for carrying the inner encrypted packet.
>>
>> This doesn't seem very correct to me, as it breaks the semantic of 
>> the SDP. How about using an new codec/payload type for carrying that 
>> information and use an apt-like semantic for signaling the PT of the 
>> inner packet?
>>
>> Best regards
>>
>> Sergio
>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org
>> https://www.ietf.org/mailman/listinfo/perc
>


From nobody Thu Mar 30 13:29: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 9E0C61292FD for ; Thu, 30 Mar 2017 13:29:17 -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 d6PAicv073jh for ; Thu, 30 Mar 2017 13:29:09 -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 D6ECE1270FC for ; Thu, 30 Mar 2017 13:29:08 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id l43so78489686wre.1 for ; Thu, 30 Mar 2017 13:29:08 -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=+JPu+g+CrrrWqEPyKwHLHb5E27lBznf8W95MaqK6jYE=; b=I3YGEgYb9TRUvG8X1USL71KLAL4fxy8PbbpP13vwhPEaQvRo/nPzjlTYrMrN4RluZO Dv4DX7McujMfYUw+WHT8PYysU/qxjq1UtEGq29P1bk1ymqx1sjtMSY0DExbAN4nYDRtH XEMNCXnzjDXSxYUdFhgK/ehMHafmM+3jA44hL3ruxMoh0Pul/7iR6K/1KDftgTTYT3OI AdmSXMwTfPxuclwM+deff+B840XjzT6rxb59tTIqx94rGW0GtAnnI9jK7PNPnc+o0bUU bcOznG/bSAmUFe9afH3PDK7cUWBl/p+dMAQScYa6+ZdfpslulPRboKpPkguSO3BwtLrW Xzow==
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=+JPu+g+CrrrWqEPyKwHLHb5E27lBznf8W95MaqK6jYE=; b=VTOwcz7M3/t7lLYow2xILiQ8/lr0lmpTKimV9wMLWZM2sKiIAoKiJ2kfUcGdEkCzqK V7JzZyyKV9sg5olR/hTityc7ljtzHLTWEoee7KnY3iYfilad2+OUGc6MMvekGc3q1td2 BXFBzH2060ggAe3UQ8cvPR368VeqricdDF7YU7iHGZvAVQ6FbbEPg6EGIEQpKV5viCKg EwK2pJIQYxR/dq80PbxIY9+ILAjKoBLFwnRVBJ/nxmbcChiCzAVJ9+N6FSx9JGvUQhW8 7G+Ca516LVYqx7lkGIaojsf0O/FwkpELefewyqgHLlTSt1iOdF5pZbh7Z4ZpGUcueGyr 05iA==
X-Gm-Message-State: AFeK/H0f9NaCu52vyG9th5oQdrl9cNlXCB5CHeCN9k7mFkc8z5baQKsa/h1uW2/QOisuoQ==
X-Received: by 10.28.229.140 with SMTP id c134mr61097wmh.29.1490905747328; Thu, 30 Mar 2017 13:29:07 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id 110sm4006305wra.49.2017.03.30.13.29.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 13:29:06 -0700 (PDT)
To: "Paul E. Jones" , perc@ietf.org
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>   
From: Sergio Garcia Murillo 
Message-ID: 
Date: Thu, 30 Mar 2017 22:29:08 +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="------------BC881697AF7ED228AFD23ACF"
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: Thu, 30 Mar 2017 20:29:18 -0000

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

One thing I realized is that adding OHB in the payload would mean that 
it is also sent from the sender to the MD, which would be an unnecessary 
overhead.

Regarding encrypted  extensions, I think that the question is even more 
basic, can we have e2e extensions? My view is that it is not possible 
because extensions and ids are negotiated HBH, not E2E.

If we don't (can't) have E2E extensions, there is no reason at all to 
mandate OHB to be at any specific position, and we will not change 
current rtp header extensions, making it much more easy to implement it 
in current products.

Best regards
Sergio

On 30/03/2017 22:20, Paul E. Jones wrote:
> Sergio,
>
> Moving the OHB to the payload is doable, but perhaps a better solution 
> is simply have the endpoint always insert the OHB as the first header 
> extension.  We could also pre-populate that with every single value 
> that we might ever want to change (i.e., allow it to be a fixed size). 
>  Having a fixed-size was suggested yesterday in the meeting.  It would 
> mean, though, that the header extensions are not E2E authenticated or 
> encrypted.  I don't know how important that might be to anyone.
>
> Paul
>
> ------ Original Message ------
> From: "Sergio Garcia Murillo"  >
> To: "Paul E. Jones"  >; perc@ietf.org 
> Sent: 3/30/2017 1:54:07 PM
> Subject: Re: [Perc] Double Encryption and header extensions issue
>
>> Hi Paul
>>
>> Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause 
>> and solution, but let's keep that discussion on a separate thread.
>>
>> Regarding OHB, as a developer, changing meaning of rtp headers 
>> depending on the relative position of the OHB feels very unfriendly 
>> for me, specially if I have later have to reconstruct the packet and 
>> apply padding to keep boundaries. Doesn't seem a clean solution IMHO.
>>
>> I would really prefer to not touch the header extensions and move the 
>> OHB to the packet payload, which is were it belongs IMHO (same as OSN 
>> in normal RTX). That brings another question, which I will open on a 
>> new email.
>>
>> Best regards
>> Sergio
>>
>> On 30/03/2017 19:42, Paul E. Jones wrote:
>>> Sergio,
>>>
>>> For RTX and FEC, I wasn't referring to the header extensions, but 
>>> rather how those are handled in light of "double."
>>>
>>> What you suggest is certainly possible.  We could have the endpoints 
>>> insert the OHB as the first extension and then have all others 
>>> follow it.  That would make all extensions HBH, effectively.
>>>
>>> Paul
>>>
>>> ------ Original Message ------
>>> From: "Sergio Garcia Murillo" >> >
>>> To: "Paul E. Jones" >> >; perc@ietf.org 
>>> Sent: 3/30/2017 1:02:39 PM
>>> Subject: Re: [Perc] Double Encryption and header extensions issue
>>>
>>>> Maybe I am jumping to the conclusions too fast, but IMHO both 
>>>> RTX/FEC and header extensions should be HBH and not E2E.
>>>>
>>>> For header extensions I don't see a feasible way of negotiating the 
>>>> minimum common header extension subsets and getting all clients use 
>>>> the same extensions with same id. Also, I don't see much value in 
>>>> having the rtp header extensions E2E, as except the video 
>>>> orientation one, most of them are meant to be terminated at the MD 
>>>> (except the video orientation which would just need to be copied by 
>>>> the SFU).
>>>>
>>>> Also, I don't see any privacy issue doing extensions HBH, as they 
>>>> are transmitted in clear to the MD, and even more, the main purpose 
>>>> of the rfc6904 for encrypted header extensions was to protect the 
>>>> client to mixer/mixer to client audio indications, which by 
>>>> definition are not E2E and required by an SFU to operate.
>>>>
>>>> So IMHO, the inner encryption should be done on a "cloned" packet 
>>>> without extensions, and even more, we could use that encoded packet 
>>>> as the media payload of the outer encryption and forget about OHB 
>>>> completely and solve the RTX/FEC issue altogether. After all, it 
>>>> would be just a matter of adding an extra 12 bytes overhead (the 
>>>> full rtp payload header) vs the current OHB header extension, which 
>>>> could get also up to those 12 bytes if we need to include ssrc and ts.
>>>>
>>>> Best regards
>>>> Sergio
>>>>
>>>> On 30/03/2017 18:31, Paul E. Jones wrote:
>>>>> Sergio,
>>>>>
>>>>> Your interpretation is correct, I think.  When we submitted the 
>>>>> original proposal for PERC (that we called "PRIME"), the RTP 
>>>>> payload itself was encrypted using an E2E key, but the headers 
>>>>> only authenticated with a HBH key.  That draft was this:
>>>>> https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00
>>>>>
>>>>> This was proposed using a single crypto context with an additional 
>>>>> E2E key.  Another way to have viewed this (which I think is 
>>>>> perhaps easiest to comprehend) is that there were two contexts, 
>>>>> one for E2E and one for HBH.  The E2E context would have used, for 
>>>>> example, AES-CM with null authentication and the HBH context would 
>>>>> have used null encryption and HMAC-SHA1 for authentication.  (Of 
>>>>> course, any ciphers or auth functions could have been used.)  This 
>>>>> would have allowed the middlebox to change headers as it saw fit, 
>>>>> so long as we retained the fields required to re-construct the 
>>>>> crypto contexts.  However, the need to maintain SSRC and sequence 
>>>>> numbers to reconstruct the crypto context is where a lot of 
>>>>> discussion took place that forced some discussion on how we had 
>>>>> proposed to do the encryption.
>>>>>
>>>>> Double addressed the issue of changing certain critical fields, 
>>>>> while also moving toward authenticated encryption.  There were 
>>>>> concerns with introducing a new RFC with a split in encryption and 
>>>>> authentication, so Double addressed those concerns, too.
>>>>>
>>>>> However, you're right that the negotiated values might present a 
>>>>> problem.  I've not spent much time thinking about how to solve 
>>>>> that.  During this meeting, there were also concerns raised with 
>>>>> Double and how it works with RTX and FEC. Obviously, we need to 
>>>>> get that right and perhaps those and the RTP header extension 
>>>>> concerns you raise should both be topics for discussion in an 
>>>>> interim meeting that the chairs will be arranging.
>>>>>
>>>>> Paul
>>>>>
>>>>> ------ Original Message ------
>>>>> From: "Sergio Garcia Murillo" >>>> >
>>>>> To: perc@ietf.org 
>>>>> Sent: 3/30/2017 11:16:11 AM
>>>>> Subject: [Perc] Double Encryption and header extensions issue
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have been reviewing the documentation for double encryption and 
>>>>>> I have serious doubts about how the header extensions are handled.
>>>>>>
>>>>>> If I have understood it (please correct me if I am wrong) the MD 
>>>>>> must rely all the header extensions present before the OHB to the 
>>>>>> other peers:
>>>>>>
>>>>>>        The Media Distributor MUST NOT delete any header extensions before
>>>>>>        the OHB, but MAY add, delete, or modify any that follow the OHB.
>>>>>>
>>>>>> This is an obvious requirement, as to be able to decrypt the 
>>>>>> inner crypto, the end receiver must have the same original rtp 
>>>>>> packet, which includes header extensions.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Is there anything that I missing?
>>>>>>
>>>>>> Best regards
>>>>>> Sergio
>>>>
>>>>
>>


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


  
    
  
  
    
One thing I realized is that adding OHB
      in the payload would mean that it is also sent from the sender to
      the MD, which would be an unnecessary overhead.

      

      Regarding encrypted  extensions, I think that the question is even
      more basic, can we have e2e extensions? My view is that it is not
      possible because extensions and ids are negotiated HBH, not E2E.

      

      If we don't (can't) have E2E extensions, there is no reason at all
      to mandate OHB to be at any specific position, and we will not
      change current rtp header extensions, making it much more easy to
      implement it in current products.

      

      Best regards

      Sergio

      

      On 30/03/2017 22:20, Paul E. Jones wrote:

    

    

      
      
Sergio,

      


      

      
Moving the OHB to the payload is doable, but perhaps a better
        solution is simply have the endpoint always insert the OHB as
        the first header extension.  We could also pre-populate that
        with every single value that we might ever want to change (i.e.,
        allow it to be a fixed size).  Having a fixed-size was suggested
        yesterday in the meeting.  It would mean, though, that the
        header extensions are not E2E authenticated or encrypted.  I
        don't know how important that might be to anyone.

      


      

      
Paul

      


      

      
------ Original Message ------

      
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

      
To: "Paul E. Jones" <paulej@packetizer.com>;
        perc@ietf.org

      
Sent: 3/30/2017 1:54:07 PM

      
Subject: Re: [Perc] Double Encryption and header extensions
        issue

      


      

      

        

          
Hi Paul

            

            Re: RTX/FEC, yeah I know, IMHO the problem has the same root
            cause and solution, but let's keep that discussion on a
            separate thread.

            

            Regarding OHB, as a developer, changing meaning of rtp
            headers depending on the relative position of the OHB feels
            very unfriendly for me, specially if I have later have to
            reconstruct the packet and apply padding to keep boundaries.
            Doesn't seem a clean solution IMHO.

            

            I would really prefer to not touch the header extensions and
            move the OHB to the packet payload, which is were it belongs
            IMHO (same as OSN in normal RTX). That brings another
            question, which I will open on a new email.

            

            Best regards

            Sergio

            

            On 30/03/2017 19:42, Paul E. Jones wrote:

          

          

            
            
Sergio,

            


            

            
For RTX and FEC, I wasn't referring to the header
              extensions, but rather how those are handled in light of
              "double."

            


            

            
What you suggest is certainly possible.  We could have
              the endpoints insert the OHB as the first extension and
              then have all others follow it.  That would make all
              extensions HBH, effectively.

            


            

            
Paul

            


            

            
------ Original Message ------

            
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

            
To: "Paul E. Jones" <paulej@packetizer.com>;
              perc@ietf.org

            
Sent: 3/30/2017 1:02:39 PM

            
Subject: Re: [Perc] Double Encryption and header
              extensions issue

            


            

            

              

                
Maybe I am jumping to the
                  conclusions too fast, but IMHO both RTX/FEC and header
                  extensions should be HBH and not E2E.

                  

                  For header extensions I don't see a feasible way of
                  negotiating the minimum common header extension
                  subsets and getting all clients use the same
                  extensions with same id. Also, I don't see much value
                  in having the rtp header extensions E2E, as except the
                  video orientation one, most of them are meant to be
                  terminated at the MD (except the video orientation
                  which would just need to be copied by the SFU).

                  

                  Also, I don't see any privacy issue doing extensions
                  HBH, as they are transmitted in clear to the MD, and
                  even more, the main purpose of the rfc6904 for
                  encrypted header extensions was to protect the client
                  to mixer/mixer to client audio indications, which by
                  definition are not E2E and required by an SFU to
                  operate.

                  

                  So IMHO, the inner encryption should be done on a
                  "cloned" packet without extensions, and even more, we
                  could use that encoded packet as the media payload of
                  the outer encryption and forget about OHB completely
                  and solve the RTX/FEC issue altogether. After all, it
                  would be just a matter of adding an extra 12 bytes
                  overhead (the full rtp payload header) vs the current
                  OHB header extension, which could get also up to those
                  12 bytes if we need to include ssrc and ts.

                  

                  Best regards

                  Sergio

                  

                  On 30/03/2017 18:31, Paul E. Jones wrote:

                

                

                  
                  
Sergio,

                  


                  

                  
Your interpretation is correct, I think.  When we
                    submitted the original proposal for PERC (that we
                    called "PRIME"), the RTP payload itself was
                    encrypted using an E2E key, but the headers only
                    authenticated with a HBH key.  That draft was this:

                  
                  


                  

                  
This was proposed using a
                    single crypto context with an additional E2E key.
                     Another way to have viewed this (which I think is
                    perhaps easiest to comprehend) is that there were
                    two contexts, one for E2E and one for HBH.  The E2E
                    context would have used, for example, AES-CM with
                    null authentication and the HBH context would have
                    used null encryption and HMAC-SHA1 for
                    authentication.  (Of course, any ciphers or auth
                    functions could have been used.)  This would have
                    allowed the middlebox to change headers as it saw
                    fit, so long as we retained the fields required to
                    re-construct the crypto contexts.  However, the need
                    to maintain SSRC and sequence numbers to reconstruct
                    the crypto context is where a lot of discussion took
                      place that forced some discussion on how we had
                      proposed to do the encryption.

                  


                  

                  
Double addressed the
                    issue of changing certain critical fields, while
                    also moving toward authenticated encryption.  There
                    were concerns with introducing a new RFC with a
                    split in encryption and authentication, so Double
                    addressed those concerns, too.

                  


                  

                  
However, you're right
                    that the negotiated values might present a problem.
                     I've not spent much time thinking about how to
                    solve that.  During this meeting, there were also
                    concerns raised with Double and how it works with
                    RTX and FEC. Obviously, we need to get that right
                    and perhaps those and the RTP header extension
                    concerns you raise should both be topics for
                    discussion in an interim meeting that the chairs
                    will be arranging.

                  


                  

                  
Paul

                  


                  

                  
------ Original Message ------

                  
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

                  
                  
Sent: 3/30/2017 11:16:11 AM

                  
Subject: [Perc] Double Encryption and header
                    extensions issue

                  


                  

                  

                    

                      
Hi all,

                      
I have been reviewing the documentation for
                        double encryption and I have serious doubts
                        about how the header extensions are handled.

                      
If I have understood it (please correct me if I
                        am wrong) the MD must rely all the header
                        extensions present before the OHB to the other
                        peers:

                      
      The Media Distributor MUST NOT delete any header extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



                      This is an obvious requirement, as to be able to
                      decrypt the inner crypto, the end receiver must
                      have the same original rtp packet, which includes
                      header extensions.

                      

                      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.

                      

                      
Is there anything that I missing?

                      

                      Best regards

                      Sergio

                    

                  

                

                


                

              

            

          

          


          

        

      

    

    


    

  


--------------BC881697AF7ED228AFD23ACF--


From nobody Thu Mar 30 15:43: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 E94A012961E for ; Thu, 30 Mar 2017 15:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 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, 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 oxqn_uOjP4yp for ; Thu, 30 Mar 2017 15:43:14 -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 5AFEF12962A for ; Thu, 30 Mar 2017 15:43:14 -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 v2UMhBU2022154 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 18:43:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490913792; bh=nZCQSnCstv1V7FDIrkMuftUEpwPJ23QSJwGvEDodgtg=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=ifiGrOQlIHqr2PT8HcSN0FuIyrfLW9DwzCdvATUX+fHgz38rONY7g9hRgFTo+u/Yf rGo2MYRU79HzSc7T0A/UqtsOzbybMHHre0lCQ7+liempN0B17eOVye5cjQHS3z8ZTO 4h4x/k3XMhUaD/f8qbIqVZ3tr6XYv4ojLpQexvAI=
From: "Paul E. Jones" 
To: "Sergio Garcia Murillo" , perc@ietf.org
Date: Thu, 30 Mar 2017 22:43:13 +0000
Message-Id: 
In-Reply-To: <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com>
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>  <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 18:43:12 -0400 (EDT)
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: Thu, 30 Mar 2017 22:43:17 -0000

Sergio,

Our original proposal was to encrypt the packet using one key and=20
authenticate using a second key.  In theory, that could have been done=20
in a single pass (and we coded it that way).

With PERC, it's now fully two passes of encryption.  The steps at the=20
endpoint are:
1) Form an RTP packet;
2) Call rtp_protect() (or similar function) that applies the double=20
cipher logic;
3) Append the EKT tag; and
4) Send the packet.

I don't see the reason for having a separate PT and I don't view it as=20
tunneling one packet inside another packet.

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

Even if we split the two-pass encryption step fully into two pieces,=20
that's not creating a tunnel or a new media type.  It's just how the=20
crypto transforms are applied.  Devices who receive the media are going=20
to know and understand this, because it will be negotiated in SDP.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" 
To: "Paul E. Jones" ; perc@ietf.org
Sent: 3/30/2017 4:22:45 PM
Subject: Re: [Perc] Double encryption codec/payload type

>For me conceptually you are just tunneling an rtp over rtp, at least=20
>this is how I am implementing it. Let me explain.
>
>For applying the first crypto, you need an rtp packet (my "inner=20
>packet), of the resulting srtp packet, you are creating another rtp=20
>packet ("outher packet) with happens to have same rtp header, copy the=20
>encrypted payload of the encrypted inner packet, encrypt it again and=20
>send it to the MD.
>
>The MD then decrypts the  it, removes the "outher packet", and=20
>creates/encrypts another "outher packet"  with the payload, to send it=20
>to the receiver, but the receiver in order decrypt it, needs to=20
>recreate the original "inner packet", that's why we are sending the the=20
>OHB data.
>
>At the end this is a very similar mechanism to RED/FEC or even RTX, so=20
>that's why I think that it could make sense to use a new codec/payload=20
>to signal it.
>
>The other alternative to signal this on the SDP would be to change the=20
>transport to somthing like UDP/TLS/RTP/TLS/RTP/SAVPF (or whatever) but=20
>I don't think that would be semantically correct, as the inner=20
>encryption can't be terminated at the MD. So in fact, what you are=20
>transporting on the RTP packet is an encrypted payload, whin in SDP=20
>semantics requires a codec and a payload.
>
>What is your view about this?
>
>Best regards
>Sergio
>
>
>
>On 30/03/2017 22:03, Paul E. Jones wrote:
>>Sergio,
>>
>>I don't fully understand your question, since we did not define an=20
>>"inner packet".  There are two encryption passes over the packet using=20
>>two different keys, so I guess you're referring to the first=20
>>encryption pass.
>>
>>We do not change the PT when we apply SRTP, so applying "double"=20
>>should not result in a new PT, either.  It's just a new "transform".
>>
>>So, I'm not sure what you mean here.
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Sergio Garcia Murillo" 
>>To: perc@ietf.org
>>Sent: 3/30/2017 2:01:06 PM
>>Subject: [Perc] Double encryption codec/payload type
>>
>>>Hi all,
>>>
>>>I have another doubt about double encryption, which payload should it=20
>>>use. If I read the specs correctly the original media payload should=20
>>>be used for carrying the inner encrypted packet.
>>>
>>>This doesn't seem very correct to me, as it breaks the semantic of=20
>>>the SDP. How about using an new codec/payload type for carrying that=20
>>>information and use an apt-like semantic for signaling the PT of the=20
>>>inner packet?
>>>
>>>Best regards
>>>
>>>Sergio
>>>
>>>_______________________________________________
>>>Perc mailing list
>>>Perc@ietf.org
>>>https://www.ietf.org/mailman/listinfo/perc
>>
>


From nobody Thu Mar 30 15:54: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 0E32F12949E for ; Thu, 30 Mar 2017 15:54:49 -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 VVOM90fjPDMG for ; Thu, 30 Mar 2017 15:54:46 -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 E874B1279E5 for ; Thu, 30 Mar 2017 15:54:45 -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 v2UMsh94023162 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 18:54:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490914484; bh=X3npAAKtLrR0qsfkDd4XxHnIXqd9duwwxxrUmJqQhsQ=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=WlPq3OWZhizZKX6spJklP4NTgKQ2kpOQXUEz/dl0kedRoxM3ox/FmpylhQm06ItoZ jySZh7w6+8PY8FEWRBSj7gj2beCiKINBtojGsNat0dLrjog9rXqdQPxmfZp8SY9BxK n2/ROmOmbBt4j5F96l/Xy3mvIUBsd0MpZcMQE3bk=
From: "Paul E. Jones" 
To: "Sergio Garcia Murillo" , perc@ietf.org
Date: Thu, 30 Mar 2017 22:54:45 +0000
Message-Id: 
In-Reply-To: 
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>    
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB6BE3CF35-57DB-4C85-85AE-EF3A107E97E2"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 18:54:44 -0400 (EDT)
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: Thu, 30 Mar 2017 22:54:49 -0000

--------=_MB6BE3CF35-57DB-4C85-85AE-EF3A107E97E2
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sergio,

Yeah, all of these are valid points. Likely, none should be E2E=20
extensions, but that would mean that the OHB will always be first in the=20
packet the way things are presently defined, since HBH extensions are=20
added after the OHB.

Perhaps others can suggest when/why we might need E2E RTP header=20
extensions.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" 
To: "Paul E. Jones" ; perc@ietf.org
Sent: 3/30/2017 4:29:08 PM
Subject: Re: [Perc] Double Encryption and header extensions issue

>One thing I realized is that adding OHB in the payload would mean that=20
>it is also sent from the sender to the MD, which would be an=20
>unnecessary overhead.
>
>Regarding encrypted  extensions, I think that the question is even more=20
>basic, can we have e2e extensions? My view is that it is not possible=20
>because extensions and ids are negotiated HBH, not E2E.
>
>If we don't (can't) have E2E extensions, there is no reason at all to=20
>mandate OHB to be at any specific position, and we will not change=20
>current rtp header extensions, making it much more easy to implement it=20
>in current products.
>
>Best regards
>Sergio
>
>On 30/03/2017 22:20, Paul E. Jones wrote:
>>Sergio,
>>
>>Moving the OHB to the payload is doable, but perhaps a better solution=20
>>is simply have the endpoint always insert the OHB as the first header=20
>>extension.  We could also pre-populate that with every single value=20
>>that we might ever want to change (i.e., allow it to be a fixed size).=20
>>  Having a fixed-size was suggested yesterday in the meeting.  It would=
=20
>>mean, though, that the header extensions are not E2E authenticated or=20
>>encrypted.  I don't know how important that might be to anyone.
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Sergio Garcia Murillo" 
>>To: "Paul E. Jones" ; perc@ietf.org
>>Sent: 3/30/2017 1:54:07 PM
>>Subject: Re: [Perc] Double Encryption and header extensions issue
>>
>>>Hi Paul
>>>
>>>Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause=20
>>>and solution, but let's keep that discussion on a separate thread.
>>>
>>>Regarding OHB, as a developer, changing meaning of rtp headers=20
>>>depending on the relative position of the OHB feels very unfriendly=20
>>>for me, specially if I have later have to reconstruct the packet and=20
>>>apply padding to keep boundaries. Doesn't seem a clean solution IMHO.
>>>
>>>I would really prefer to not touch the header extensions and move the=20
>>>OHB to the packet payload, which is were it belongs IMHO (same as OSN=20
>>>in normal RTX). That brings another question, which I will open on a=20
>>>new email.
>>>
>>>Best regards
>>>Sergio
>>>
>>>On 30/03/2017 19:42, Paul E. Jones wrote:
>>>>Sergio,
>>>>
>>>>For RTX and FEC, I wasn't referring to the header extensions, but=20
>>>>rather how those are handled in light of "double."
>>>>
>>>>What you suggest is certainly possible.  We could have the endpoints=20
>>>>insert the OHB as the first extension and then have all others=20
>>>>follow it.  That would make all extensions HBH, effectively.
>>>>
>>>>Paul
>>>>
>>>>------ Original Message ------
>>>>From: "Sergio Garcia Murillo" 
>>>>To: "Paul E. Jones" ; perc@ietf.org
>>>>Sent: 3/30/2017 1:02:39 PM
>>>>Subject: Re: [Perc] Double Encryption and header extensions issue
>>>>
>>>>>Maybe I am jumping to the conclusions too fast, but IMHO both=20
>>>>>RTX/FEC and header extensions should be HBH and not E2E.
>>>>>
>>>>>For header extensions I don't see a feasible way of negotiating the=20
>>>>>minimum common header extension subsets and getting all clients use=20
>>>>>the same extensions with same id. Also, I don't see much value in=20
>>>>>having the rtp header extensions E2E, as except the video=20
>>>>>orientation one, most of them are meant to be terminated at the MD=20
>>>>>(except the video orientation which would just need to be copied by=20
>>>>>the SFU).
>>>>>
>>>>>Also, I don't see any privacy issue doing extensions HBH, as they=20
>>>>>are transmitted in clear to the MD, and even more, the main purpose=20
>>>>>of the rfc6904 for encrypted header extensions was to protect the=20
>>>>>client to mixer/mixer to client audio indications, which by=20
>>>>>definition are not E2E and required by an SFU to operate.
>>>>>
>>>>>So IMHO, the inner encryption should be done on a "cloned" packet=20
>>>>>without extensions, and even more, we could use that encoded packet=20
>>>>>as the media payload of the outer encryption and forget about OHB=20
>>>>>completely and solve the RTX/FEC issue altogether. After all, it=20
>>>>>would be just a matter of adding an extra 12 bytes overhead (the=20
>>>>>full rtp payload header) vs the current OHB header extension, which=20
>>>>>could get also up to those 12 bytes if we need to include ssrc and=20
>>>>>ts.
>>>>>
>>>>>Best regards
>>>>>Sergio
>>>>>
>>>>>On 30/03/2017 18:31, Paul E. Jones wrote:
>>>>>>Sergio,
>>>>>>
>>>>>>Your interpretation is correct, I think.  When we submitted the=20
>>>>>>original proposal for PERC (that we called "PRIME"), the RTP=20
>>>>>>payload itself was encrypted using an E2E key, but the headers=20
>>>>>>only authenticated with a HBH key.  That draft was this:
>>>>>>https://tools.ietf.org/html/draft-jones-avtcore-private-media-framewo=
rk-00
>>>>>>
>>>>>>This was proposed using a single crypto context with an additional=20
>>>>>>E2E key.  Another way to have viewed this (which I think is=20
>>>>>>perhaps easiest to comprehend) is that there were two contexts,=20
>>>>>>one for E2E and one for HBH.  The E2E context would have used, for=20
>>>>>>example, AES-CM with null authentication and the HBH context would=20
>>>>>>have used null encryption and HMAC-SHA1 for authentication.  (Of=20
>>>>>>course, any ciphers or auth functions could have been used.)  This=20
>>>>>>would have allowed the middlebox to change headers as it saw fit,=20
>>>>>>so long as we retained the fields required to re-construct the=20
>>>>>>crypto contexts.  However, the need to maintain SSRC and sequence=20
>>>>>>numbers to reconstruct the crypto context is where a lot of=20
>>>>>>discussion took place that forced some discussion on how we had=20
>>>>>>proposed to do the encryption.
>>>>>>
>>>>>>Double addressed the issue of changing certain critical fields,=20
>>>>>>while also moving toward authenticated encryption.  There were=20
>>>>>>concerns with introducing a new RFC with a split in encryption and=20
>>>>>>authentication, so Double addressed those concerns, too.
>>>>>>
>>>>>>However, you're right that the negotiated values might present a=20
>>>>>>problem.  I've not spent much time thinking about how to solve=20
>>>>>>that.  During this meeting, there were also concerns raised with=20
>>>>>>Double and how it works with RTX and FEC. Obviously, we need to=20
>>>>>>get that right and perhaps those and the RTP header extension=20
>>>>>>concerns you raise should both be topics for discussion in an=20
>>>>>>interim meeting that the chairs will be arranging.
>>>>>>
>>>>>>Paul
>>>>>>
>>>>>>------ Original Message ------
>>>>>>From: "Sergio Garcia Murillo" 
>>>>>>To: perc@ietf.org
>>>>>>Sent: 3/30/2017 11:16:11 AM
>>>>>>Subject: [Perc] Double Encryption and header extensions issue
>>>>>>
>>>>>>>Hi all,
>>>>>>>
>>>>>>>I have been reviewing the documentation for double encryption and=20
>>>>>>>I have serious doubts about how the header extensions are=20
>>>>>>>handled.
>>>>>>>
>>>>>>>If I have understood it (please correct me if I am wrong) the MD=20
>>>>>>>must rely all the header extensions present before the OHB to the=20
>>>>>>>other peers:
>>>>>>>
>>>>>>>The Media Distributor MUST NOT delete any header extensions=20
>>>>>>>before the OHB, but MAY add, delete, or modify any that follow=20
>>>>>>>the OHB. This is an obvious requirement, as to be able to decrypt=20
>>>>>>>the inner crypto, the end receiver must have the same original=20
>>>>>>>rtp packet, which includes header extensions.
>>>>>>>
>>>>>>>My concerns is that there are scenarios in which this is not=20
>>>>>>>possible:
>>>>>>>Sender and receiver may not support same set of header=20
>>>>>>>extensionsSender and receiver may have negotiated a different id=20
>>>>>>>for same header extension
>>>>>>>In any of the previous scenarios, the receiver will not be able=20
>>>>>>>to parse the packet correctly, and at best case scenario, it will=20
>>>>>>>ignore the header extension.
>>>>>>>
>>>>>>>Is there anything that I missing?
>>>>>>>
>>>>>>>Best regards
>>>>>>>Sergio
>>>>>
>>>>>
>>>
>>>
>
>
--------=_MB6BE3CF35-57DB-4C85-85AE-EF3A107E97E2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


   =20
  
  
Sergio,

Yeah, all of these are vali=
d points. Likely, none should be E2E extensions, but that would mean that t=
he OHB will always be first in the packet the way things are presently defi=
ned, since HBH extensions are added after the OHB.

Perhaps others can s=
uggest when/why we might need E2E RTP header extensions.

Paul



------ Original Message ------


From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>


To: "Paul E. Jones" <paule=
j@packetizer.com>; perc@ietf.org


Sent: 3/30/2017 4:29:08 PM


Subject: Re: [Perc] Double Encryption and header extensions issue





    
One thing I realized is that adding OHB
      in the payload would mean that it is also sent from the sender to
      the MD, which would be an unnecessary overhead.

      

      Regarding encrypted=C2=A0 extensions, I think that the question is ev=
en
      more basic, can we have e2e extensions? My view is that it is not
      possible because extensions and ids are negotiated HBH, not E2E.

      

      If we don't (can't) have E2E extensions, there is no reason at all
      to mandate OHB to be at any specific position, and we will not
      change current rtp header extensions, making it much more easy to
      implement it in current products.

      

      Best regards

      Sergio

      

      On 30/03/2017 22:20, Paul E. Jones wrote:

    

    

      
Sergio,

      


      

      
Moving the OHB to the payload is doable, but perhaps a better
        solution is simply have the endpoint always insert the OHB as
        the first header extension. =C2=A0We could also pre-populate that
        with every single value that we might ever want to change (i.e.,
        allow it to be a fixed size). =C2=A0Having a fixed-size was suggest=
ed
        yesterday in the meeting. =C2=A0It would mean, though, that the
        header extensions are not E2E authenticated or encrypted. =C2=A0I
        don't know how important that might be to anyone.

      


      

      
Paul

      


      

      
------ Original Message ------

      
      
To: "Paul E. Jones" <paulej@packetizer.com>;
        perc@ietf=
.org

      
Sent: 3/30/2017 1:54:07 PM

      
Subject: Re: [Perc] Double Encryption and header extensions
        issue

      


      

      

        

          
Hi Paul

            

            Re: RTX/FEC, yeah I know, IMHO the problem has the same root
            cause and solution, but let's keep that discussion on a
            separate thread.

            

            Regarding OHB, as a developer, changing meaning of rtp
            headers depending on the relative position of the OHB feels
            very unfriendly for me, specially if I have later have to
            reconstruct the packet and apply padding to keep boundaries.
            Doesn't seem a clean solution IMHO.

            

            I would really prefer to not touch the header extensions and
            move the OHB to the packet payload, which is were it belongs
            IMHO (same as OSN in normal RTX). That brings another
            question, which I will open on a new email.

            

            Best regards

            Sergio

            

            On 30/03/2017 19:42, Paul E. Jones wrote:

          

          

            
            
Sergio,

            


            

            
For RTX and FEC, I wasn't referring to the header
              extensions, but rather how those are handled in light of
              "double."

            


            

            
What you suggest is certainly possible. =C2=A0We could hav=
e
              the endpoints insert the OHB as the first extension and
              then have all others follow it. =C2=A0That would make all
              extensions HBH, effectively.

            


            

            
Paul

            


            

            
------ Original Message ------

            
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@g=
mail.com>

            
To: "Paul E. Jones" <paulej@packetizer.com>;
              per=
c@ietf.org

            
Sent: 3/30/2017 1:02:39 PM

            
Subject: Re: [Perc] Double Encryption and header
              extensions issue

            


            

            

              

                
Maybe I am jumping to the
                  conclusions too fast, but IMHO both RTX/FEC and header
                  extensions should be HBH and not E2E.

                  

                  For header extensions I don't see a feasible way of
                  negotiating the minimum common header extension
                  subsets and getting all clients use the same
                  extensions with same id. Also, I don't see much value
                  in having the rtp header extensions E2E, as except the
                  video orientation one, most of them are meant to be
                  terminated at the MD (except the video orientation
                  which would just need to be copied by the SFU).

                  

                  Also, I don't see any privacy issue doing extensions
                  HBH, as they are transmitted in clear to the MD, and
                  even more, the main purpose of the rfc6904 for
                  encrypted header extensions was to protect the client
                  to mixer/mixer to client audio indications, which by
                  definition are not E2E and required by an SFU to
                  operate.

                  

                  So IMHO, the inner encryption should be done on a
                  "cloned" packet without extensions, and even more, we
                  could use that encoded packet as the media payload of
                  the outer encryption and forget about OHB completely
                  and solve the RTX/FEC issue altogether. After all, it
                  would be just a matter of adding an extra 12 bytes
                  overhead (the full rtp payload header) vs the current
                  OHB header extension, which could get also up to those
                  12 bytes if we need to include ssrc and ts.

                  

                  Best regards

                  Sergio

                  

                  On 30/03/2017 18:31, Paul E. Jones wrote:

                

                

                  
                  
Sergio,

                  


                  

                  
Your interpretation is correct, I think. =C2=A0When=
 we
                    submitted the original proposal for PERC (that we
                    called "PRIME"), the RTP payload itself was
                    encrypted using an E2E key, but the headers only
                    authenticated with a HBH key. =C2=A0That draft was this=
:

                  
                  


                  

                  
This was proposed using a
                    single crypto context with an additional E2E key.
                    =C2=A0Another way to have viewed this (which I think is
                    perhaps easiest to comprehend) is that there were
                    two contexts, one for E2E and one for HBH. =C2=A0The E2=
E
                    context would have used, for example, AES-CM with
                    null authentication and the HBH context would have
                    used null encryption and HMAC-SHA1 for
                    authentication. =C2=A0(Of course, any ciphers or auth
                    functions could have been used.) =C2=A0This would have
                    allowed the middlebox to change headers as it saw
                    fit, so long as we retained the fields required to
                    re-construct the crypto contexts. =C2=A0However, the ne=
ed
                    to maintain SSRC and sequence numbers to reconstruct
                    the crypto context is where=C2=A0a lot of discussi=
on took
                      place that forced some discussion on how we had
                      proposed to do the encryption.

                  


                  

                  
Double addressed the
                    issue of changing certain critical fields, while
                    also moving toward authenticated encryption. =C2=A0Ther=
e
                    were concerns with introducing a new RFC with a
                    split in encryption and authentication, so Double
                    addressed those concerns, too.

                  


                  

                  
However, you're right
                    that the negotiated values might present a problem.
                    =C2=A0I've not spent much time thinking about how to
                    solve that. =C2=A0During this meeting, there were also
                    concerns raised with Double and how it works with
                    RTX and FEC. Obviously, we need to get that right
                    and perhaps those and the RTP header extension
                    concerns you raise should both be topics for
                    discussion in an interim meeting that the chairs
                    will be arranging.

                  


                  

                  
Paul

                  


                  

                  
------ Original Message ------

                  
From: "Sergio Garcia Murillo" <sergio.garcia.mur=
illo@gmail.com>

                  
                  
Sent: 3/30/2017 11:16:11 AM

                  
Subject: [Perc] Double Encryption and header
                    extensions issue

                  


                  

                  

                    

                      
Hi all,

                      
I have been reviewing the documentation for
                        double encryption and I have serious doubts
                        about how the header extensions are handled.

                      
If I have understood it (please correct me if I
                        am wrong) the MD must rely all the header
                        extensions present before the OHB to the other
                        peers:

                      
      The Media Distributor MUST NOT delete any h=
eader extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



                      This is an obvious requirement, as to be able to
                      decrypt the inner crypto, the end receiver must
                      have the same original rtp packet, which includes
                      header extensions.

                      

                      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.

                      

                      
Is there anything that I missing?

                      

                      Best regards

                      Sergio

                    

                  

                

                


                

              

            

          

          


          

        

      

    

    


    

  




--------=_MB6BE3CF35-57DB-4C85-85AE-EF3A107E97E2--


From nobody Thu Mar 30 15:57: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 46E771279E5 for ; Thu, 30 Mar 2017 15:57:07 -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 r5SWyslTnmtq for ; Thu, 30 Mar 2017 15:57:05 -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 077C21294AE for ; Thu, 30 Mar 2017 15:57:05 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id w43so81102132wrb.0 for ; Thu, 30 Mar 2017 15:57:04 -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=dboh+Jh4OoLTCl/Kgpn+vwyobJy2GjbWcpmNYhYGdpc=; b=cqzzqX7I7cDv4GYOsHEtA+E5qoAljDRBt8Sn3kINNpHmfg3SIwzP92uGCrYBj2xSSj MX9yCXJS/Ejbd8ImN3+TnpH92tE/4TGdIKTUZG5tCl8Z7un0vQElM7IfPJnwyme5H55E LF8YC5d27fxkBVdtRqXMysZ+MVsL9pN9jPwov7rYqT24659cQZgQ165gSQgyxrAslx6/ 78rNED5ZL7xTSY9McGCx70CtO0zvvTrYLWJhuZ40PHGkcVZzpv9P5icky/Kj0wynM7nb EGbcK1x26Foi1p2S+bEbtVLA5y9FJstIx5uGqjEgvkn6KrnWfl/kqV8pkwPLgIsO/7M1 53HA==
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=dboh+Jh4OoLTCl/Kgpn+vwyobJy2GjbWcpmNYhYGdpc=; b=PsOk1/IniShUtLZBgT68aD4f9nd5R6CuQqG/i7h8M7U8SgRqMrpyEvxnr99ZvWj49X TVSBuEXOY3WPfrvneRgYUtb5AdQCkgkl894MWb/ROYODFXNBoo5qFzM++6d1fc7yCmQM BM+EMnZF8X/nl09lEbJPd2iJorUmn0vjfElMLEaktVDvYXqTTzqb26AxGDzpf3QeBpVO Ond1OjGrs8wwdLKZ+eBTRTsh12SQizK1K8lJuoNGNNa7jiohwKBnkRhyxA1eNre+74hE j8CldsBGsFgKVvD2V/rmaadCaSKYM7kfefNUJMboZJSzwnVw0ebHX1EOH8qSgqg1SklP 9XLQ==
X-Gm-Message-State: AFeK/H3hj0uBPVA7pw9U9LIcbbtz94uQYBO19ncJzMXdv+kn9MlMzY2xVD3owN12Gn43xQ==
X-Received: by 10.28.208.7 with SMTP id h7mr410130wmg.79.1490914623164; Thu, 30 Mar 2017 15:57:03 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id m186sm561785wmd.21.2017.03.30.15.57.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 15:57:01 -0700 (PDT)
To: "Paul E. Jones" , perc@ietf.org
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>  <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: 
Date: Fri, 31 Mar 2017 00:57:04 +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 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: Thu, 30 Mar 2017 22:57:07 -0000

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

Best regards
Sergio


From nobody Thu Mar 30 16:07: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 333C61250B8 for ; Thu, 30 Mar 2017 16:07:53 -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 tTwN6_LahOcz for ; Thu, 30 Mar 2017 16:07:51 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 389FA129434 for ; Thu, 30 Mar 2017 16:07:51 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id w43so81358139wrb.0 for ; Thu, 30 Mar 2017 16:07:51 -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=0umJ7KPlGjZKEKo6XVwW55e8MyAkD58w8AuBYPu0Jx8=; b=Bzr0DfyCMVl+hcG7/v4e98d2R0riR/Zl+9EJOdAltLGW0yzGwW01sBkG3/0LQV1P3+ /qtjs8N5wZ+MYUiCzBOKnzm9Qa6lbQQS0j3M0/c5QCut077iWXIWsTPwmZ6fDe4buHg8 paCoueg3SihPDzisi77ECifUsJ1OCGS2LCU576FQM10KryDAWUIUxI+pMsLbrEri0HX/ IhKWZrjD6h84qcfDg2BPJe8SFfMtFVhcQW1/+x1i7Joc5AlaE5Xfx9gMMdpdy7cp4J9d ZHWRjmE1Z24sGtccA4NZHAAGoUKnDW9/FfWIZmKThDsBqSUGDQWVA+muYplwB1JKchGV 9FoA==
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=0umJ7KPlGjZKEKo6XVwW55e8MyAkD58w8AuBYPu0Jx8=; b=aV2fy5dEpFL6g/GsdfHNeccCusIpaRVbm/DJCgMUGSowBU5kRE4a9/BAOweNN4w7qE vwLFIVgCDxzYwEB/kaRjWeLAO+kl1zC3YVTOqoNapPnsvUNlT5jYov8xWmsraHYeZXNb y1nhOGOV/Ynmmu4SBApF45PCd0ljjJe8m/TPVuW+1Z71aHTZfMcUmgzVlzWAW0nnjnpw Hjq+1AVPYHENxuZHcZTMVoiCBB1dk31bnIdVgEa8MhOsA7fTLdK6U7IuQ1JcpTHdjNDY PK5QvYZn3h43BPSdswzgRgf2LcjiJz1OIRZok7sSiaubrLDjBR7YI48fAd4eH9BLqY7j wtjw==
X-Gm-Message-State: AFeK/H0emJK020dPQGLazx6xPRK0coKXyHOF01R8/7KP2S45tIGD0ysJydJR9mT4si4gkw==
X-Received: by 10.28.54.76 with SMTP id d73mr462619wma.114.1490915269478; Thu, 30 Mar 2017 16:07:49 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id l132sm600329wmd.10.2017.03.30.16.07.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:07:48 -0700 (PDT)
To: "Paul E. Jones" , perc@ietf.org
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>  <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com>
Date: Fri, 31 Mar 2017 01:07:50 +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: [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: Thu, 30 Mar 2017 23:07:53 -0000

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



From nobody Thu Mar 30 16:10: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 574BA129622 for ; Thu, 30 Mar 2017 16:10:05 -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 j8O50I8crUtZ for ; Thu, 30 Mar 2017 16:10:01 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 3F3261295A0 for ; Thu, 30 Mar 2017 16:10:01 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id y18so3439134itc.0 for ; Thu, 30 Mar 2017 16:10: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=q6zksnK3ecXVTUTvpqklcdRI0MxtRGTzE76Qa3lfbUw=; b=ArOlyNzK98069RjS95j71FWh6FlmraMh079ApMd1/Oy6n1Vkcyk2Zyo0vYO5cG9nYy KCUIEk/oG+Ak7qZPyqKXI+LgmOUqDPBAi1fOMh97hDTVrWKWqTgAgxlbJBIjt1acCtSY xE8FDIPBYuEscc3lf40RebEcFh23ptY605xNE=
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=q6zksnK3ecXVTUTvpqklcdRI0MxtRGTzE76Qa3lfbUw=; b=CpktGayknqAuY9W7kkFfhr5p5iX+O5NU03H92R0gV7BHdOWT5OH0ghEvnOReAV01/r F1zbXN2BpjYKO1NMK17bcvB4B5HFv7uHw741wsHtKDA9jc7LcNrdNJGkarrwSO2e4Yj+ v1M56TRYhyxZyj2zbfl0e16pPChmtzztRI3UwvWmcMYcK2n2yccOk7N/UHZQVSlQMILT nFO3OMOmEyjumju+whDTX32CzwkJUf42OXw6psTExpXUgVfwYDyMInaSs2ulYOF1nuzt X7jkUY52ksd8BqhKNgAOQxj70YcPdsp6GWEgdj+4oHYWqWPA3BjwesqCrOGtlnPCqeT9 BZ1w==
X-Gm-Message-State: AFeK/H2fgdSOPCduUQTMaqlW+PittosiaAJVeKFQ67oiCL5gV+fCsSgGlYWJcTNPrFxdXi73
X-Received: by 10.36.52.200 with SMTP id z191mr831084itz.122.1490915400542; Thu, 30 Mar 2017 16:10:00 -0700 (PDT)
Received: from t2001067c037001284d9bb16459b4364c.v6.meeting.ietf.org (t2001067c037001284d9bb16459b4364c.v6.meeting.ietf.org. [2001:67c:370:128:4d9b:b164:59b4:364c]) by smtp.gmail.com with ESMTPSA id p140sm307398itc.27.2017.03.30.16.09.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:09:59 -0700 (PDT)
From: Nils Ohlmeier 
Message-Id: <262EFF2C-767F-46F8-B952-9D80579DD450@mozilla.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_83533955-79C3-4F03-94C5-8E6BE1E14BF0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 30 Mar 2017 18:09:56 -0500
In-Reply-To: 
Cc: Sergio Garcia Murillo , perc@ietf.org
To: "Paul E. Jones" 
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>     
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: Thu, 30 Mar 2017 23:10:05 -0000

--Apple-Mail=_83533955-79C3-4F03-94C5-8E6BE1E14BF0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5EEC6E34-3261-4690-9296-C06A88BB6DC0"


--Apple-Mail=_5EEC6E34-3261-4690-9296-C06A88BB6DC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

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.

Best
  Nils

> On Mar 30, 2017, at 17:54, Paul E. Jones  =
wrote:
>=20
> Sergio,
>=20
> Yeah, all of these are valid points. Likely, none should be E2E =
extensions, but that would mean that the OHB will always be first in the =
packet the way things are presently defined, since HBH extensions are =
added after the OHB.
>=20
> Perhaps others can suggest when/why we might need E2E RTP header =
extensions.
>=20
> Paul
>=20
> ------ Original Message ------
> From: "Sergio Garcia Murillo" >
> To: "Paul E. Jones" >; perc@ietf.org 
> Sent: 3/30/2017 4:29:08 PM
> Subject: Re: [Perc] Double Encryption and header extensions issue
>=20
>> One thing I realized is that adding OHB in the payload would mean =
that it is also sent from the sender to the MD, which would be an =
unnecessary overhead.
>>=20
>> Regarding encrypted  extensions, I think that the question is even =
more basic, can we have e2e extensions? My view is that it is not =
possible because extensions and ids are negotiated HBH, not E2E.
>>=20
>> If we don't (can't) have E2E extensions, there is no reason at all to =
mandate OHB to be at any specific position, and we will not change =
current rtp header extensions, making it much more easy to implement it =
in current products.
>>=20
>> Best regards
>> Sergio
>>=20
>> On 30/03/2017 22:20, Paul E. Jones wrote:
>>> Sergio,
>>>=20
>>> Moving the OHB to the payload is doable, but perhaps a better =
solution is simply have the endpoint always insert the OHB as the first =
header extension.  We could also pre-populate that with every single =
value that we might ever want to change (i.e., allow it to be a fixed =
size).  Having a fixed-size was suggested yesterday in the meeting.  It =
would mean, though, that the header extensions are not E2E authenticated =
or encrypted.  I don't know how important that might be to anyone.
>>>=20
>>> Paul
>>>=20
>>> ------ Original Message ------
>>> From: "Sergio Garcia Murillo" >
>>> To: "Paul E. Jones" >; perc@ietf.org 
>>> Sent: 3/30/2017 1:54:07 PM
>>> Subject: Re: [Perc] Double Encryption and header extensions issue
>>>=20
>>>> Hi Paul
>>>>=20
>>>> Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause =
and solution, but let's keep that discussion on a separate thread.
>>>>=20
>>>> Regarding OHB, as a developer, changing meaning of rtp headers =
depending on the relative position of the OHB feels very unfriendly for =
me, specially if I have later have to reconstruct the packet and apply =
padding to keep boundaries. Doesn't seem a clean solution IMHO.
>>>>=20
>>>> I would really prefer to not touch the header extensions and move =
the OHB to the packet payload, which is were it belongs IMHO (same as =
OSN in normal RTX). That brings another question, which I will open on a =
new email.
>>>>=20
>>>> Best regards
>>>> Sergio
>>>>=20
>>>> On 30/03/2017 19:42, Paul E. Jones wrote:
>>>>> Sergio,
>>>>>=20
>>>>> For RTX and FEC, I wasn't referring to the header extensions, but =
rather how those are handled in light of "double."
>>>>>=20
>>>>> What you suggest is certainly possible.  We could have the =
endpoints insert the OHB as the first extension and then have all others =
follow it.  That would make all extensions HBH, effectively.
>>>>>=20
>>>>> Paul
>>>>>=20
>>>>> ------ Original Message ------
>>>>> From: "Sergio Garcia Murillo" >
>>>>> To: "Paul E. Jones" >; perc@ietf.org 
>>>>> Sent: 3/30/2017 1:02:39 PM
>>>>> Subject: Re: [Perc] Double Encryption and header extensions issue
>>>>>=20
>>>>>> Maybe I am jumping to the conclusions too fast, but IMHO both =
RTX/FEC and header extensions should be HBH and not E2E.
>>>>>>=20
>>>>>> For header extensions I don't see a feasible way of negotiating =
the minimum common header extension subsets and getting all clients use =
the same extensions with same id. Also, I don't see much value in having =
the rtp header extensions E2E, as except the video orientation one, most =
of them are meant to be terminated at the MD (except the video =
orientation which would just need to be copied by the SFU).
>>>>>>=20
>>>>>> Also, I don't see any privacy issue doing extensions HBH, as they =
are transmitted in clear to the MD, and even more, the main purpose of =
the rfc6904 for encrypted header extensions was to protect the client to =
mixer/mixer to client audio indications, which by definition are not E2E =
and required by an SFU to operate.
>>>>>>=20
>>>>>> So IMHO, the inner encryption should be done on a "cloned" packet =
without extensions, and even more, we could use that encoded packet as =
the media payload of the outer encryption and forget about OHB =
completely and solve the RTX/FEC issue altogether. After all, it would =
be just a matter of adding an extra 12 bytes overhead (the full rtp =
payload header) vs the current OHB header extension, which could get =
also up to those 12 bytes if we need to include ssrc and ts.
>>>>>>=20
>>>>>> Best regards
>>>>>> Sergio
>>>>>>=20
>>>>>> On 30/03/2017 18:31, Paul E. Jones wrote:
>>>>>>> Sergio,
>>>>>>>=20
>>>>>>> Your interpretation is correct, I think.  When we submitted the =
original proposal for PERC (that we called "PRIME"), the RTP payload =
itself was encrypted using an E2E key, but the headers only =
authenticated with a HBH key.  That draft was this:
>>>>>>> =
https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00=
 =

>>>>>>>=20
>>>>>>> This was proposed using a single crypto context with an =
additional E2E key.  Another way to have viewed this (which I think is =
perhaps easiest to comprehend) is that there were two contexts, one for =
E2E and one for HBH.  The E2E context would have used, for example, =
AES-CM with null authentication and the HBH context would have used null =
encryption and HMAC-SHA1 for authentication.  (Of course, any ciphers or =
auth functions could have been used.)  This would have allowed the =
middlebox to change headers as it saw fit, so long as we retained the =
fields required to re-construct the crypto contexts.  However, the need =
to maintain SSRC and sequence numbers to reconstruct the crypto context =
is where a lot of discussion took place that forced some discussion on =
how we had proposed to do the encryption.
>>>>>>>=20
>>>>>>> Double addressed the issue of changing certain critical fields, =
while also moving toward authenticated encryption.  There were concerns =
with introducing a new RFC with a split in encryption and =
authentication, so Double addressed those concerns, too.
>>>>>>>=20
>>>>>>> However, you're right that the negotiated values might present a =
problem.  I've not spent much time thinking about how to solve that.  =
During this meeting, there were also concerns raised with Double and how =
it works with RTX and FEC. Obviously, we need to get that right and =
perhaps those and the RTP header extension concerns you raise should =
both be topics for discussion in an interim meeting that the chairs will =
be arranging.
>>>>>>>=20
>>>>>>> Paul
>>>>>>>=20
>>>>>>> ------ Original Message ------
>>>>>>> From: "Sergio Garcia Murillo" >
>>>>>>> To: perc@ietf.org 
>>>>>>> Sent: 3/30/2017 11:16:11 AM
>>>>>>> Subject: [Perc] Double Encryption and header extensions issue
>>>>>>>=20
>>>>>>>> Hi all,
>>>>>>>>=20
>>>>>>>> I have been reviewing the documentation for double encryption =
and I have serious doubts about how the header extensions are handled.
>>>>>>>>=20
>>>>>>>> If I have understood it (please correct me if I am wrong) the =
MD must rely all the header extensions present before the OHB to the =
other peers:
>>>>>>>>=20
>>>>>>>>       The Media Distributor MUST NOT delete any header =
extensions before
>>>>>>>>       the OHB, but MAY add, delete, or modify any that follow =
the OHB.
>>>>>>>>=20
>>>>>>>> This is an obvious requirement, as to be able to decrypt the =
inner crypto, the end receiver must have the same original rtp packet, =
which includes header extensions.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> Is there anything that I missing?
>>>>>>>>=20
>>>>>>>> Best regards
>>>>>>>> Sergio
>>>>>>=20
>>>>=20
>>=20
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc


--Apple-Mail=_5EEC6E34-3261-4690-9296-C06A88BB6DC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi,

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.

Best
  Nils

On =
Mar 30, 2017, at 17:54, Paul E. Jones <paulej@packetizer.com> wrote:

Sergio,

Yeah, all of these are valid points. Likely, none =
should be E2E extensions, but that would mean that the OHB will always =
be first in the packet the way things are presently defined, since HBH =
extensions are added after the OHB.

Perhaps others can suggest when/why we might =
need E2E RTP header extensions.

Paul

------ Original Message ------
From: =
"Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
To: "Paul =
E. Jones" <paulej@packetizer.com>; perc@ietf.org
Sent: =
3/30/2017 4:29:08 PM
Subject: Re: [Perc] Double Encryption and header extensions =
issue

One =
thing I realized is that adding OHB in the payload would mean that it is =
also sent from the sender to the MD, which would be an unnecessary =
overhead.

Regarding encrypted  =
extensions, I think that the question is even more basic, can we have =
e2e extensions? My view is that it is not possible because extensions =
and ids are negotiated HBH, not E2E.

If we =
don't (can't) have E2E extensions, there is no reason at all to mandate =
OHB to be at any specific position, and we will not change current rtp =
header extensions, making it much more easy to implement it in current =
products.

Best regards
Sergio

On 30/03/2017 22:20, Paul =
E. Jones wrote:
Sergio,

Moving the OHB to the payload is doable, but perhaps a better =
solution is simply have the endpoint always insert the OHB as the first =
header extension.  We could also pre-populate that with every =
single value that we might ever want to change (i.e., allow it to be a =
fixed size).  Having a fixed-size was suggested yesterday in the =
meeting.  It would mean, though, that the header extensions are not =
E2E authenticated or encrypted.  I don't know how important that =
might be to anyone.

Paul

------ Original Message ------
From: =
"Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>; perc@ietf.org
Sent: 3/30/2017 1:54:07 PM
Subject: Re: =
[Perc] Double Encryption and header extensions issue

Hi =
Paul

Re: RTX/FEC, yeah I know, IMHO the =
problem has the same root cause and solution, but let's keep that =
discussion on a separate thread.

Regarding =
OHB, as a developer, changing meaning of rtp headers depending on the =
relative position of the OHB feels very unfriendly for me, specially if =
I have later have to reconstruct the packet and apply padding to keep =
boundaries. Doesn't seem a clean solution IMHO.

I would really prefer to not touch the header extensions and =
move the OHB to the packet payload, which is were it belongs IMHO (same =
as OSN in normal RTX). That brings another question, which I will open =
on a new email.

Best regards
Sergio

On 30/03/2017 19:42, Paul =
E. Jones wrote:
Sergio,

For RTX and FEC, I wasn't referring to the header extensions, =
but rather how those are handled in light of "double."

What you suggest is =
certainly possible.  We could have the endpoints insert the OHB as =
the first extension and then have all others follow it.  That would =
make all extensions HBH, effectively.

Paul

------ Original Message =
------
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>; perc@ietf.org
Sent: 3/30/2017 1:02:39 PM
Subject: Re: =
[Perc] Double Encryption and header extensions issue

Maybe =
I am jumping to the conclusions too fast, but IMHO both RTX/FEC and =
header extensions should be HBH and not E2E.

For header extensions I don't see a feasible way of =
negotiating the minimum common header extension subsets and getting all =
clients use the same extensions with same id. Also, I don't see much =
value in having the rtp header extensions E2E, as except the video =
orientation one, most of them are meant to be terminated at the MD =
(except the video orientation which would just need to be copied by the =
SFU).

Also, I don't see any privacy issue =
doing extensions HBH, as they are transmitted in clear to the MD, and =
even more, the main purpose of the rfc6904 for encrypted header =
extensions was to protect the client to mixer/mixer to client audio =
indications, which by definition are not E2E and required by an SFU to =
operate.

So IMHO, the inner encryption =
should be done on a "cloned" packet without extensions, and even more, =
we could use that encoded packet as the media payload of the outer =
encryption and forget about OHB completely and solve the RTX/FEC issue =
altogether. After all, it would be just a matter of adding an extra 12 =
bytes overhead (the full rtp payload header) vs the current OHB header =
extension, which could get also up to those 12 bytes if we need to =
include ssrc and ts.

Best regards
Sergio

On 30/03/2017 18:31, Paul =
E. Jones wrote:
Sergio,

Your interpretation is correct, I think.  When we =
submitted the original proposal for PERC (that we called "PRIME"), the =
RTP payload itself was encrypted using an E2E key, but the headers only =
authenticated with a HBH key.  That draft was this:
https://tools.ietf.org/html/draft-jones-avtcore-private-media-f=
ramework-00

This was proposed using a single =
crypto context with an additional E2E key.  Another way to have =
viewed this (which I think is perhaps easiest to comprehend) is that =
there were two contexts, one for E2E and one for HBH.  The E2E =
context would have used, for example, AES-CM with null authentication =
and the HBH context would have used null encryption and HMAC-SHA1 for =
authentication.  (Of course, any ciphers or auth functions could =
have been used.)  This would have allowed the middlebox to change =
headers as it saw fit, so long as we retained the fields required to =
re-construct the crypto contexts.  However, the need to maintain =
SSRC and sequence numbers to reconstruct the crypto context is =
where a =
lot of discussion took place that forced some discussion on how we had =
proposed to do the encryption.

Double addressed the issue of changing certain critical =
fields, while also moving toward authenticated encryption.  There =
were concerns with introducing a new RFC with a split in encryption and =
authentication, so Double addressed those concerns, too.

However, you're right that the =
negotiated values might present a problem.  I've not spent much =
time thinking about how to solve that.  During this meeting, there =
were also concerns raised with Double and how it works with RTX and FEC. =
Obviously, we need to get that right and perhaps those and the RTP =
header extension concerns you raise should both be topics for discussion =
in an interim meeting that the chairs will be arranging.

Paul

------ Original Message =
------
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>
To: perc@ietf.org
Sent: 3/30/2017 =
11:16:11 AM
Subject: [Perc] Double Encryption and =
header extensions issue

Hi all,
I have been reviewing the documentation for double encryption =
and I have serious doubts about how the header extensions are =
handled.
If I have understood it (please correct me if =
I am wrong) the MD must rely all the header extensions present before =
the OHB to the other peers:
      The Media =
Distributor MUST NOT delete any header extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.


This is an obvious requirement, as to be able to decrypt the inner =
crypto, the end receiver must have the same original rtp packet, which =
includes header extensions.

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.
Is there =
anything that I missing?
Best regards
Sergio



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

=

--Apple-Mail=_5EEC6E34-3261-4690-9296-C06A88BB6DC0--

--Apple-Mail=_83533955-79C3-4F03-94C5-8E6BE1E14BF0
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-----

iQIcBAEBCgAGBQJY3ZBFAAoJEJ3NnGfOORkky1QP/1Zr0XEuOCq0xVy8tLLiBluR
L7nTcvEUj1DAgmMRQxnRu7f5FrIvkVCdShey+VsWYYpQ3JHHcpnvtXz6FWTXwkHa
AV51/AICIrWHX1mc3HRRwxggGskgn5tXwiBsN97K89dj2dIlc8MwIG0jmBhqVw9e
tujWOKffEidhS7L6ErFzlyD+OboZskUThlBjOTDxHtvVdx4GB32iMbHJOjFUVQYX
gi9LH1MMIbxqOiFnHk1HH3BegTfOi7B8s/2KLnGHhKNNMVH9tF9CbfgjnTVbP9Vt
apPFOlSlFxkDkLR0ZZcQ+9nOjBuJfpj9iHGBfm+6eIarjkzCw2LvfePqj11K2mZI
weJiC5KvwRsvUNXRoFNg+Af9ZMZGI53n7ht3iLdk8lw76sOzyJbl5qZ5mSiTja9+
ZAGaD9mbok3TUF0cdpdnO59NnreFbzXloUsMoJAUkvqbdL19x1nFg/1HE9/yagv/
XAVi+5lIZnby/DhNK/9K4Dj+wXu014oacc6ySHBGBY3PBQleLCTI8LcGgwTKkivU
PLWp43jM+sQYgmg8dy7ksPSSDb/8bfjzt7IG7Q2RM5UbZBfn35w8/B6JbFQGg3BL
mTs6VFBf69Tedv/o0z6UMV5QW89jxms6hJWtUo489z3ThDPapRqnDo0i3pF2zapR
+YjdqAuIhxb6536vw+a8
=dzSh
-----END PGP SIGNATURE-----

--Apple-Mail=_83533955-79C3-4F03-94C5-8E6BE1E14BF0--


From nobody Thu Mar 30 16:15: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 978921295A0 for ; Thu, 30 Mar 2017 16:15: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 H3Z3MMN7LkMp for ; Thu, 30 Mar 2017 16:15:24 -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 924CA128B38 for ; Thu, 30 Mar 2017 16:15:20 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id l43so83079621wre.1 for ; Thu, 30 Mar 2017 16:15: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=wA/fxU/kS575rpyYoIuL2RiwhlHZbzmANzYfclWdf6s=; b=TY558JW86FHMG+PFjxrPwJTUoIsE22DjFUQgRLytUG+ed8s+bplW8O4FSen6wqn0rG Ygz/Ws6yecN6ek0Yf/QK+DBnSHSMpJg5Fp6xVIRBm9Ne5vlitfdC+8+SptRYpkjJYAp9 fCZk9HQZyRGqkMO8wj7I2cA/jDAMwnVQboH3+kqPJOIeP+ao7Nn1wkn4mYQdeS7GVq+D OhuWhtLHrZm5R448ikQEVIq89cG8FLQcZqNinI34cmOLwWXHHF22mlw6eOi3IWOS2Zwc NGFD6aiUXp5SeLkWSMeTtyjxWKrRvhY/225gimfMf3dRgjlnFRitcViJUAXdnk0VrR0y 0h2A==
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=wA/fxU/kS575rpyYoIuL2RiwhlHZbzmANzYfclWdf6s=; b=H3G/H7XoWHz5gWtnzm4ywBhyP2nqu5zfg2JKkmg83QEdfyMcnK4E+xDhHBqAksi2p5 bdhY1cw1rQ7OrA47NNtGI75y3BUl0Wv/vRcsP+JUURmqQDkRdz1AdzNln8fXM0x/4vBK KL/bVZchGfhg2ss8hGougsbdi6JKbHVov+iMOyUl6lnpg/nKnFuDbyIsTz/uR0bOQ0F+ afdH1zgvJMbLQeP+Tiaa1/e2Y4BkPp0RiuXFHIorLe7UWZ7Xm9eMNBTbsIsugJTYFioF 3XrP5bdh3PaOZ3uhRJOwpjATITBd9CtvaY0KRgQtWl0bFaxkOIVwkzLwQZlqedHmPKA7 gC9A==
X-Gm-Message-State: AFeK/H1ZVmBgf3CdKvbbAT1PHXDlclq5h5PMz3vueoqeWV9ymHQ2wNDP1ED8FphOWlM3GQ==
X-Received: by 10.28.129.212 with SMTP id c203mr37117wmd.19.1490915718873; Thu, 30 Mar 2017 16:15:18 -0700 (PDT)
Received: from [192.168.0.196] ([87.125.122.129]) by smtp.googlemail.com with ESMTPSA id t21sm602866wmd.19.2017.03.30.16.15.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:15:17 -0700 (PDT)
To: Nils Ohlmeier , "Paul E. Jones" 
References: <44c5cb73-cb44-0edc-774f-121f349a0aa7@gmail.com>  <7724f2eb-de56-6544-4e04-d2e3fc3dd98c@gmail.com>      <262EFF2C-767F-46F8-B952-9D80579DD450@mozilla.com>
Cc: perc@ietf.org
From: Sergio Garcia Murillo 
Message-ID: 
Date: Fri, 31 Mar 2017 01:15: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: <262EFF2C-767F-46F8-B952-9D80579DD450@mozilla.com>
Content-Type: multipart/alternative; boundary="------------254E7F27AD129E7EB060BA96"
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: Thu, 30 Mar 2017 23:15:28 -0000

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

I agree

Best regards
Sergio
On 31/03/2017 1:09, Nils Ohlmeier wrote:
> Hi,
>
> 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.
>
> Best
>   Nils
>
>> On Mar 30, 2017, at 17:54, Paul E. Jones > > wrote:
>>
>> Sergio,
>>
>> Yeah, all of these are valid points. Likely, none should be E2E 
>> extensions, but that would mean that the OHB will always be first in 
>> the packet the way things are presently defined, since HBH extensions 
>> are added after the OHB.
>>
>> Perhaps others can suggest when/why we might need E2E RTP header 
>> extensions.
>>
>> Paul
>>
>> ------ Original Message ------
>> From: "Sergio Garcia Murillo" > >
>> To: "Paul E. Jones" > >;perc@ietf.org 
>> Sent: 3/30/2017 4:29:08 PM
>> Subject: Re: [Perc] Double Encryption and header extensions issue
>>
>>> One thing I realized is that adding OHB in the payload would mean 
>>> that it is also sent from the sender to the MD, which would be an 
>>> unnecessary overhead.
>>>
>>> Regarding encrypted  extensions, I think that the question is even 
>>> more basic, can we have e2e extensions? My view is that it is not 
>>> possible because extensions and ids are negotiated HBH, not E2E.
>>>
>>> If we don't (can't) have E2E extensions, there is no reason at all 
>>> to mandate OHB to be at any specific position, and we will not 
>>> change current rtp header extensions, making it much more easy to 
>>> implement it in current products.
>>>
>>> Best regards
>>> Sergio
>>>
>>> On 30/03/2017 22:20, Paul E. Jones wrote:
>>>> Sergio,
>>>>
>>>> Moving the OHB to the payload is doable, but perhaps a better 
>>>> solution is simply have the endpoint always insert the OHB as the 
>>>> first header extension.  We could also pre-populate that with every 
>>>> single value that we might ever want to change (i.e., allow it to 
>>>> be a fixed size).  Having a fixed-size was suggested yesterday in 
>>>> the meeting.  It would mean, though, that the header extensions are 
>>>> not E2E authenticated or encrypted.  I don't know how important 
>>>> that might be to anyone.
>>>>
>>>> Paul
>>>>
>>>> ------ Original Message ------
>>>> From: "Sergio Garcia Murillo" >>> >
>>>> To: "Paul E. Jones" >>> >;perc@ietf.org 
>>>> Sent: 3/30/2017 1:54:07 PM
>>>> Subject: Re: [Perc] Double Encryption and header extensions issue
>>>>
>>>>> Hi Paul
>>>>>
>>>>> Re: RTX/FEC, yeah I know, IMHO the problem has the same root cause 
>>>>> and solution, but let's keep that discussion on a separate thread.
>>>>>
>>>>> Regarding OHB, as a developer, changing meaning of rtp headers 
>>>>> depending on the relative position of the OHB feels very 
>>>>> unfriendly for me, specially if I have later have to reconstruct 
>>>>> the packet and apply padding to keep boundaries. Doesn't seem a 
>>>>> clean solution IMHO.
>>>>>
>>>>> I would really prefer to not touch the header extensions and move 
>>>>> the OHB to the packet payload, which is were it belongs IMHO (same 
>>>>> as OSN in normal RTX). That brings another question, which I will 
>>>>> open on a new email.
>>>>>
>>>>> Best regards
>>>>> Sergio
>>>>>
>>>>> On 30/03/2017 19:42, Paul E. Jones wrote:
>>>>>> Sergio,
>>>>>>
>>>>>> For RTX and FEC, I wasn't referring to the header extensions, but 
>>>>>> rather how those are handled in light of "double."
>>>>>>
>>>>>> What you suggest is certainly possible.  We could have the 
>>>>>> endpoints insert the OHB as the first extension and then have all 
>>>>>> others follow it.  That would make all extensions HBH, effectively.
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> ------ Original Message ------
>>>>>> From: "Sergio Garcia Murillo" >>>>> >
>>>>>> To: "Paul E. Jones" >>>>> >;perc@ietf.org 
>>>>>> Sent: 3/30/2017 1:02:39 PM
>>>>>> Subject: Re: [Perc] Double Encryption and header extensions issue
>>>>>>
>>>>>>> Maybe I am jumping to the conclusions too fast, but IMHO both 
>>>>>>> RTX/FEC and header extensions should be HBH and not E2E.
>>>>>>>
>>>>>>> For header extensions I don't see a feasible way of negotiating 
>>>>>>> the minimum common header extension subsets and getting all 
>>>>>>> clients use the same extensions with same id. Also, I don't see 
>>>>>>> much value in having the rtp header extensions E2E, as except 
>>>>>>> the video orientation one, most of them are meant to be 
>>>>>>> terminated at the MD (except the video orientation which would 
>>>>>>> just need to be copied by the SFU).
>>>>>>>
>>>>>>> Also, I don't see any privacy issue doing extensions HBH, as 
>>>>>>> they are transmitted in clear to the MD, and even more, the main 
>>>>>>> purpose of the rfc6904 for encrypted header extensions was to 
>>>>>>> protect the client to mixer/mixer to client audio indications, 
>>>>>>> which by definition are not E2E and required by an SFU to operate.
>>>>>>>
>>>>>>> So IMHO, the inner encryption should be done on a "cloned" 
>>>>>>> packet without extensions, and even more, we could use that 
>>>>>>> encoded packet as the media payload of the outer encryption and 
>>>>>>> forget about OHB completely and solve the RTX/FEC issue 
>>>>>>> altogether. After all, it would be just a matter of adding an 
>>>>>>> extra 12 bytes overhead (the full rtp payload header) vs the 
>>>>>>> current OHB header extension, which could get also up to those 
>>>>>>> 12 bytes if we need to include ssrc and ts.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Sergio
>>>>>>>
>>>>>>> On 30/03/2017 18:31, Paul E. Jones wrote:
>>>>>>>> Sergio,
>>>>>>>>
>>>>>>>> Your interpretation is correct, I think.  When we submitted the 
>>>>>>>> original proposal for PERC (that we called "PRIME"), the RTP 
>>>>>>>> payload itself was encrypted using an E2E key, but the headers 
>>>>>>>> only authenticated with a HBH key.  That draft was this:
>>>>>>>> https://tools.ietf.org/html/draft-jones-avtcore-private-media-framework-00
>>>>>>>>
>>>>>>>> This was proposed using a single crypto context with an 
>>>>>>>> additional E2E key.  Another way to have viewed this (which I 
>>>>>>>> think is perhaps easiest to comprehend) is that there were two 
>>>>>>>> contexts, one for E2E and one for HBH.  The E2E context would 
>>>>>>>> have used, for example, AES-CM with null authentication and the 
>>>>>>>> HBH context would have used null encryption and HMAC-SHA1 for 
>>>>>>>> authentication.  (Of course, any ciphers or auth functions 
>>>>>>>> could have been used.)  This would have allowed the middlebox 
>>>>>>>> to change headers as it saw fit, so long as we retained the 
>>>>>>>> fields required to re-construct the crypto contexts.  However, 
>>>>>>>> the need to maintain SSRC and sequence numbers to reconstruct 
>>>>>>>> the crypto context is where a lot of discussion took place that 
>>>>>>>> forced some discussion on how we had proposed to do the encryption.
>>>>>>>>
>>>>>>>> Double addressed the issue of changing certain critical fields, 
>>>>>>>> while also moving toward authenticated encryption.  There were 
>>>>>>>> concerns with introducing a new RFC with a split in encryption 
>>>>>>>> and authentication, so Double addressed those concerns, too.
>>>>>>>>
>>>>>>>> However, you're right that the negotiated values might present 
>>>>>>>> a problem.  I've not spent much time thinking about how to 
>>>>>>>> solve that.  During this meeting, there were also concerns 
>>>>>>>> raised with Double and how it works with RTX and FEC. 
>>>>>>>> Obviously, we need to get that right and perhaps those and the 
>>>>>>>> RTP header extension concerns you raise should both be topics 
>>>>>>>> for discussion in an interim meeting that the chairs will be 
>>>>>>>> arranging.
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> ------ Original Message ------
>>>>>>>> From: "Sergio Garcia Murillo" >>>>>>> >
>>>>>>>> To:perc@ietf.org 
>>>>>>>> Sent: 3/30/2017 11:16:11 AM
>>>>>>>> Subject: [Perc] Double Encryption and header extensions issue
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I have been reviewing the documentation for double encryption 
>>>>>>>>> and I have serious doubts about how the header extensions are 
>>>>>>>>> handled.
>>>>>>>>>
>>>>>>>>> If I have understood it (please correct me if I am wrong) the 
>>>>>>>>> MD must rely all the header extensions present before the OHB 
>>>>>>>>> to the other peers:
>>>>>>>>>
>>>>>>>>>        The Media Distributor MUST NOT delete any header extensions before
>>>>>>>>>        the OHB, but MAY add, delete, or modify any that follow the OHB.
>>>>>>>>>
>>>>>>>>> This is an obvious requirement, as to be able to decrypt the 
>>>>>>>>> inner crypto, the end receiver must have the same original rtp 
>>>>>>>>> packet, which includes header extensions.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Is there anything that I missing?
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Sergio
>>>>>>>
>>>>>>>
>>>>>
>>>
>> _______________________________________________
>> Perc mailing list
>> Perc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/perc
>


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


  
    
  
  
    
I agree

      

      Best regards

      Sergio

      On 31/03/2017 1:09, Nils Ohlmeier wrote:

    

    

      
      Hi,
      


      

      
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.

      


      

      
Best

      
  Nils

      


      

      

        

          

            
On Mar 30, 2017, at 17:54, Paul E. Jones <paulej@packetizer.com>
              wrote:

            

            

              
Sergio,

              


              

              
Yeah, all of
                these are valid points. Likely, none should be E2E
                extensions, but that would mean that the OHB will always
                be first in the packet the way things are presently
                defined, since HBH extensions are added after the OHB.

              


              

              
Perhaps others can suggest when/why we might
                need E2E RTP header extensions.

              


              

              
Paul

              


              

              
------
                Original Message ------

              
From: "Sergio
                Garcia Murillo" <sergio.garcia.murillo@gmail.com>

              
To: "Paul E.
                Jones" <paulej@packetizer.com>; perc@ietf.org

              
Sent:
                3/30/2017 4:29:08 PM

              
Subject: Re:
                [Perc] Double Encryption and header extensions issue

              


              

              

                

                  
One thing I realized is
                    that adding OHB in the payload would mean that it is
                    also sent from the sender to the MD, which would be
                    an unnecessary overhead.

                    

                    Regarding encrypted  extensions, I think that the
                    question is even more basic, can we have e2e
                    extensions? My view is that it is not possible
                    because extensions and ids are negotiated HBH, not
                    E2E.

                    

                    If we don't (can't) have E2E extensions, there is no
                    reason at all to mandate OHB to be at any specific
                    position, and we will not change current rtp header
                    extensions, making it much more easy to implement it
                    in current products.

                    

                    Best regards

                    Sergio

                    

                    On 30/03/2017 22:20, Paul E. Jones wrote:

                  

                  

                    
Sergio,

                    


                    

                    
Moving the OHB to the payload is
                      doable, but perhaps a better solution is simply
                      have the endpoint always insert the OHB as the
                      first header extension.  We could also
                      pre-populate that with every single value that we
                      might ever want to change (i.e., allow it to be a
                      fixed size).  Having a fixed-size was suggested
                      yesterday in the meeting.  It would mean, though,
                      that the header extensions are not E2E
                      authenticated or encrypted.  I don't know how
                      important that might be to anyone.

                    


                    

                    
Paul

                    


                    

                    
------ Original Message ------

                    
From: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>

                    
To: "Paul E. Jones" <paulej@packetizer.com>; perc@ietf.org

                    
Sent: 3/30/2017 1:54:07 PM

                    
Subject: Re: [Perc] Double Encryption
                      and header extensions issue

                    


                    

                    

                      

                        
Hi Paul

                          

                          Re: RTX/FEC, yeah I know, IMHO the problem has
                          the same root cause and solution, but let's
                          keep that discussion on a separate thread.

                          

                          Regarding OHB, as a developer, changing
                          meaning of rtp headers depending on the
                          relative position of the OHB feels very
                          unfriendly for me, specially if I have later
                          have to reconstruct the packet and apply
                          padding to keep boundaries. Doesn't seem a
                          clean solution IMHO.

                          

                          I would really prefer to not touch the header
                          extensions and move the OHB to the packet
                          payload, which is were it belongs IMHO (same
                          as OSN in normal RTX). That brings another
                          question, which I will open on a new email.

                          

                          Best regards

                          Sergio

                          

                          On 30/03/2017 19:42, Paul E. Jones wrote:

                        

                        

                          
Sergio,

                          


                          

                          
For RTX and FEC, I wasn't
                            referring to the header extensions, but
                            rather how those are handled in light of
                            "double."

                          


                          

                          
What you suggest is certainly
                            possible.  We could have the endpoints
                            insert the OHB as the first extension and
                            then have all others follow it.  That would
                            make all extensions HBH, effectively.

                          


                          

                          
Paul

                          


                          

                          
------ Original Message ------

                          
From: "Sergio Garcia Murillo"
                            <sergio.garcia.murillo@gmail.com>

                          
To: "Paul E. Jones" <paulej@packetizer.com>; perc@ietf.org

                          
Sent: 3/30/2017 1:02:39 PM

                          
Subject: Re: [Perc] Double
                            Encryption and header extensions issue

                          


                          

                          

                            

                              
Maybe I am
                                jumping to the conclusions too fast, but
                                IMHO both RTX/FEC and header extensions
                                should be HBH and not E2E.

                                

                                For header extensions I don't see a
                                feasible way of negotiating the minimum
                                common header extension subsets and
                                getting all clients use the same
                                extensions with same id. Also, I don't
                                see much value in having the rtp header
                                extensions E2E, as except the video
                                orientation one, most of them are meant
                                to be terminated at the MD (except the
                                video orientation which would just need
                                to be copied by the SFU).

                                

                                Also, I don't see any privacy issue
                                doing extensions HBH, as they are
                                transmitted in clear to the MD, and even
                                more, the main purpose of the rfc6904
                                for encrypted header extensions was to
                                protect the client to mixer/mixer to
                                client audio indications, which by
                                definition are not E2E and required by
                                an SFU to operate.

                                

                                So IMHO, the inner encryption should be
                                done on a "cloned" packet without
                                extensions, and even more, we could use
                                that encoded packet as the media payload
                                of the outer encryption and forget about
                                OHB completely and solve the RTX/FEC
                                issue altogether. After all, it would be
                                just a matter of adding an extra 12
                                bytes overhead (the full rtp payload
                                header) vs the current OHB header
                                extension, which could get also up to
                                those 12 bytes if we need to include
                                ssrc and ts.

                                

                                Best regards

                                Sergio

                                

                                On 30/03/2017 18:31, Paul E. Jones
                                wrote:

                              

                              

                                
Sergio,

                                


                                

                                
Your interpretation is
                                  correct, I think.  When we submitted
                                  the original proposal for PERC (that
                                  we called "PRIME"), the RTP payload
                                  itself was encrypted using an E2E key,
                                  but the headers only authenticated
                                  with a HBH key.  That draft was this:

                                
                                


                                

                                
This
                                  was proposed using a single crypto
                                  context with an additional E2E key.
                                   Another way to have viewed this
                                  (which I think is perhaps easiest to
                                  comprehend) is that there were two
                                  contexts, one for E2E and one for HBH.
                                   The E2E context would have used, for
                                  example, AES-CM with null
                                  authentication and the HBH context
                                  would have used null encryption and
                                  HMAC-SHA1 for authentication.  (Of
                                  course, any ciphers or auth functions
                                  could have been used.)  This would
                                  have allowed the middlebox to change
                                  headers as it saw fit, so long as we
                                  retained the fields required to
                                  re-construct the crypto contexts.
                                   However, the need to maintain SSRC
                                  and sequence numbers to reconstruct
                                  the crypto context is where a lot of discussion
                                    took place that forced some
                                    discussion on how we had proposed to
                                    do the encryption.

                                


                                

                                
Double
                                  addressed the issue of changing
                                  certain critical fields, while also
                                  moving toward authenticated
                                  encryption.  There were concerns with
                                  introducing a new RFC with a split in
                                  encryption and authentication, so
                                  Double addressed those concerns, too.

                                


                                

                                
However,
                                  you're right that the negotiated
                                  values might present a problem.  I've
                                  not spent much time thinking about how
                                  to solve that.  During this meeting,
                                  there were also concerns raised with
                                  Double and how it works with RTX and
                                  FEC. Obviously, we need to get that
                                  right and perhaps those and the RTP
                                  header extension concerns you raise
                                  should both be topics for discussion
                                  in an interim meeting that the chairs
                                  will be arranging.

                                


                                

                                
Paul

                                


                                

                                
------ Original Message
                                  ------

                                
From: "Sergio Garcia
                                  Murillo" <sergio.garcia.murillo@gmail.com>

                                
                                
Sent: 3/30/2017 11:16:11
                                  AM

                                
Subject: [Perc] Double
                                  Encryption and header extensions issue

                                


                                

                                

                                  

                                    
Hi all,

                                    
I have been reviewing
                                      the documentation for double
                                      encryption and I have serious
                                      doubts about how the header
                                      extensions are handled.

                                    
If I have understood it
                                      (please correct me if I am wrong)
                                      the MD must rely all the header
                                      extensions present before the OHB
                                      to the other peers:

                                    
      The Media Distributor MUST NOT delete any header extensions before
      the OHB, but MAY add, delete, or modify any that follow the OHB.



                                    This is an obvious requirement, as
                                    to be able to decrypt the inner
                                    crypto, the end receiver must have
                                    the same original rtp packet, which
                                    includes header extensions.

                                    

                                    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.

                                    

                                    
Is there anything that I
                                      missing?

                                    

                                    Best regards

                                    Sergio

                                  

                                

                              

                              


                              

                            

                          

                        

                        


                        

                      

                    

                  

                  


                  

                

              

              _______________________________________________

              Perc mailing list

              Perc@ietf.org

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

          

        

        

      

    

    


    

  


--------------254E7F27AD129E7EB060BA96--


From nobody Thu Mar 30 18:47:15 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 C6620129444 for ; Thu, 30 Mar 2017 18:47:13 -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, 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 MJticmP5bl99 for ; Thu, 30 Mar 2017 18:47:12 -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 DBAB4126DDF for ; Thu, 30 Mar 2017 18:47:11 -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 v2V1l9Yv006304 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 21:47:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1490924830; bh=hkyEBNvIY1oV5AOe3fmf+RvDh4xSnhDkAQh3cOFyBaw=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=IpX2PfIxAGPCjMeOmWoq26O8YSJYG5E2oMXcXXxQUDRLTz4G+HJnZCXvmRCYJRfda 1qye6g9EdC/ZNhNeVGeMUtk7rpQ5HER3eYwXVtzlLpmsGDM/TNNtdGFg41D4QhTSNT Jo2Lt457AyBFUsNuK1G/8lB8FyFWw1aVjKvZmODM=
From: "Paul E. Jones" 
To: "Sergio Garcia Murillo" , perc@ietf.org
Date: Fri, 31 Mar 2017 01:47:11 +0000
Message-Id: 
In-Reply-To: 
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>  <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com>  
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 30 Mar 2017 21:47:10 -0400 (EDT)
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: Fri, 31 Mar 2017 01:47:14 -0000

Sergio,

Signaling work has literally just started with an initial draft from=20
Adam Roach:
https://tools.ietf.org/html/draft-roach-perc-webrtc-00

One big clue is that when DTLS-SRTP is performed, the ciphers indicated=20
would be DOUBLE_*.  Another clue will be the EKTKey message, though that=20
in and of itself doesn't mean "PERC" and endpoints that do not=20
understand that DTLS message will not act on it.  We might want to have=20
something more explicit, but that isn't yet defined.

Paul

------ Original Message ------
From: "Sergio Garcia Murillo" 
To: "Paul E. Jones" ; perc@ietf.org
Sent: 3/30/2017 6:57:04 PM
Subject: Re: [Perc] Double encryption codec/payload type

>
>
>>Even if we split the two-pass encryption step fully into two pieces,=20
>>that's not creating a tunnel or a new media type.  It's just how the=20
>>crypto transforms are applied.  Devices who receive the media are=20
>>going to know and understand this, because it will be negotiated in=20
>>SDP.
>
>That is my key question, how it will be signaled?
>
>Best regards
>Sergio


From nobody Thu Mar 30 19:09:24 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 370281296CA for ; Thu, 30 Mar 2017 19:09:22 -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 kx7K_qJNEvir for ; Thu, 30 Mar 2017 19:09:20 -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 EA82112708C for ; Thu, 30 Mar 2017 19:09:19 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id s68so75955254vke.3 for ; Thu, 30 Mar 2017 19:09:19 -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=194D/NJ5YQgZmVFoEfLA3HvtCaGWUen+/XUg6HaUBuk=; b=maWNdipfaq8GQ9GTc3esrd+6ruQA9ZT687koD3J8/l02PUFQe/HgNTmcRry9hfIvxQ gUw8bfq04LTwLkTX8eKh1onZwfGIqHQ0jhSU4zKUFOVs3nNiml996UT34A46SFbuMWVH bTkl6Kan+RhrZl5Pyvup6+nQimnR5C7vGu7wPDRIdWQOEZj41bcLXNsD1ZXS+Hzf/E9v dOpLeZjbDmfuRcyjiU/5mjbC3HOpPdoCH33Wunqt3kcwDgYDOTm0R/VklyNdSwQSi/4I kH2G5CxbO9lk3JNLY9Te1QUlyHX6JUgAqJ2SdPXPGJgYmR4CEU14ldI5Hi39fkKvHfiX KnXQ==
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=194D/NJ5YQgZmVFoEfLA3HvtCaGWUen+/XUg6HaUBuk=; b=TFWC8WsNzqhyq1NSHq6b2E8d7HyyxvL/81ewiYhxCWpXpXG6/mh6sIJld7VGEbWcJz 9lbi/27C4jHbtOxDtk1Anis+rWhUomOSgd4DLzb3b3woT2wNH6PH/WlGRLcOopbfx4eI O1hxzjTOoOGKXvgIKUlDrXdKo6eXG+x/PrE1haGJX9C4/1VUyjJbrAh8R9VIA5i4iQ51 nTvHmsO11Ywwza/SHtW9XkqzrErvR0OiFJcSkURBJ11tKDANG74sgXJn3frKnI1oLKko 6oFYW/GGv3UyTC7J6oSIqnbwqWTAvW1ThsKZ814FTBOj2RGYTR+yLo5RFi0Vo+Mf6szD rA9w==
X-Gm-Message-State: AFeK/H0o5gXMjB0uR5rj5VNUxycXl+LMggGhGm4itUlYwXo1o/9Oo4HCYW9E6K2P26Fi6w+uTzrawGIdWHStHw==
X-Received: by 10.31.10.133 with SMTP id 127mr279144vkk.5.1490926158969; Thu, 30 Mar 2017 19:09:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.83.99 with HTTP; Thu, 30 Mar 2017 19:08:58 -0700 (PDT)
In-Reply-To: <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com>
References: <10c37f1c-bac9-e720-2ba3-27a039e609f0@gmail.com>  <0202dc89-8a44-1b83-0b9d-c4c9a9100c70@gmail.com>  <30ea7b51-cd54-e04f-cc2a-d4e1424c7ea3@gmail.com>
From: Bernard Aboba 
Date: Thu, 30 Mar 2017 21:08:58 -0500
Message-ID: 
To: Sergio Garcia Murillo 
Cc: "Paul E. Jones" , perc@ietf.org
Content-Type: multipart/alternative; boundary=001a1144142c1782d3054bfd4c9c
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: Fri, 31 Mar 2017 02:09:22 -0000

--001a1144142c1782d3054bfd4c9c
Content-Type: text/plain; charset=UTF-8

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
>

--001a1144142c1782d3054bfd4c9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This would be my preferred option as well, particularly be=
cause 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@gma=
il.com> wrote:
On 31/03/201=
7 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





--001a1144142c1782d3054bfd4c9c--