From nobody Tue Nov 14 19:47: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 F3F16128D86 for ; Tue, 14 Nov 2017 19:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ1l4y4dBEoE for ; Tue, 14 Nov 2017 19:47:01 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 BCDAB1294C9 for ; Tue, 14 Nov 2017 19:47:01 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id l19so14458854pgo.2 for ; Tue, 14 Nov 2017 19:47:01 -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:cc:to; bh=8TTmInFCw215V1UUi/Hly39CBR26Po67sSRl/rO4YcE=; b=KY732u7FoMbZ5ZafTDyHplbTp0Lf8La0FOLdaGO3yL5itRuybIi3+koTcGCDMgzidA Yukv3wu9AickSUKt98VxY7c9tvD9vl2Ys71nhl8y2NXjFggR21C/tiZFE1fRrJ9RVXuO zTQ+E1yXXLRugiBsCKrNLan3qeWCZk/NBWHjE= 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:cc:to; bh=8TTmInFCw215V1UUi/Hly39CBR26Po67sSRl/rO4YcE=; b=YF4MGvRFKrFyJBgLl0hpBTrmelDv7R0+tV8kJbmBW8pVPciboc7x1t6TaxgFC2qPAd zrGt60yJ0j1q4tx3CTp4iyks0UNRboKr1d5HMaUaAszgeyVyE8FTyX6R8xy5Y7BJCls7 kH1Ius7PCG8/tilq7xHfSjTPGkeV/l0hoxPl7qoFrZocCryNmKhQhRBryLxkFAQaC1BM MtnSPzMevkkb/iymrcVHaByajJT9/zBKlmsPky7WE63cexERqw6T2IW46L8eKuU4PdhZ 9erV/MLmkSWdZsHCxfMR4sCG+XtDcjXpsZuUcsyCBV7CXLf9ssdt0I483pSrVbjpjxtO wbTQ== X-Gm-Message-State: AJaThX6EyWM6mkqAQ8UNm6IImwEzxs/5CjRFUs34LDFQjDz4Py4jw+V6 w1GQ8QGmh6MMN5pzx4nJNdsjbrNiQK8= X-Google-Smtp-Source: AGs4zMYoE2fupqFjn4XFvZ5RwDkCJd41qcTG37WkzikysfICT/5WWtswMhzeg3sWoZtDe6J7S+zK1g== X-Received: by 10.159.194.6 with SMTP id x6mr14634622pln.359.1510717620635; Tue, 14 Nov 2017 19:47:00 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:b12e:f306:222a:b6a0? ([2001:67c:370:128:b12e:f306:222a:b6a0]) by smtp.gmail.com with ESMTPSA id l5sm47623136pfi.165.2017.11.14.19.46.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:46:59 -0800 (PST) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_9F84C22C-644D-4AC6-A781-B18EE4F94349"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: Date: Wed, 15 Nov 2017 11:44:19 +0800 Cc: draft-ietf-perc-double@ietf.org To: perc@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Perc] Review of draft-ietf-perc-double-07 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 Nov 2017 03:47:04 -0000 --Apple-Mail=_9F84C22C-644D-4AC6-A781-B18EE4F94349 Content-Type: multipart/alternative; boundary="Apple-Mail=_EE5059F9-ED7C-48F1-9B3C-247486569999" --Apple-Mail=_EE5059F9-ED7C-48F1-9B3C-247486569999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, As an individual contributor I reviewed draft-ietf-perc-double-07. I don=E2=80=99t think that the draft is ready for moving forward yet, = because of the TODO in section 7.2. Here is the more detailed list of my findings: Section 1: =E2=80=9CSee the framework document that describes this concept in more = detail in more detail in=E2=80=9D one time =E2=80=9Cin more detail=E2=80=9D= should be enough. =E2=80=9CThe original value of any RTP header field that is changed is = included in a new RTP header extension called the Original Header = Block.=E2=80=9D double no longer uses an RTP header extension. Section 3: =E2=80=9CAssign the key and salt values generated for the inner = (end-to-end) algorithm to the first half of the key and salt for the = double algorithm.=E2=80=9D To me that sentence doesn=E2=80=99t make it = 100% clear if only half of the salt is used or not. I would propose to = change this to =E2=80=9C=E2=80=A6 algorithm to the first half of the key = and the first half to the salt for the double algorithm.=E2=80=9D Same = applies to the next bullet point. Section 4: =46rom my reading when the receiving endpoint wants to extract the OHB = it will read the last byte of the RTP payload (after decrypting and = verifying the outer encryption). Then depending on the content of that = byte, the Config, it might need to read up to three more bytes. = Wouldn=E2=80=99t it be easier to always put the full 4 bytes of OHB at = the end of the RTP payload and zero it out if not used? Then the = receiving endpoint knows that it can always split of the last 4 bytes no = matter what their content is. It would be easier to read if the list of letter acronyms would be = sorted by first occurrence in the config byte diagram. Section 5.1 4th step: =E2=80=9CApply the inner cryptographic algorithm to the RTP = packet.=E2=80=9D Which packet is that? The packet from step 1 or the = synthetic packet from step 3? Section 5.2 2nd step: =E2=80=9C=E2=80=A6 and are allowed =E2=80=A6=E2=80=9D should = be =E2=80=9C=E2=80=A6 and is allowed =E2=80=A6=E2=80=9D. 2nd step: I think we need a reference to a list of the part of the RTP = packet it is allowed to modify. 3rd step: To me the first and the second sentences are contradicting = them self a little bit. The first sentence starts with =E2=80=9CIf a = changed RTP header field is not already in the OHB,=E2=80=A6=E2=80=9D. = But that is not really an if condition here, because as the next = sentence explains the relay would have not been allowed to touch/change = the value if the value was already in the OHB (because it got already = modified by a previous relay). 3rd step: similar to my comment for section 4, adding something to the = OHB actually means removing the empty config byte of OHB, adding the = original value and then append the new config byte. 3rd step: maybe the easier description would be here something like: = Remove the original OHB from the end of the packet. If the value is = already contained in the OHB it can=E2=80=99t modify the value again. = Append all original values of values the relay modified and append the = new config byte of the OHB. 3rd step: As we are appending now OHB at the end of the packet, we could = actually allow a chain of media relays to modify values which the = previous relay had modified already. The second relay would then have to = append another OHB to the packet. As long the endpoint receives only one = OHB with the original values from the sender I think this might work, if = people are interested in such a feature. Why is there no section describing how to handle repair packets for = media relays? Section 5.3 2nd step: why does this step say to skip the rest of the steps? I think = the handling actually depends on the repair mechanism. But without = further instructions this sounds like an endpoint could simply =E2=80=9Cpl= ay the media=E2=80=9D, where I think it still needs to do inner = decryption, because the repair packets from the media relay hopefully = will still be encrypted end-to-end. Section 7.1 It might be worth pointing out how to handle the receiver part of RTX. = Which I believe is decrypt HBH2, undo RTX transformation, then follow = the steps in section 5.3 Section 7.2 This section says literally =E2=80=98TODO=E2=80=99. This needs to = written out how to handle option A from the Prag slides. Section 7.3: =E2=80=9C=E2=80=A6 it MUST be encrypted in repair mode packet.=E2=80=9D = doesn=E2=80=99t quite parse for me. I guess this meant to be =E2=80=9C=E2=80= =A6 it MUST be encrypted in packet repair mode.=E2=80=9D. Section 8 The last paragraph which talks about the changes in size of the packet = probably needs to updated, because it still considers the OHB to be a = RTP header extension. And I think it should also include the sizes = caused by doing tripple encryption for any of the repair mechanisms. Section 9 This section also looks to me like it needs a brief update for the fact = that the OHB no longer goes into the RTP header extensions, e.g. =E2=80=9C= Any additional headers added by the Media Distributor=E2=80=A6=E2=80=9D. Section 10.1 This section needs to be deleted as we no longer use a RTP header = extension. Best regards Nils Ohlmeier, as an individual contributor --Apple-Mail=_EE5059F9-ED7C-48F1-9B3C-247486569999 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

As = an individual contributor I reviewed = draft-ietf-perc-double-07.

I don=E2=80=99t think that the draft is ready for moving = forward yet, because of the TODO in section 7.2.

Here is the more detailed list of my = findings:
  • Section 1:
    • =E2=80=9CSee the framework document = that describes this concept in more detail  in more detail in=E2=80=9D= one time =E2=80=9Cin more detail=E2=80=9D should be enough.
    • =E2=80=9CThe original value of any = RTP header field that is changed is included in a new RTP header = extension called the Original Header Block.=E2=80=9D double no longer = uses an RTP header extension.
  • Section 3:
    • =E2=80=9CAssign the key and salt = values generated for the inner (end-to-end) algorithm to the first half = of the key and salt for the double algorithm.=E2=80=9D To me that = sentence doesn=E2=80=99t make it 100% clear if only half of the salt is = used or not. I would propose to change this to =E2=80=9C=E2=80=A6 = algorithm to the first half of the key and the first half to the salt = for the double algorithm.=E2=80=9D Same applies to the next bullet = point.
  • Section 4:
    • =46rom my reading when the receiving = endpoint wants to extract the OHB it will read the last byte of the RTP = payload (after decrypting and verifying the outer encryption). Then = depending on the content of that byte, the Config, it might need to read = up to three more bytes. Wouldn=E2=80=99t it be easier to always put the = full 4 bytes of OHB at the end of the RTP payload and zero it out if not = used? Then the receiving endpoint knows that it can always split of the = last 4 bytes no matter what their content is.
    • It would be easier to read if the = list of letter acronyms would be sorted by first occurrence in the = config byte diagram.
  • Section 5.1
    • 4th step: =E2=80=9CApply the inner = cryptographic algorithm to the RTP packet.=E2=80=9D Which packet is = that? The packet from step 1 or the synthetic packet from step 3?
  • Section 5.2
    • 2nd step: =E2=80=9C=E2=80=A6 and are = allowed =E2=80=A6=E2=80=9D should be =E2=80=9C=E2=80=A6 and is allowed = =E2=80=A6=E2=80=9D.
    • 2nd step: I think we need a = reference to a list of the part of the RTP packet it is allowed to = modify.
    • 3rd step: To me the first and the = second sentences are contradicting them self a little bit. The first = sentence starts with =E2=80=9CIf a changed RTP header field is not = already in the OHB,=E2=80=A6=E2=80=9D. But that is not really an if = condition here, because as the next sentence explains the relay would = have not been allowed to touch/change the value if the value was already = in the OHB (because it got already modified by a previous relay).
    • 3rd step: similar to my comment for = section 4, adding something to the OHB actually means removing the empty = config byte of OHB, adding the original value and then append the new = config byte.
    • 3rd step: maybe the easier = description would be here something like: Remove the original OHB from = the end of the packet. If the value is already contained in the OHB it = can=E2=80=99t modify the value again. Append all original values of = values the relay modified and append the new config byte of the = OHB.
    • 3rd step: As we are appending now = OHB at the end of the packet, we could actually allow a chain of media = relays to modify values which the previous relay had modified already. = The second relay would then have to append another OHB to the packet. As = long the endpoint receives only one OHB with the original values from = the sender I think this might work, if people are interested in such a = feature.
    • Why is there no section describing = how to handle repair packets for media relays?
  • Section 5.3
    • 2nd step: why does this step say to = skip the rest of the steps? I think the handling actually depends on the = repair mechanism. But without further instructions this sounds like an = endpoint could simply =E2=80=9Cplay the media=E2=80=9D, where I think it = still needs to do inner decryption, because the repair packets from the = media relay hopefully will still be encrypted end-to-end.
  • Section 7.1
    • It might be worth pointing out how = to handle the receiver part of RTX. Which I believe is decrypt HBH2, = undo RTX transformation, then follow the steps in section 5.3
  • Section 7.2
    • This section says literally = =E2=80=98TODO=E2=80=99. This needs to written out how to handle option A = from the Prag slides.
  • Section 7.3:
    • =E2=80=9C=E2=80=A6 it MUST be = encrypted in repair mode packet.=E2=80=9D doesn=E2=80=99t quite parse = for me. I guess this meant to be =E2=80=9C=E2=80=A6 it MUST be encrypted = in packet repair mode.=E2=80=9D.
  • Section 8
    • The last paragraph which talks about = the changes in size of the packet probably needs to updated, because it = still considers the OHB to be a RTP header extension. And I think it = should also include the sizes caused by doing tripple encryption for any = of the repair mechanisms.
  • Section 9
    • This section also looks to me like = it needs a brief update for the fact that the OHB no longer goes into = the RTP header extensions, e.g. =E2=80=9CAny additional headers added by = the Media Distributor=E2=80=A6=E2=80=9D.
  • Section 10.1
    • This section needs to be deleted as = we no longer use a RTP header extension.
Best = regards
  Nils Ohlmeier, as an individual = contributor

= --Apple-Mail=_EE5059F9-ED7C-48F1-9B3C-247486569999-- --Apple-Mail=_9F84C22C-644D-4AC6-A781-B18EE4F94349 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAloLuBMACgkQY2o/VmzJ +KFJohAAyJS2f+cQuT3Ltu1PrT9J0D8ULYu+GOP8SvxCb9BtZ/SvIexSDEXrBP8i 1Ungb9n1VHgXUSdc1VyMR8xbpeSSblW/BAWAveXhUs9wQ0zzyfngN1Rez2bferrF tHhkZ2Me60qESPgnuQaua1Jdy1wt5XSi8KPhLHyujzZnmy9GVOQdvbA8sosiNmjO B9wUgxtJRE+6vJOhptNp2JNU/D0KqKQMO3YP/ZvbLKk4QkJiNof+O500MBuBbnuY JvJsciUuwBqw5omsx0r0HzvOTWA2xFntE6zZoOEvx/7jDYlVpNmOOhmu3nJ5hkru H0tw/dqkgKbZXvZgUjGM2IQVlua5XO2Ex9OvVopxa8wUmrgVyFzoyoVnj0SpPpNb O8aZcqpsFxug1IUMZHFwpR1xRybT3rPv7tN516nKE/2N3bcKh8VJJUYE10QQsSxp fLmiaZ5oBCOpzwoEsn7+kgpxDJAjZbxvZQNnCo8d+StPg1l900orQwF5dXLLGF5c QOsd3UIUU0po1nVITTZNvN/FgaffibB6xDgVVjQ9x3q75Z3ae/WEuOCJGjg8j+eN UV/p0wkMl7Yad0Fx+bwqc+0u/EV2iZSENMW17vLgp7bzLzLYBQ0Ylq+zlYHjT1Xj IRtEiOds3k0Flm+kTyOR1f9+S4ct6pnJDw+ZXLHyfeookqfSBaA= =C01J -----END PGP SIGNATURE----- --Apple-Mail=_9F84C22C-644D-4AC6-A781-B18EE4F94349-- From nobody Tue Nov 14 19:50: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 AAD451294EE for ; Tue, 14 Nov 2017 19:50:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxnvFMxl-QOd for ; Tue, 14 Nov 2017 19:50:09 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 9B9371294DB for ; Tue, 14 Nov 2017 19:50:03 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id r12so269952pgu.10 for ; Tue, 14 Nov 2017 19:50:03 -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=jI2+A/aWHW+c5e+AmC8LnxaUFoQGCl69XZru7t7sHHU=; b=RBvOQN+aooxwYWQV/rKVWyThlvS0Ay/h74tYv7gB6QUzNZ0oTiW3RjTxmUgCV8i/ww gzkN96hTmRrYAzEzmlsupU06jtxq7G2FoD4RFDvJSXAQCtGw880f+BOTxPExSz+Dgf7m UYNoOMBNpbTilTm0ppitkosHwHO2+V8Vve4MQ= 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=jI2+A/aWHW+c5e+AmC8LnxaUFoQGCl69XZru7t7sHHU=; b=SEo09asOgV12RMVs7z0fVXccqD0zaFU45HZI5wjeFhOUp8junjIJWI1Lly4Vm6kTIR hR5iOspOGJL/arEmlROeijPmY3wdHL7xIUIJPOSTYBgV+PnCAJbHqDqIWgJXJK6aM9bK vSxmMmfwJQY0lT405xQlBlctc4PP6extr8SSGIZhLJV3GXxftWmxE8VMFf0R1Bv2mu/0 Jb5/1Zc2fV5K194+f2eU/Xl8U6Zwod0Vzfct5OUrO+OSf+o91xi66JDqS9sarNah84n8 gQGXLZ7506KEawD0hJ2TiigIxefOqYXDEtGAi5NDPt63ox4tX6ZufGTXgki1UBC13VeL SXvg== X-Gm-Message-State: AJaThX7rGwzh98hBLEWuUwahUcj3jVOLHhjMWpihmauxltx13FJ53PJT TMCJ3F9glwLVmxSSXnLcenHsXAr9Qo8= X-Google-Smtp-Source: AGs4zMZX1WJlZmatDjAf0k/sGtwz/EdC0J9jhdwdQWC286jFD92T6O3CC+EvS4pl2xK57TNS2AAVHQ== X-Received: by 10.98.58.29 with SMTP id h29mr13674421pfa.121.1510717802758; Tue, 14 Nov 2017 19:50:02 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:b12e:f306:222a:b6a0? ([2001:67c:370:128:b12e:f306:222a:b6a0]) by smtp.gmail.com with ESMTPSA id s4sm36169757pgp.40.2017.11.14.19.50.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:50:01 -0800 (PST) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_A54B1E93-E9EB-4F73-8B40-FED46B00F745"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: Date: Wed, 15 Nov 2017 11:47:22 +0800 To: perc@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Perc] Reminder for WGLC on ekt and double X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:50:11 -0000 --Apple-Mail=_A54B1E93-E9EB-4F73-8B40-FED46B00F745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, This is a friendly reminder that we have WGLC running right now for the = double and ekt drafts. Please submit your feedback to the mailing list or share it at latest at = our meeting on Friday at IETF 100. Thank you Your PERC chairs, Suhas and Nils --Apple-Mail=_A54B1E93-E9EB-4F73-8B40-FED46B00F745 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAloLuMoACgkQY2o/VmzJ +KH7ZQ//eDW5I+NfnPTvWnDsewpHUaEG7hxnTC/rBYCoIl0N4bFm+CSV9UBrjgLY vTFuEYEvmx+gWqoDStlRoDqN5tXDGq12KpJXEkbAPWqA8C0xMZT4Qb9EQuKJuPyX aNC+z2LmGb/tDbZl1TxQVEIkwbAnsr2okGKHTdYlgNhilhhh5pyKY84SrKGABj7R 7ryTkilfX67ILgiSlWfVgsVD7wFBKy+VA0oX+YC0qlOJknzjdHVAh3KG1yIzG9to 59qRyzu2YQ+qoC3PE5cn/uINtBwd8Lp/Y2+x0vuNRrmTYriFAUpXXYLMfn7qygkz yyzinRlanwrPaiWK3/g77hgC5wkU4GK/6aynPzYd3gLCjy1/5FpI8p1w3dNk1XKS 7hojtEws0HBsMtW1qSHFPvxlMD+MvhfVEkHnunlZzNtRQgnaqqvbC1NtHWHmLKyO Bh446rBRQiOdXvVloNq02BJvcV3d1AQ4v1qzNQTw6oGm35+et8CR+hFSwCdpSBny JJnZigIft1bYxLhqtJMI4N3cHiTxq0Kwk/Psdh2AVW+QtfEemzBunmAfq1oXcvB3 jMXF+JcvPxNbV9+1Y8Vo8Cn21BO9K2Uf4WjbxfpA1hT/sZNAKQ45G4u0+OBuPDtA TP8SLj9wNqaSWIrbHuH2gBI+3wW9/9C7R0mVKqPp+J6Gk/XNUxY= =sZRt -----END PGP SIGNATURE----- --Apple-Mail=_A54B1E93-E9EB-4F73-8B40-FED46B00F745-- From nobody Wed Nov 15 07:40: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 A61041241FC for ; Wed, 15 Nov 2017 07:40:26 -0800 (PST) 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 YmQbMaWkJPh6 for ; Wed, 15 Nov 2017 07:40:24 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 7D97D1200FC for ; Wed, 15 Nov 2017 07:40:24 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id e143so26733148lfg.12 for ; Wed, 15 Nov 2017 07:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language; bh=dLQeovPTcfRKRx6nJTi7D8yrZR/NkPQc3nTdRTnav9c=; b=KTG48x8jHVLzXO3VIMfBcRTwugg0eHJFHzOCDDWkoxVsqEMkMCVn8Hi7CMWakNqnNs YlmaLoP+90cM+q8/IH+haSH7JmICGZP+98tT+TjyJ+Hw38rX03A0XQklidp5FCzjwNHz /MZyr1aPWOydg4ksK98Musr0RnxtiemOXUwBq7F/VINyyDYDcqS7ed+44spOI29FOfN/ gpVXH5Ynad1phqQszl+r052XgAIBjS8ljxiQKMSNFmsKGTlrgUCUXDIrDKcGWaR9KnrR TesxTCXV3GkjN/9gQKusdR1d9luXPB67Vr12Pd4ELLnlH9QPZJFlOhnsEkPs0MeCi2Xr p86Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language; bh=dLQeovPTcfRKRx6nJTi7D8yrZR/NkPQc3nTdRTnav9c=; b=s4yWX0RtT0N0IfZzbZT0t+fT6TTP7pHjYCwK29IKBu0JBICa6mQz1EaLy1D19YVapT WyraeNMeLi5GrJwb6AQmYDwo7bKbdCL7z9rgIflTJrQYYi0iw7E6oslTeb+a11gQxLoU 84Z6/+LMoPnkTqj2fInWllKPX0pbDsbDjOZAFIgWQ5FrXGfStEzf6qsHj6bghbDEA43N HT5K0/AqjHyE8/rh5Gv6mZWFgR6cfQLZc1YnScT41gMsilUgaRxmzFY1nVI5QN9bUzIb kclaDvZTqgf4e4CK02MrJcEUFqUUPP9ClNNc/qvLNIJuVK8haXU7M8ZMSRjevE9UbXO2 g59w== X-Gm-Message-State: AJaThX5HBOTdFonEOCjE+tM78IiaGFn1Od1I0e+CCpJxW3Wd3xsnrPi0 FSet2Rf2RHzN8EAcNvFtZuoBplbx X-Google-Smtp-Source: AGs4zMZqk9wmhxLdK8oOKbjJFNSqDQ/ySKDEubrn93CQ7RSdnq7f4RYeWST0yUQ4q/8NYiobCbiCeQ== X-Received: by 10.46.18.14 with SMTP id t14mr3912829lje.154.1510760422492; Wed, 15 Nov 2017 07:40:22 -0800 (PST) Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id 66sm4437551ljc.82.2017.11.15.07.40.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 07:40:20 -0800 (PST) From: Sergio Garcia Murillo To: "perc@ietf.org" Message-ID: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> Date: Wed, 15 Nov 2017 16:40:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8DC5B621F35C4630244E6AE2" Content-Language: en-US Archived-At: Subject: [Perc] Double implementation status 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 Nov 2017 15:40:27 -0000 This is a multi-part message in MIME format. --------------8DC5B621F35C4630244E6AE2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, As agreed on latest IETF meeting in Prague, the latest Double Encryption proposal seemed technically correct but we were waiting to validate the viability of implementing the changes required in an RTP stack. In order to modify a current webrtc stack (libwebrtc for example) it would be needed to : * Implement double encryption in libsrtp * Modifications to dtls to support tunneling negotiation and extracting the key pair (I expect this to be fairly easy) * Change all the libwrtc rtp stack to perform rtx/fec after srtp encryption and use the repair mode for it As far as I know, there is a librtsp implementation for double made by cisco, which will cover the double encryption part (https://github.com/bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are important pieces missing in order to fully validate its implementation viability. But the code available seems not to cover the repair_mode to be able to apply only the HBH encryption to the RTX/FEC packets. I also feel that the last point is the key one, because the impact of modification of the fec/rtx and srtp order can be huge. Also, I think that it would be needed to know how it would be the transition phase be handled when we will have "old" webrtc implementations doing fec/rtx before srtp and "new" ones doing it in the opposite way. Best regards Sergio --------------8DC5B621F35C4630244E6AE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello all,

As agreed on latest IETF meeting in Prague, the latest Double Encryption proposal seemed technically correct but we were waiting to validate the viability of implementing the changes required in an RTP stack.

In order to modify a current webrtc stack (libwebrtc for example) it would be needed to :

  • Implement double encryption in libsrtp
  • Modifications to dtls to support tunneling negotiation and extracting the key pair (I expect this to be fairly easy)
  • Change all the libwrtc rtp stack to perform rtx/fec after srtp encryption and use the repair mode for it

As far as I know, there is a librtsp implementation for double made by cisco, which will cover the double encryption part  (https://github.com/bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are important pieces missing in order to fully validate its implementation viability. But the code available seems not to cover the repair_mode to be able to apply only the HBH encryption to the RTX/FEC packets.

I also feel that the last point is the key one, because the impact of modification of the fec/rtx and srtp order can be huge.

Also, I think that it would be needed to know how it would be the transition phase be handled when we will have "old" webrtc implementations doing fec/rtx before srtp and "new" ones doing it in the opposite way.

Best regards

Sergio


--------------8DC5B621F35C4630244E6AE2-- From nobody Thu Nov 16 01:45:59 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1556A129418 for ; Thu, 16 Nov 2017 01:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px3axZan4iP4 for ; Thu, 16 Nov 2017 01:45:55 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 DE5E91292AE for ; Thu, 16 Nov 2017 01:45:54 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 207so17392364pgc.12 for ; Thu, 16 Nov 2017 01:45:54 -0800 (PST) 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=iOiVSM4yWt76W8QOEsjE4aU+j7EKyJ6hoyUIdZAM2ik=; b=ZsI+roLG04oRNiVDPc6JMBn+1RqCrv0fQYtfOrPuRZUbranKjad4bWnoyeNUiBx8Y8 g8OPx0vTiCJiS9dh4e5iXtPZw+Xt6S0cS4I4IuMmkzyeQtVU7A3p1MFJmoLCjzpu9Xth rXv7qHvcW6vJNIjINEAPJ5VAjdN7CPoRPEP2Q= 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=iOiVSM4yWt76W8QOEsjE4aU+j7EKyJ6hoyUIdZAM2ik=; b=D4mJN271I+x10QO5z1fYkQW7o1Dty/D8ADpooawsa+rTSv4vGh0KObHUd6jEsJxf4E Voxskski+EB//sPIcmoA78dsXM25qTE3fuWoLWtUI88el/7pbTLpjnzHnacpcqkPbH/U K9nfGpbTbkRUkHiJBPf2Ln2SpbdYU0qQqKizV12cY6VNApNTv7yYWqhKUzLS1KTGJGRU sBaP2/HCd8FJv2BxK95HfximQtwXamYMyMqJNs11J9EmfmKD6tiPcGc3vnxrKk5FlBN1 JBlL4ttjKvg/Q6aFFDJ4qmt6p8FBtJ0DadzGYLuRS+cWgxgrM1DeWb4AKdrgMudtgREO pacg== X-Gm-Message-State: AJaThX72H7mxsl2IHikqTk+/NC+ymU25TOlQW+RRbFbO6+qpEzxVfu+a yoVEe+jwHF7UbjuteaHAPjCbAQ== X-Google-Smtp-Source: AGs4zMaeMSLAUG9QfgnUtL6yKNzV9mHyWZGqKjJktr5BhVfV7lHysHD6CaPPaz1J+pK7iaoF07uMnA== X-Received: by 10.99.156.26 with SMTP id f26mr1090595pge.433.1510825554336; Thu, 16 Nov 2017 01:45:54 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:68df:d9a3:9e51:4836? ([2001:67c:370:128:68df:d9a3:9e51:4836]) by smtp.gmail.com with ESMTPSA id d6sm2195157pfc.29.2017.11.16.01.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 01:45:52 -0800 (PST) From: Nils Ohlmeier Message-Id: <6B61D903-D3A1-43E2-8A84-BCCA1E901D4D@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_57B4494A-71DC-4E2F-A6E0-7D02BCA209E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Thu, 16 Nov 2017 17:41:14 +0800 In-Reply-To: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> Cc: "perc@ietf.org" To: Sergio Garcia Murillo References: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Perc] Double implementation status 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 Nov 2017 09:45:58 -0000 --Apple-Mail=_57B4494A-71DC-4E2F-A6E0-7D02BCA209E6 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB7CE9C4-3202-4C39-8470-2FE80450F245" --Apple-Mail=_FB7CE9C4-3202-4C39-8470-2FE80450F245 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Sergio, As an individual contributor. > On Nov 15, 2017, at 23:40, Sergio Garcia Murillo = wrote: > In order to modify a current webrtc stack (libwebrtc for example) it = would be needed to : >=20 > Implement double encryption in libsrtp > Modifications to dtls to support tunneling negotiation and extracting = the key pair (I expect this to be fairly easy) > Change all the libwrtc rtp stack to perform rtx/fec after srtp = encryption and use the repair mode for it > As far as I know, there is a librtsp implementation for double made by = cisco, which will cover the double encryption part = (https://github.com/bifurcation/libsrtp/tree/ohb-in-payload = ), but we = feel that there are important pieces missing in order to fully validate = its implementation viability. But the code available seems not to cover = the repair_mode to be able to apply only the HBH encryption to the = RTX/FEC packets. > I also feel that the last point is the key one, because the impact of = modification of the fec/rtx and srtp order can be huge. >=20 True. The changes needed here are quite substantial. But just to avoid people having the impression that PERC lite is easier = to implement: I think that depends a lot on your design, and in case of = Firefox it would also require major surgery. > Also, I think that it would be needed to know how it would be the = transition phase be handled when we will have "old" webrtc = implementations doing fec/rtx before srtp and "new" ones doing it in the = opposite way. My assumption here is that the modifications to your webrtc = implementation need to allow you to run it in either or mode. So that = you can support running calls in the =E2=80=9Cnew=E2=80=9D mode when = doing PERC calls. But you can keep running in the =E2=80=9Cold=E2=80=9D = mode for non-PERC calls. Eventually there might be value in moving all calls over to the = =E2=80=9Cnew=E2=80=9D mode where you always encrypt before caching and = repair. I assume a transition would require some form of signaling = indication that you support and want to do the new mode. But that is = discussion for the future how to solve that. Best regards Nils Ohlmeier --Apple-Mail=_FB7CE9C4-3202-4C39-8470-2FE80450F245 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Sergio,

As an = individual contributor.

On Nov 15, 2017, at 23:40, = Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

In order to modify a current webrtc stack (libwebrtc for = example) it would be needed to :

  • Implement double encryption in libsrtp
    =
  • Modifications to dtls to support tunneling = negotiation and extracting the key pair (I expect this to be fairly easy)
  • Change all the libwrtc rtp stack to perform rtx/fec = after srtp encryption and use the repair mode for it

As far as I know, there is a librtsp = implementation for double made by cisco, which will cover the double encryption part  (https:= //github.com/bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are important pieces missing in order to fully validate its implementation viability. But the code available seems not to cover the repair_mode to be able to apply only the HBH encryption to the RTX/FEC packets.

I also feel that the last point is the key one, = because the impact of modification of the fec/rtx and srtp order can be = huge.

True. The changes needed here are = quite substantial.

But just to avoid = people having the impression that PERC lite is easier to implement: I = think that depends a lot on your design, and in case of Firefox it would = also require major surgery.

Also, I think that it would be needed to know = how it would be the transition phase be handled when we will have "old" webrtc implementations doing fec/rtx before srtp and "new" ones doing it in the opposite way.

My assumption here is that the = modifications to your webrtc implementation need to allow you to run it = in either or mode. So that you can support running calls in the = =E2=80=9Cnew=E2=80=9D mode when doing PERC calls. But you can keep = running in the =E2=80=9Cold=E2=80=9D mode for non-PERC = calls.

Eventually there might be = value in moving all calls over to the =E2=80=9Cnew=E2=80=9D mode where = you always encrypt before caching and repair. I assume a transition = would require some form of signaling indication that you support and = want to do the new mode. But that is discussion for the future how to = solve that.

Best = regards
  Nils Ohlmeier

= --Apple-Mail=_FB7CE9C4-3202-4C39-8470-2FE80450F245-- --Apple-Mail=_57B4494A-71DC-4E2F-A6E0-7D02BCA209E6 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAloNXToACgkQY2o/VmzJ +KHNrA/+KQ6Q0PzRdbJ4USpDBOZ9OM29byxmhow0ZJS0AtvJktePp9GqSnZLWBnW zjhg6Ux8TOrr5oim89fI+PbMJZnjihHVjcA78YXiOCoBKdNZhYJ+degthSLQ6ucy 1m5vyCxIRX1QvgUhLbjUXZXMb3KzfR7TGz4Zyup/EGhncOVkRC9pv+Z9mCZ08YFT sTYVbX8U98iIJoIggpsoLsk0T5Tw7d7OVGjRCik8UlSiIr+Xf6IV9L91laU9ILuq Y9zU3FnE5XpLQkpUduU0nbAhmtvzG4FHI2TOD0LvoNyushP9rOWXWgsqeTrpccKi AePafKWt/zebMDixIqhWZ3kNFQG8KC5PmoVBg75Se7Vzo68i56P5D7WAlpfZ5W31 e3u21nXOgBqh3JGOvle+2O0GQ/NiKOetaO65J5QZSpdcT1ktTQ0JrtFudmixk+bB DkcJjgYvKhYtEuDVn8+Q9vDqWVyG8HN4fm5iTR0W3kr0POvxLNedvo8KGmO0eM78 iTxoqkRjDJHzPWh/VKJah3e6Irj482Ha+GbktreQ6ttficiSO0owxVVqAvI8W33p 98HsrJ0YTPMuIKksVcpGyQFV6KdrhvDfM9aHGq+7tE4eFtCAd+eyW2sneyixMMuC FEIaz0umAP88N/AsUn03yZy80rabVMlIZiC4LVL6z6PPAxac2d8= =d9HF -----END PGP SIGNATURE----- --Apple-Mail=_57B4494A-71DC-4E2F-A6E0-7D02BCA209E6-- From nobody Thu Nov 16 02:59: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 DC026127909 for ; Thu, 16 Nov 2017 02:59:50 -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 Ce5TCakGtRwU for ; Thu, 16 Nov 2017 02:59:48 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1820B127873 for ; Thu, 16 Nov 2017 02:59:48 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id w23so6022385lfd.11 for ; Thu, 16 Nov 2017 02:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wyjqAFYesfuQdxGMKX75kutZstHtt7tTi+/8PPI3DhM=; b=Vml07IzAZlz63YKgjuiBX8l/3NgFp810EilNun2/H9hjfqm2C/AyGWi/nCAn9yF0na G5RObbFNDOZyd1c4LK4TDdJ7OEtGprguMftkZYVfv6K3jpElC1Hflf5CM/gvyZxYJrsI sId79oVTwYzSLZipqlEou0w5dM3n/gS0iH2SbAoZW3LsZRVQ/XchFvqECe572vGVNcLV JtoYF/VMATDObVGjeh6iZLHlk6C7KsZ5+TBR2Kwer4j3ZPjv3I+EanzNSZH+SCudeONw NvnrGZb+wFYLINTli6HpwIlSbxIiCx0wnLvTlhBuBwzKpTdZxkKg6mc/nz34Wo18K+Oa FRvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wyjqAFYesfuQdxGMKX75kutZstHtt7tTi+/8PPI3DhM=; b=SMXZNy/qk60hyb1KC7zGrVunHyCwGg4avhoTIot5OrY9YKjIrFF3dX9FRfFF5WYWMr c77Uff/LQ1hSsGU6HV5MrcXumme81w1L4UXw9mT6YBS9jRmtAK3EyCUIpkEPEY+g3dyw yhKmXOG9kYDoAmqQebJHcEF9S0cp7dMXEbDEeRApswCUB3Lvr1SgLp/xPF03N6Yz8WUR optZfkgCxteirCVj3cBBVeQhNpFzUIjHOWrqgN2Wbv5QHoi0UTFO9QSClc5yieow+3uJ mmnUY5nQPDakDZpED1sgYgdQE8do2yVutA2Y7mweoj+XXvLaNSP+ITeq4w7TwSoL0lxh Parg== X-Gm-Message-State: AJaThX5mqHgeJKIKHNg81+co3Mgg8N2+wa/96Z0Yn9d7wsHXLC5XQXEf KcpHLJjz8Cqmjb651z3QBHWraxHv X-Google-Smtp-Source: AGs4zMaKbxnEyI1My/OvRWodFz+mrIgmzUpNSJfCE0XudTnh7BkFL5piQjGsy2L4A+F0yu9m0FlI2A== X-Received: by 10.46.85.208 with SMTP id g77mr559358lje.114.1510829986056; Thu, 16 Nov 2017 02:59:46 -0800 (PST) Received: from [192.168.0.11] (213.37.228.37.dyn.user.ono.com. [213.37.228.37]) by smtp.googlemail.com with ESMTPSA id u23sm209153lje.79.2017.11.16.02.59.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 02:59:44 -0800 (PST) To: Nils Ohlmeier Cc: "perc@ietf.org" References: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> <6B61D903-D3A1-43E2-8A84-BCCA1E901D4D@mozilla.com> From: Sergio Garcia Murillo Message-ID: <18fd709d-3666-6963-e74d-aa24666921b3@gmail.com> Date: Thu, 16 Nov 2017 11:59:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6B61D903-D3A1-43E2-8A84-BCCA1E901D4D@mozilla.com> Content-Type: multipart/alternative; boundary="------------79C51D2A5CE2095178284100" Content-Language: en-US Archived-At: Subject: Re: [Perc] Double implementation status 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 Nov 2017 10:59:51 -0000 This is a multi-part message in MIME format. --------------79C51D2A5CE2095178284100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 16/11/2017 10:41, Nils Ohlmeier wrote: > Hello Sergio, > > As an individual contributor. > >> On Nov 15, 2017, at 23:40, Sergio Garcia Murillo >> > > wrote: >> >> In order to modify a current webrtc stack (libwebrtc for example) it >> would be needed to : >> >> * Implement double encryption in libsrtp >> * Modifications to dtls to support tunneling negotiation and >> extracting the key pair (I expect this to be fairly easy) >> * Change all the libwrtc rtp stack to perform rtx/fec after srtp >> encryption and use the repair mode for it >> >> As far as I know, there is a librtsp implementation for double made >> by cisco, which will cover the double encryption part  >> (https://github.com/bifurcation/libsrtp/tree/ohb-in-payload), but we >> feel that there are important pieces missing in order to fully >> validate its implementation viability. But the code available seems >> not to cover the repair_mode to be able to apply only the HBH >> encryption to the RTX/FEC packets. >> >> I also feel that the last point is the key one, because the impact of >> modification of the fec/rtx and srtp order can be huge. >> > True. The changes needed here are quite substantial. > > But just to avoid people having the impression that PERC lite is > easier to implement: I think that depends a lot on your design, and in > case of Firefox it would also require major surgery. Hi Nils, Could you elaborate? Adding the end to end encryption is just putting two lines of code in the correct places in libwebrtc. Passing the key from js (which is out of the scope of this wg) has been made substantially easy by having them as a parameter in the setParameters  for rtp senders/receivers. Where do you expect the problem to arise? >> Also, I think that it would be needed to know how it would be the >> transition phase be handled when we will have "old" webrtc >> implementations doing fec/rtx before srtp and "new" ones doing it in >> the opposite way. >> > My assumption here is that the modifications to your webrtc > implementation need to allow you to run it in either or mode. So that > you can support running calls in the “new” mode when doing PERC calls. > But you can keep running in the “old” mode for non-PERC calls. > > Eventually there might be value in moving all calls over to the “new” > mode where you always encrypt before caching and repair. I assume a > transition would require some form of signaling indication that you > support and want to do the new mode. But that is discussion for the > future how to solve that. > Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate? I would prefer to answer that solutions now in order to ensure that we have a complete solution that RTCWEB group could adopt in the future without further discussions. Best regards Sergio --------------79C51D2A5CE2095178284100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 16/11/2017 10:41, Nils Ohlmeier wrote:
Hello Sergio,

As an individual contributor.

On Nov 15, 2017, at 23:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

In order to modify a current webrtc stack (libwebrtc for example) it would be needed to :

  • Implement double encryption in libsrtp
  • Modifications to dtls to support tunneling negotiation and extracting the key pair (I expect this to be fairly easy)
  • Change all the libwrtc rtp stack to perform rtx/fec after srtp encryption and use the repair mode for it

As far as I know, there is a librtsp implementation for double made by cisco, which will cover the double encryption part  (https://github.com/bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are important pieces missing in order to fully validate its implementation viability. But the code available seems not to cover the repair_mode to be able to apply only the HBH encryption to the RTX/FEC packets.

I also feel that the last point is the key one, because the impact of modification of the fec/rtx and srtp order can be huge.

True. The changes needed here are quite substantial.

But just to avoid people having the impression that PERC lite is easier to implement: I think that depends a lot on your design, and in case of Firefox it would also require major surgery.

Hi Nils,

Could you elaborate?

Adding the end to end encryption is just putting two lines of code in the correct places in libwebrtc. Passing the key from js (which is out of the scope of this wg) has been made substantially easy by having them as a parameter in the setParameters  for rtp senders/receivers.

Where do you expect the problem to arise?

Also, I think that it would be needed to know how it would be the transition phase be handled when we will have "old" webrtc implementations doing fec/rtx before srtp and "new" ones doing it in the opposite way.

My assumption here is that the modifications to your webrtc implementation need to allow you to run it in either or mode. So that you can support running calls in the “new” mode when doing PERC calls. But you can keep running in the “old” mode for non-PERC calls.

Eventually there might be value in moving all calls over to the “new” mode where you always encrypt before caching and repair. I assume a transition would require some form of signaling indication that you support and want to do the new mode. But that is discussion for the future how to solve that.

Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate?

I would prefer to answer that solutions now in order to ensure that we have a complete solution that RTCWEB group could adopt in the future without further discussions.

Best regards
Sergio


--------------79C51D2A5CE2095178284100-- From nobody Thu Nov 16 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 CB96C126D0C for ; Thu, 16 Nov 2017 17:04:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOOQs-GbaKw0 for ; Thu, 16 Nov 2017 17:04:28 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE80126CD8 for ; Thu, 16 Nov 2017 17:04:28 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id q4so657607pfg.13 for ; Thu, 16 Nov 2017 17:04:28 -0800 (PST) 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=kCYaV727riewEZISczZbgd2/q+YmHrB5TQPGTwOIGgY=; b=FjK3e+7yo1Jeo9RYaCYQ0B3i9d6OC8D/NGgKBMXG+L1mCEo1YYlf70zirCcce2Hix8 qzNAx9lAQ2xBigz6QvbDjZWo2+lSU+k9Y6E/xCYab2bQzLk/Ca2AiymaaF37+Igdde8G dX7Y6DRLiO2axoXhw+T6lXUG0cnEu3dAH0uxs= 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=kCYaV727riewEZISczZbgd2/q+YmHrB5TQPGTwOIGgY=; b=dxr2cWODsbQieS88W5mYdxDkTFdvXWPFUjXglg6D59Gc2jynd4+aeS94DExYkBE7dI zFC68HZGP2sCPf9ne7Qs7UV5UgPtsvMzO6Vd0Hwv+ptxm72fB+XVrd1NNycIoXrUzov7 N3QcnJqNIGAhpZCgpa7oAO4DC0QwyiryXl2Ap1n2EWxs6/e01NsdZdImmnMBsfD4H4Ll 5KZKRifREsNDm3/6Ib/cs8YlAesK80/zIEPNMHDKXeha/a01WvnxWlRatiGKXwuRzZe9 4D2Jj/cumExGwzYmJAAa3iJpkZdDefUXoRH47wzTwCiso5rBf9IwyzBeG9ZdMEZ6Ww/p mW3Q== X-Gm-Message-State: AJaThX5dQjMtkaQ4Dxa+G2n6LDmUQJCyKE0dTMqtS4YwgvC0Ctt39euk E21Wz+B7/tJWlhAaBrM3wZ9ZvNwdQ/EK2Q== X-Google-Smtp-Source: AGs4zMbaOHnz92dyVeiaVlCnKmUCDs/reoBgcloTO9UVJTiRg4BaqB4GmptOod32GRF78w3GuFoJxg== X-Received: by 10.84.136.135 with SMTP id 7mr146566pll.46.1510880668344; Thu, 16 Nov 2017 17:04:28 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:256b:4c5f:60c:2c02? ([2001:67c:1232:144:256b:4c5f:60c:2c02]) by smtp.gmail.com with ESMTPSA id u12sm4705008pfi.87.2017.11.16.17.04.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 17:04:27 -0800 (PST) From: Nils Ohlmeier Message-Id: <0915A9C1-5515-402B-8CD7-08A65D59AA9A@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D153E22E-C33B-49E2-B7FC-7312A7D24A3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Fri, 17 Nov 2017 08:59:49 +0800 In-Reply-To: <18fd709d-3666-6963-e74d-aa24666921b3@gmail.com> Cc: "perc@ietf.org" To: Sergio Garcia Murillo References: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> <6B61D903-D3A1-43E2-8A84-BCCA1E901D4D@mozilla.com> <18fd709d-3666-6963-e74d-aa24666921b3@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Perc] Double implementation status 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, 17 Nov 2017 01:04:31 -0000 --Apple-Mail=_D153E22E-C33B-49E2-B7FC-7312A7D24A3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 16, 2017, at 18:59, Sergio Garcia Murillo = wrote: >=20 > On 16/11/2017 10:41, Nils Ohlmeier wrote: >> True. The changes needed here are quite substantial. >>=20 >> But just to avoid people having the impression that PERC lite is = easier to implement: I think that depends a lot on your design, and in = case of Firefox it would also require major surgery. >=20 > Hi Nils, >=20 > Could you elaborate? >=20 > Adding the end to end encryption is just putting two lines of code in = the correct places in libwebrtc. Passing the key from js (which is out = of the scope of this wg) has been made substantially easy by having them = as a parameter in the setParameters for rtp senders/receivers. >=20 > Where do you expect the problem to arise? My point is that Firefox doesn't use the standard libwebrtc setup. It = invokes libsrtp way outside the libwebrtc stack. Therefore any PERC = solution will require major surgery. >> My assumption here is that the modifications to your webrtc = implementation need to allow you to run it in either or mode. So that = you can support running calls in the =E2=80=9Cnew=E2=80=9D mode when = doing PERC calls. But you can keep running in the =E2=80=9Cold=E2=80=9D = mode for non-PERC calls. >>=20 >> Eventually there might be value in moving all calls over to the = =E2=80=9Cnew=E2=80=9D mode where you always encrypt before caching and = repair. I assume a transition would require some form of signaling = indication that you support and want to do the new mode. But that is = discussion for the future how to solve that. >>=20 > Apart of having to implement and support two different modes of = operation, how would the endpoint know in which mode to operate? >=20 > I would prefer to answer that solutions now in order to ensure that we = have a complete solution that RTCWEB group could adopt in the future = without further discussions. I fear the answer for that is not within the charter of the PERC working = group. But once the PERC working group has chosen a solution for double = I would be happy to write a draft with you about signaling in SDP (or = other signaling protocols if desired/needed) which alternative of = encrypt->repair or repair->encrypt the endpoint support and/or prefers = and try to get it through the right working groups at IETF. Best Nils Ohlmeier --Apple-Mail=_D153E22E-C33B-49E2-B7FC-7312A7D24A3F 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAloONIUACgkQY2o/VmzJ +KGMDw//ZyPc0ah3oWrGIYDMzwjao7HhysAYjYxLxnP1sEZsXy47KZ7S5mCsOLBb Vt38d6lkqpp0Sjwfgt+TucpVp/WuYzyE0iXo1QWAmTcTK7iQSL66rNYkUMYVvy2M W9o82Lu+jXNF4BmajjGm1/ffyOgsn0BBgsalwPrb7IkVoX9RYjrkkjcVV0LZ4c9q cH5NridSbnsfInxalFtNjDU6N9WLtyY+1glYTtoI2ee7ypvb9by1byzLN6VGkGdk cEa2+T8JXMeeFQ++hpgSZwFyqIlrXFBegTyDawAa2StHkyce3S6EVBdVi43jIirV wn4aPTt2vK31WnjyeI6aEuhzAsUQxIRjlQMhgf5GJcww8JysuOkuKtClZQgBOJLF YXqk4GJZNo59GeMEulvWjLld4tMwhf7nHktPf9CfDEe3UfZGtaIT/eIRWYIs5dml jb8/tStFS65ANdDzarvwVsA4ibnQ+rWqF3jvl3zAgk/861m+/0bvb/el/nFWuPdo iC1nFm/1gvCu+6VjmjHzkj0xEV1taLjXxAzDqHFpnKOXqSxchEgvX/oMwLCpDIcr v5xBxROoYEXyLaDSCo/PJz03XppNpEHuItp415zGMFrMnQXc/Uya6ZQEil4XO2s3 C+RO+MOpCR9dME48nkYUdwRFSczKwqX7qtc79FEo0yj3Q5XFVv0= =nj6y -----END PGP SIGNATURE----- --Apple-Mail=_D153E22E-C33B-49E2-B7FC-7312A7D24A3F-- From nobody Thu Nov 16 17:42: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 78538127522 for ; Thu, 16 Nov 2017 17:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv-6CLK8jx2g for ; Thu, 16 Nov 2017 17:42:03 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45071272E1 for ; Thu, 16 Nov 2017 17:42:02 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 108so449284uaf.2 for ; Thu, 16 Nov 2017 17:42:02 -0800 (PST) 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=XzznXC4XSK0pX2e79HylqmRuIRJ85tDPzRcP9pHrXe4=; b=Sr69bLiB7N7k4JKhJK4aHmTRsHB6UCKYwOcpM0Ru4TPOORob/hBZKahZBIoDwTp+62 LfHthgEiVF/JMuD3SvvKaIr9N2ZuYhVZmGiNWfTtfecT3lXMQVKNCEe43jE4Iu9FuE2K 3jsmPVEwmP+KDNUMGVUJL+ywKBNlmAUURaCtPq1kHND2UGJOBY0lRuvHy0vsp76rzrzA 1Ij6iAWG18PlW6hIOa924h9BLMLzdIQRzes6oECrPL1VUNY9L0+4Og0J0OdrCiqj8fqF EVnYO6jcTgjCxGQAlGggH0b4FA1ZyYFWA3VprC4fThChwoGtEtvZLMe1FEcZxgrMdsqv pP/A== 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=XzznXC4XSK0pX2e79HylqmRuIRJ85tDPzRcP9pHrXe4=; b=IUSHytNFg0K7u+rsBICQHLc6BbonVNGq8AoyPb1WnSOr8iVZnMNbgFv0buMBl1hKj2 7FBXZIDs7CQvCx0u8KopBj6zpf73EdNArJmi1xEB1Kj2IPuL6XUPx49nqhlT8tcQymn5 /hsyk/CnUUzPtfG5rRNYruZtDfLGX+PSja0e1y5p3YykdUGy8FLXDGdCzJxO21MO5wC3 6MFualR0aN7CayxNZZ84gymT/HHDSwumqiO1R4j5+3a7mLF3aA/+hk8K9Ounwb97H2SA 4GMuv1aFPAb/uS9vf3seCYkJ303TD4/+KCnvHdeJpUcApBWqY4kwc1nOQFUrgnsbVfJ6 GQrA== X-Gm-Message-State: AJaThX6P3yeK5bcu7E8xVC1VJXmwejben2RBw8MsuTScvmuwe7hrIhy1 GEMIrVZ9a0AQDdNL+q4K6yT+q/koV8itIv6iGp8= X-Google-Smtp-Source: AGs4zMZZyJAxXGx0D4miHXkdsR0qB8FHN0eNZ0TVzvY86GZOMchAOJzTPMrVR6VDDl4fl/TPw2I9ecLh1w11p6ldUCU= X-Received: by 10.176.20.225 with SMTP id f30mr3386438uae.66.1510882921690; Thu, 16 Nov 2017 17:42:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 17:41:41 -0800 (PST) In-Reply-To: <18fd709d-3666-6963-e74d-aa24666921b3@gmail.com> References: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> <6B61D903-D3A1-43E2-8A84-BCCA1E901D4D@mozilla.com> <18fd709d-3666-6963-e74d-aa24666921b3@gmail.com> From: Bernard Aboba Date: Thu, 16 Nov 2017 17:41:41 -0800 Message-ID: To: Sergio Garcia Murillo Cc: Nils Ohlmeier , "perc@ietf.org" Content-Type: multipart/alternative; boundary="001a1145ab00d83a48055e23d775" Archived-At: Subject: Re: [Perc] Double implementation status 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, 17 Nov 2017 01:42:05 -0000 --001a1145ab00d83a48055e23d775 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sergio said: " Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate? " [BA] A more basic question is why there needs to be two modes of operation in the first place, when a single mode could be made to work and would be considerably simpler. " On Thu, Nov 16, 2017 at 2:59 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 16/11/2017 10:41, Nils Ohlmeier wrote: > > Hello Sergio, > > As an individual contributor. > > On Nov 15, 2017, at 23:40, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > In order to modify a current webrtc stack (libwebrtc for example) it woul= d > be needed to : > > - Implement double encryption in libsrtp > - Modifications to dtls to support tunneling negotiation and > extracting the key pair (I expect this to be fairly easy) > - Change all the libwrtc rtp stack to perform rtx/fec after srtp > encryption and use the repair mode for it > > As far as I know, there is a librtsp implementation for double made by > cisco, which will cover the double encryption part (https://github.com/ > bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are > important pieces missing in order to fully validate its implementation > viability. But the code available seems not to cover the repair_mode to b= e > able to apply only the HBH encryption to the RTX/FEC packets. > > I also feel that the last point is the key one, because the impact of > modification of the fec/rtx and srtp order can be huge. > > True. The changes needed here are quite substantial. > > But just to avoid people having the impression that PERC lite is easier t= o > implement: I think that depends a lot on your design, and in case of > Firefox it would also require major surgery. > > > Hi Nils, > > Could you elaborate? > > Adding the end to end encryption is just putting two lines of code in the > correct places in libwebrtc. Passing the key from js (which is out of the > scope of this wg) has been made substantially easy by having them as a > parameter in the setParameters for rtp senders/receivers. > > Where do you expect the problem to arise? > > Also, I think that it would be needed to know how it would be the > transition phase be handled when we will have "old" webrtc implementation= s > doing fec/rtx before srtp and "new" ones doing it in the opposite way. > > My assumption here is that the modifications to your webrtc implementatio= n > need to allow you to run it in either or mode. So that you can support > running calls in the =E2=80=9Cnew=E2=80=9D mode when doing PERC calls. Bu= t you can keep > running in the =E2=80=9Cold=E2=80=9D mode for non-PERC calls. > > Eventually there might be value in moving all calls over to the =E2=80=9C= new=E2=80=9D mode > where you always encrypt before caching and repair. I assume a transition > would require some form of signaling indication that you support and want > to do the new mode. But that is discussion for the future how to solve th= at. > > Apart of having to implement and support two different modes of operation= , > how would the endpoint know in which mode to operate? > > I would prefer to answer that solutions now in order to ensure that we > have a complete solution that RTCWEB group could adopt in the future > without further discussions. > > Best regards > Sergio > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a1145ab00d83a48055e23d775 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"
=
Apart of having to implement= and support two different modes of operation, how would the endpoint know = in which mode to operate? "

[BA] A more basic question is why there needs to be = two modes of operation in the first place, when a single mode could be made= to work and would be considerably simpler.
=
"

On Thu, Nov 16, 2017 at 2:59 AM, Sergio Garcia Muri= llo <sergio.garcia.murillo@gmail.com> wrote:
=20 =20 =20
On 16/11/2017 10:4= 1, Nils Ohlmeier wrote:
=20 Hello Sergio,

As an individual contributor.

On Nov 15, 2017, at 23:40, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

In order to modify a current webrtc stack (libwebrtc for example) it would be needed to :

  • Implement double encryption in libsrtp
  • Modifications to dtls to support tunneling negotiation and extracting the key pair (I expect this to be fairly easy)
  • Change all the libwrtc rtp stack to perform rtx/fec after srtp encryption and use the repair mode for it

As far as I know, there is a librtsp implementation for double made by cisco, which will cover the double encryption part=C2=A0 (https://github.com/= bifurcation/libsrtp/tree/ohb-in-payload), but we feel that there are important pieces missing in order to fully validate its implementation viability. But the code available seems not to cover the repair_mode to be able to apply only the HBH encryption to the RTX/FEC packets.

I also feel that the last point is the key one, because the impact of modification of the fec/rtx and srtp order can be huge.

True. The changes needed here are quite substantial.

But just to avoid people having the impression that PERC lite is easier to implement: I think that depends a lot on your design, and in case of Firefox it would also require major surgery.

 Hi Nils,

Could you elaborate?

Adding the end to end encryption is just putting two lines of code in the correct places in libwebrtc. Passing the key from js (which is out of the scope of this wg) has been made substantially easy by having them as a parameter in the setParameters=C2=A0 for rtp senders/receivers.

Where do you expect the problem to arise?

Also, I think that it would be needed to know how it would be the transition phase be handled when we will have "old" webrtc implementations = doing fec/rtx before srtp and "new" ones doing it in = the opposite way.

My assumption here is that the modifications to your webrtc implementation need to allow you to run it in either or mode. So that you can support running calls in the =E2=80=9Cnew=E2=80= =9D mode when doing PERC calls. But you can keep running in the =E2=80=9Cold=E2= =80=9D mode for non-PERC calls.

Eventually there might be value in moving all calls over to the =E2=80=9Cnew=E2=80=9D mode where you always encrypt before ca= ching and repair. I assume a transition would require some form of signaling indication that you support and want to do the new mode. But that is discussion for the future how to solve that.

Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate?

I would prefer to answer that solutions now in order to ensure that we have a complete solution that RTCWEB group could adopt in the future without further discussions.

Best regards
Sergio



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


--001a1145ab00d83a48055e23d775-- From nobody Fri Nov 17 01:23:03 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 784C4127868 for ; Fri, 17 Nov 2017 01:23:01 -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 JC2YSDuEBt5o for ; Fri, 17 Nov 2017 01:22:59 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8FF127241 for ; Fri, 17 Nov 2017 01:22:59 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id b189so4966404wmd.5 for ; Fri, 17 Nov 2017 01:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=FHEUipcy95/Hpt6AnX0BXNrdBMDoI214Ma3hMVcfRu4=; b=sINbou437Sa1psKniVzVb7sAeIGwKwmLhlXF0HwDGwBlBZHfdZ33SCk8veHaQZo9Gy iGpdHNnjnXCZ9TeSMSaLyijNqC+dDbCnW6I25B51oTymCw6jOIllO8/ThVUZXBmCjr08 zR2isgwK1u56suhL0BE6kgwi3eVFXCsDoxw9ZeGEed/FnNiJrPjiLr+sqi3SpIh4dRqu knpq3mG/rOUZXy6gMOMojgD2BhUEbbErG4vYAIiJRlNyh6NGgZC6s8tkiUE03bwCWWf7 AFtVjI41xYyDuoBA5ng2UDnpwXiamY0FwFMUylupVggUMOQE6CvfIIbFCiPBYelojYNF WjGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=FHEUipcy95/Hpt6AnX0BXNrdBMDoI214Ma3hMVcfRu4=; b=HhpqosFkm/l+jMPD5pgb+c0etyJF/Yyu+HTsTlgYn9ScO7WdqWolTSBX8qfHeT88IQ CEfNW1S0BIR7gJ2E62opYXiX2YM9KWRS052+Cz1FmZXlO8SwTdc+GvqOMKXp/eg+LEUI LHNWeqx5a/TAdNS8QPFgX3jALf3LjVXjzw88Yh67W5ksCG2YwmmrDQpTdiqC1t4V4rFZ f1VAT6rrFU87PG5FHlqSbrfmZHYAyZhWP1hS8iZwpQxG3iuXCgRtuj2q2lCwwpkiM6k6 d6NHuTXRf8DeqBAACLk3oyco7+QIaYYiirgEcutcBjJVVNtepHBnN+3scZvdL6Bh0GKq gcHg== X-Gm-Message-State: AJaThX58+69FaBjum2CJmt4uY3kO1/t/+zLfoVN63QPdvoHPuyBvNkzf jkZ3ZLowhnqSevInUDvdFXp8NaJr/i8= X-Google-Smtp-Source: AGs4zMbsb3XtnLXdDIhUeZIFPOap2FSFACBTXSSN2mgFmlGKA3QO3BEla9BA2uwgojdWPOr+7Ydzsg== X-Received: by 10.80.182.92 with SMTP id c28mr6631591ede.244.1510910577221; Fri, 17 Nov 2017 01:22:57 -0800 (PST) Received: from [192.168.1.66] ([178.139.1.69]) by smtp.googlemail.com with ESMTPSA id v15sm2257198edb.24.2017.11.17.01.22.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 01:22:56 -0800 (PST) To: Nils Ohlmeier Cc: "perc@ietf.org" References: <6c748b0b-4f8d-a2c8-645e-684dd5a67c52@gmail.com> <6B61D903-D3A1-43E2-8A84-BCCA1E901D4D@mozilla.com> <18fd709d-3666-6963-e74d-aa24666921b3@gmail.com> <0915A9C1-5515-402B-8CD7-08A65D59AA9A@mozilla.com> From: Sergio Garcia Murillo Message-ID: Date: Fri, 17 Nov 2017 10:22:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <0915A9C1-5515-402B-8CD7-08A65D59AA9A@mozilla.com> Content-Type: multipart/alternative; boundary="------------F291F80729F80624501F835C" Content-Language: en-US Archived-At: Subject: Re: [Perc] Double implementation status 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, 17 Nov 2017 09:23:01 -0000 This is a multi-part message in MIME format. --------------F291F80729F80624501F835C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit El 17/11/2017 2:04, "Nils Ohlmeier" > escribió: > On Nov 16, 2017, at 18:59, Sergio Garcia Murillo > wrote: > > On 16/11/2017 10:41, Nils Ohlmeier wrote: >> True. The changes needed here are quite substantial. >> >> But just to avoid people having the impression that PERC lite is easier to implement: I think that depends a lot on your design, and in case of Firefox it would also require major surgery. > > Hi Nils, > > Could you elaborate? > > Adding the end to end encryption is just putting two lines of code in the correct places in libwebrtc. Passing the key from js (which is out of the scope of this wg) has been made substantially easy by having them as a parameter in the setParameters  for rtp senders/receivers. > > Where do you expect the problem to arise? My point is that Firefox doesn't use the standard libwebrtc setup. It invokes libsrtp way outside the libwebrtc stack. Therefore any PERC solution will require major surgery. AFAIK Firefox doesn't support neither RTX nor FEC, so it should be fairly easy to add Lite. You don't need to change neither your ICE/DTLS, just place the inner crypto before calling your srtp code, or even inside your code. >> My assumption here is that the modifications to your webrtc implementation need to allow you to run it in either or mode. So that you can support running calls in the “new” mode when doing PERC calls. But you can keep running in the “old” mode for non-PERC calls. >> >> Eventually there might be value in moving all calls over to the “new” mode where you always encrypt before caching and repair. I assume a transition would require some form of signaling indication that you support and want to do the new mode. But that is discussion for the future how to solve that. >> > Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate? > > I would prefer to answer that solutions now in order to ensure that we have a complete solution that RTCWEB group could adopt in the future without further discussions. I fear the answer for that is not within the charter of the PERC working group. But once the PERC working group has chosen a solution for double I would be happy to write a draft with you about signaling in SDP (or other signaling protocols if desired/needed) which alternative of encrypt->repair or repair->encrypt the endpoint support and/or prefers and try to get it through the right working groups at IETF. Well, the fact is that I don't want to have to write any draft about signaling in SDP for PERC to work :) Best regards Sergio --------------F291F80729F80624501F835C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


El 17/11/2017 2:04, "Nils Ohlmeier" <nohlmeier@mozilla.com> escribió:


> On Nov 16, 2017, at 18:59, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
>
> On 16/11/2017 10:41, Nils Ohlmeier wrote:
>> True. The changes needed here are quite substantial.
>>
>> But just to avoid people having the impression that PERC lite is easier to implement: I think that depends a lot on your design, and in case of Firefox it would also require major surgery.
>
> Hi Nils,
>
> Could you elaborate?
>
> Adding the end to end encryption is just putting two lines of code in the correct places in libwebrtc. Passing the key from js (which is out of the scope of this wg) has been made substantially easy by having them as a parameter in the setParameters  for rtp senders/receivers.
>
> Where do you expect the problem to arise?

My point is that Firefox doesn't use the standard libwebrtc setup. It invokes libsrtp way outside the libwebrtc stack. Therefore any PERC solution will require major surgery.

AFAIK Firefox doesn't support neither RTX nor FEC, so it should be fairly easy to add Lite. You don't need to change neither your ICE/DTLS, just place the inner crypto before calling your srtp code, or even inside your code.


>> My assumption here is that the modifications to your webrtc implementation need to allow you to run it in either or mode. So that you can support running calls in the “new” mode when doing PERC calls. But you can keep running in the “old” mode for non-PERC calls.
>>
>> Eventually there might be value in moving all calls over to the “new” mode where you always encrypt before caching and repair. I assume a transition would require some form of signaling indication that you support and want to do the new mode. But that is discussion for the future how to solve that.
>>
> Apart of having to implement and support two different modes of operation, how would the endpoint know in which mode to operate?
>
> I would prefer to answer that solutions now in order to ensure that we have a complete solution that RTCWEB group could adopt in the future without further discussions.

I fear the answer for that is not within the charter of the PERC working group. But once the PERC working group has chosen a solution for double I would be happy to write a draft with you about signaling in SDP (or other signaling protocols if desired/needed) which alternative of encrypt->repair or repair->encrypt the endpoint support and/or prefers and try to get it through the right working groups at IETF.


Well, the fact is that I don't want to have to write any draft about signaling in SDP for PERC to work :)

Best regards
Sergio
--------------F291F80729F80624501F835C-- From nobody Fri Nov 17 03:39:40 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696F1126CBF for ; Fri, 17 Nov 2017 03:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU2GwNx3UKLp for ; Fri, 17 Nov 2017 03:39:37 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 8D39A12008A for ; Fri, 17 Nov 2017 03:39:37 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id d15so5197602qte.4 for ; Fri, 17 Nov 2017 03:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k2DbwIrLOdM13fZFvn20XzAqxmpkH1SfanrgFZ3Km4o=; b=1eRnKGCYip6+hmJ2b7ul4rCD7Eym/LpkNLWOb05hHA4h3iRkulGrscdqH3TDwieXJN gvAE5OtY0uwQwhcxWJCWIgfPJhKy63jrwpW+Cu1Jyra01uvjDuZKeqZ18+bzW1sj4lUE TZDAuHM+R+ZhqlHG1JQsrqpTsoZAgfzNuK6qmViTfA20EzcsU9d2Ot5eWjyK/gWJDxpD TjENQVd7aC9cAa4NN0iMHw8GoJOkK9ywfP/DedPLt8Jtkhq23dIe3xFq3KPXrO31YJAL SzbyA3epUyK4wb7WrCPSMiKPnxecg/ip84qatwEn97iBwEJVLFMfGnSzAG1dUnA2bGJ8 gl7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k2DbwIrLOdM13fZFvn20XzAqxmpkH1SfanrgFZ3Km4o=; b=mwId8EygkR6UlxQdf1lcrozAYA5/JtyhW+6lrcdJSSjZujqgzToSLCox+2rl0kXPQg gnT6TWMHJsBj7E83wzu8jykNc29WAxcaj8shn9t07Rl+SVTKFXgvruxg1YoGd9RZbkAO UFmtJk2Q3Q+JsTqGezdmDpYfpA0FGzYLoax9r0H0eJvv9F5IS1HkNm+T9ZHE1Zc5F3vY FoBmyGAiggNrvs7ruc3KT6W4khQx+4ATm6r2/JcUblTNgox4bx9zWVnTn3OUlF/j6sYB GuIwq8mGrWuzLS+9uo/KekY5NI4fhQUiAat396Z+i8jwMdhmpIUR0PBDQomKBsLz/vEQ QN0A== X-Gm-Message-State: AJaThX5hW2r7EuWJ6jQ2XpfqIRV+D+jrudGmXdh2nddrsJlte9aqvMj1 HIwc68L6mVN1N36hbteWR0zV+2weyOHcDIXsylEcDg== X-Google-Smtp-Source: AGs4zMaFiFDUWvugeLiLjgms+QcwjMvPsfFwFGApRzzH8zaBTad8bHKKfUlPnaD1q4yvLZ5FBkOG6ydtDt/p9fj61bg= X-Received: by 10.55.204.131 with SMTP id n3mr7486977qkl.234.1510918776684; Fri, 17 Nov 2017 03:39:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Emil Ivov Date: Fri, 17 Nov 2017 11:39:26 +0000 Message-ID: To: Suhas Nandakumar Cc: perc@ietf.org Content-Type: multipart/alternative; boundary="001a1147a580f81a15055e2c30f7" Archived-At: Subject: Re: [Perc] WGLC: draft-ietf-perc-srtp-ekt-diet-06 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, 17 Nov 2017 11:39:39 -0000 --001a1147a580f81a15055e2c30f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I sent this yesterday but apparently it only went to Suhas. Posting again to the list (as mentioned, I am not really hoping for an answer at this stage and I am mainly doing it for the record): Hello all, I am assuming this will be ignored just as the original complaints but for the sake of completeness: No, I do not feel this draft is ready to go and it won=E2=80=99t be until i= t gets rid of the requirement for doing triple encryption for repair mechanisms. I dont believe that there has ever been consensus on this in the WG despite Suhas=E2=80=99s insistance otherwise. Speaking as an implementor, we are unlikely to adopt PERC until this is solved. Emil On Tue 31 Oct 2017 at 20:37, Suhas Nandakumar wrote: > All, > > This is a working group last call announcement for draft-ietf-perc-srtp-e= kt-diet-06 to run through November 15. Please send your reviews to the lis= t as soon as possible so we can prepare for any discussion of open issues a= t IETF 100 in Singapore. > > > Thanks > > nils & suhas > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --=20 =E2=80=94sent from my mobile --001a1147a580f81a15055e2c30f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I sent this yesterday but apparently it only went to= Suhas. Posting again to the list (as mentioned, I am not really hoping for= an answer at this stage and I am mainly doing it for the record):

Hello all,

I am assuming this will be ignored just = as the original complaints but for the sake of completeness:

No,= I do not feel this draft is ready to go and it won=E2=80=99t be until it g= ets rid of the requirement for doing triple encryption for repair mechanism= s.
I dont believe that there has ever been consensus on this in t= he WG despite Suhas=E2=80=99s insistance otherwise.

Speaking as a= n implementor, we are unlikely to adopt=C2=A0PERC=C2=A0u= ntil this is solved.

Emil

On Tue 31 Oct 2017 at 20:37, Suhas Nandakumar <suhasietf@gmail.com> wrote:
All,
This is a =
working group last call announcement for draft-ietf-perc-srtp-ekt-diet-06 t=
o run through November 15.  Please send your reviews to the list as soon as=
 possible so we can prepare for any discussion of open issues at IETF 100 i=
n Singapore.

Thanks
nils & suhas
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--
=E2=80=94sent from my mobile<= /div> --001a1147a580f81a15055e2c30f7-- From nobody Fri Nov 17 05:08: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 996931270A3 for ; Fri, 17 Nov 2017 05:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Gqzz1hicF9 for ; Fri, 17 Nov 2017 05:08:34 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384ED127058 for ; Fri, 17 Nov 2017 05:08:34 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id p96so2061243wrb.7 for ; Fri, 17 Nov 2017 05:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FCn+dL4crhEnJ1wrBxzaOTgyVmwBZH0b3B1PleBGJvE=; b=gvyhn/xGTm8djL4kLkBcf8L49CN4YRtSraXUR/lYI4VrZPgCp/HJ7+vmxvoN7kxxWS 9QRPBLcnHwFsyNrOSDIEEdO99vI+XtsJ7+yaZJsCxCddqucMRzDXHmrrpjiFSobXvDP6 bbQnTpY8W2fCbrzPwxQxhumra00gL5UKxnR1qylIDWzyPMlqs6oiOd0TZYTrAhRDaA9x WMo4mBP/6KMrvkykl7niXCZR6y5ukcWQctO5bDJkEwbUhtSF/wDrZ4chbcUkbeM21Xqr 6+KWQPwL4M1i4vKHyVy7Bh26Ha0pjvHtsb9LuFLKVxDwCM8okp/tbIYerCenOKdgT711 ZPOw== 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; bh=FCn+dL4crhEnJ1wrBxzaOTgyVmwBZH0b3B1PleBGJvE=; b=TL7NrhHwOApjLscMOgCpQMAlRPg/2HOF5PCroTbjverDZ13jEnHeuFOtgTmvAGKhXr 4Bd7vpoyb32e+NvQ2fg7VGZp69hc7Z3y3y3mbmBOYOk1K6P7CU52hOK/nZJCrQl+HXOB GV6IOpVxUs3Q0mPkTz0kjvbsE2VmVDmFL1ONcWfVSCD6xTyOt9CPWUHVx1TKHmEmFkXE MVyGS4fw5bTc3V7P2X4W+yPkClqffOp7DTxovdS1q7nIuG1Wh7G/4oVSGHql3+BzAYUg mGMgvk1CnH9vchJ5oDMqTjrGM6ZVaIDorXQ4qWHzCE2Nuci/zX4f8a8lDoyLOO06msn6 HyiA== X-Gm-Message-State: AJaThX5bvC9292Rd8+NfvyXpWg+thhgjxXyukrsi80yipkN8+rPaZKXn AmYZzLTyC0DPnclLElpkXRy4HHuLoyWQobGIt3iTCQ== X-Google-Smtp-Source: AGs4zMYbDUURVD++ZYMhrXXjsEqqTmvsBP5XSQtaek72+ue4uE5rfIid7e4LTf3W/IJAMEa1Z7Xi77uO6nPN/+sHaRw= X-Received: by 10.223.169.100 with SMTP id u91mr4177068wrc.108.1510924112639; Fri, 17 Nov 2017 05:08:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Fri, 17 Nov 2017 05:08:32 -0800 (PST) Received: by 10.28.174.81 with HTTP; Fri, 17 Nov 2017 05:08:32 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Fri, 17 Nov 2017 21:08:32 +0800 Message-ID: To: Emil Ivov , perc@ietf.org Content-Type: multipart/alternative; boundary="f403045cf7ec045e3b055e2d6f1c" Archived-At: Subject: Re: [Perc] WGLC: draft-ietf-perc-srtp-ekt-diet-06 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, 17 Nov 2017 13:08:36 -0000 --f403045cf7ec045e3b055e2d6f1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Re-adding the list... On Nov 17, 2017 21:07, "Richard Barnes" wrote: Emil - Can you explain what this draft has to do with repair? EKT allows two DTLS-SRTP endpoints to establish a shared encryption key that is not directly bound to the DTLS handshake. It seems no more related to repair than DTLS-SRTP itself. On Nov 17, 2017 19:39, "Emil Ivov" wrote: > I sent this yesterday but apparently it only went to Suhas. Posting again > to the list (as mentioned, I am not really hoping for an answer at this > stage and I am mainly doing it for the record): > > Hello all, > > I am assuming this will be ignored just as the original complaints but fo= r > the sake of completeness: > > No, I do not feel this draft is ready to go and it won=E2=80=99t be until= it gets > rid of the requirement for doing triple encryption for repair mechanisms. > > I dont believe that there has ever been consensus on this in the WG > despite Suhas=E2=80=99s insistance otherwise. > > Speaking as an implementor, we are unlikely to adopt PERC until this is > solved. > > Emil > > On Tue 31 Oct 2017 at 20:37, Suhas Nandakumar wrote= : > >> All, >> >> This is a working group last call announcement for draft-ietf-perc-srtp-= ekt-diet-06 to run through November 15. Please send your reviews to the li= st as soon as possible so we can prepare for any discussion of open issues = at IETF 100 in Singapore. >> >> >> Thanks >> >> nils & suhas >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > -- > =E2=80=94sent from my mobile > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --f403045cf7ec045e3b055e2d6f1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re-adding the list...
=
On Nov 17, 2017 21:07, "Richard Barnes&= quot; <rlb@ipv.sx> wrote:
Emil - Can you explain what this draft has to do = with repair?=C2=A0=C2=A0

EKT a= llows two DTLS-SRTP endpoints to establish a shared encryption key that is = not directly bound to the DTLS handshake.=C2=A0 It seems no more related to= repair than DTLS-SRTP itself.=C2=A0
=

On Nov 17, 2017 1= 9:39, "Emil Ivov" <emcho@jitsi.org> wrote:
I sent this yesterday but app= arently it only went to Suhas. Posting again to the list (as mentioned, I a= m not really hoping for an answer at this stage and I am mainly doing it fo= r the record):

Hello all= ,

I am assuming thi= s will be ignored just as the original complaints but for the sake of compl= eteness:

No, I do not feel this draft is ready to go and it won= =E2=80=99t be until it gets rid of the requirement for doing triple encrypt= ion for repair mechanisms.

I dont believe that there has ever bee= n consensus on this in the WG despite Suhas=E2=80=99s insistance otherwise.=

=
Speaking as an implementor, we are unlikely to adopt=C2=A0PERC=C2=A0until thi= s is solved.

Emil

= On Tue 31 Oct 2017 at 20:37, Suhas Nandakumar <suhasietf@gmail.com> wrote:
All,
This is a working group last call announcement for draft-ietf-pe=
rc-srtp-ekt-diet-06 to run through November 15.  Please send your revi=
ews to the list as soon as possible so we can prepare for any discussion of=
 open issues at IETF 100 in Singapore.

Thanks
nils & suhas
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--
=E2=80=94sent from my mobile

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


--f403045cf7ec045e3b055e2d6f1c-- From nobody Fri Nov 17 05:10: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 C49C3127058 for ; Fri, 17 Nov 2017 05:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqkKjcxhNz3s for ; Fri, 17 Nov 2017 05:10:48 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 3DD74126CB6 for ; Fri, 17 Nov 2017 05:10:48 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id n61so5764559qte.10 for ; Fri, 17 Nov 2017 05:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5Oh/DFfkEtjw3gm+fjScggcgL6YB2qwruoUZeXLa5MA=; b=X5+XmZB3RU5vktTc8b7T6jchbfNW6NhJooXcJTOEsEKAI+WwOrfY1hdqH0XP4eZGmQ sFTrT6Q8eAriAQCgYHbO+ytTt7om3lD1sSk7H8DxQgXP12dioeocK1TPVFLTuil1holK Ro4ROecT2lJeHuzK2Rqg97Aa7PnvrT1NpV/gciBoiNvMDwRAWl4lwybeMpgZEc0c9NB9 lwQ8U5MDv+/w9O9Y81V7U334dj0nJjYQ928YtCeu05ETy+BN+PkcrLKL6JtiIP07S46g rhEtJRhkwiZs69RqEK9Jpozvk+533knvlEc9F4k1wVLqiPW11HOy8qAwMkW5aDILk60H Rl6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5Oh/DFfkEtjw3gm+fjScggcgL6YB2qwruoUZeXLa5MA=; b=G9ghnCtBrUYfxCqLOq/uRVDdDqOxbRv9KWsY3rIKm8AuG/JD3L9K31mrRaIjgKCGh5 ybnbuqgkAQOxcI75pgrUAuvjZR7e7MidyXK16nYhS1l/KS/fU5G3Q4IXgeSLt0SkXfTr kejwoomtYndy4Fe4tiipFjL9IBLiGGrp2qnkf68t2NR8OxdXgWvYrvmlGaNT9fjVGiwW /n0EkIBLKaszqtnZi+E7g6i9GHWZdB1gu6rWUm74wzwMwGoiWgxh0w8tIJ/7p2NR9F0d iE8ClnhbkTNXM9EdZmteIUTRjKpipuZUwRrrNOhk2ssC9M7ymZ8wGvt4dVnUNtQE0mgH HO2Q== X-Gm-Message-State: AJaThX7R5q6Vk9MP9S2aOuuLDG9ZLdfiv8NKqQ1u/FIMCi0agMIl39nv Q5VICQ5MNz1/bg/n428cL52kh/d0vgx2S+/sahRJvA== X-Google-Smtp-Source: AGs4zMYEIkYDgNm/Sir+Ar/KShqq32qS+b8fEizNQzUcUt/ysN+dafq/mFoswpJjtUP2rZz3SzcG+q6BmNdl+SaFI4g= X-Received: by 10.55.80.214 with SMTP id e205mr1315334qkb.44.1510924247253; Fri, 17 Nov 2017 05:10:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Emil Ivov Date: Fri, 17 Nov 2017 13:10:36 +0000 Message-ID: To: Suhas Nandakumar Cc: perc@ietf.org Content-Type: multipart/alternative; boundary="001a114a7f8a0a632a055e2d7702" Archived-At: Subject: Re: [Perc] WGLC: draft-ietf-perc-srtp-ekt-diet-06 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, 17 Nov 2017 13:10:51 -0000 --001a114a7f8a0a632a055e2d7702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops sorry, this was an oversight on my behalf! (Thanks Richard for pointing it out to me!) I confused the mails about double with the WGLC on ekt-diet. My mail was intended for double only Appologies for the confusion! Emil On Fri 17 Nov 2017 at 05:39, Emil Ivov wrote: > I sent this yesterday but apparently it only went to Suhas. Posting again > to the list (as mentioned, I am not really hoping for an answer at this > stage and I am mainly doing it for the record): > > Hello all, > > I am assuming this will be ignored just as the original complaints but fo= r > the sake of completeness: > > No, I do not feel this draft is ready to go and it won=E2=80=99t be until= it gets > rid of the requirement for doing triple encryption for repair mechanisms. > > I dont believe that there has ever been consensus on this in the WG > despite Suhas=E2=80=99s insistance otherwise. > > Speaking as an implementor, we are unlikely to adopt PERC until this is > solved. > > Emil > > On Tue 31 Oct 2017 at 20:37, Suhas Nandakumar wrote= : > >> All, >> >> This is a working group last call announcement for draft-ietf-perc-srtp-= ekt-diet-06 to run through November 15. Please send your reviews to the li= st as soon as possible so we can prepare for any discussion of open issues = at IETF 100 in Singapore. >> >> >> Thanks >> >> nils & suhas >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > -- > =E2=80=94sent from my mobile > --=20 =E2=80=94sent from my mobile --001a114a7f8a0a632a055e2d7702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops sorry, this was an oversight on my behalf!

(Thanks Richard for pointing= it out to me!)

I confus= ed the mails about double with the WGLC on ekt-diet.

My mail was intended for double only

Appologies for the confusion!

Emil
On Fri 17 Nov 2017 at 05:39, Emil Ivov <emcho@jitsi.org> wrote:
I sent this yesterday but apparently i= t only went to Suhas. Posting again to the list (as mentioned, I am not rea= lly hoping for an answer at this stage and I am mainly doing it for the rec= ord):

Hello all,

I am assuming t= his will be ignored just as the original complaints but for the sake of com= pleteness:

No, I do not feel this draft is ready to go and it won= =E2=80=99t be until it gets rid of the requirement for doing triple encrypt= ion for repair mechanisms.

I dont believe that there has ever bee= n consensus on this in the WG despite Suhas=E2=80=99s insistance otherwise.=

=
Speaking as an implementor, we are unlikely to adopt=C2=A0PERC=C2=A0until this is solved.

Emil

On Tue 31 = Oct 2017 at 20:37, Suhas Nandakumar <suhasietf@gmail.com> wrote:
All,
This is a working group last call announcement for draft-ietf-perc-sr=
tp-ekt-diet-06 to run through November 15.  Please send your reviews to the=
 list as soon as possible so we can prepare for any discussion of open issu=
es at IETF 100 in Singapore.
<=
br>
Thanks
nils & suhas
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--
=E2=80=94sent from = my mobile
--
=E2=80=94sent = from my mobile
--001a114a7f8a0a632a055e2d7702-- From nobody Fri Nov 17 18:28:02 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91189120721 for ; Fri, 17 Nov 2017 18:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ccX1RnVoUun for ; Fri, 17 Nov 2017 18:28:00 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42251200C5 for ; Fri, 17 Nov 2017 18:27:59 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id x63so9644049wmf.2 for ; Fri, 17 Nov 2017 18:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ef0H4I03ALRV5kjR0FP1fl1h/8I8Oxd6ATnWd2x61GQ=; b=ehVGm2Tdowh3D6QWdsjIBcxPfQ7cwwa6mnXq3O4Ap1v8n7GsBinEJRSGDUe9GzbLpy B13ze+f78+2sjl6IayeeLB1Vvzp+bNUmNm3v3iuGgW0uREE2Y4aX30IZ7Lh71UPF5T/O DDkS96xI6utha6Kh4cei5l5kJkP4r0XtHQV83gDp/zVWnFv190GAOSGDJY221nsDpmBx HroUPNOncgqz7KObtbMWiiBhmSTShu7jlolGkwMZ2ubbtxxcruGWbnVfPAcrED5LyDC0 V3eNCNCQF+HrQF9HErOoohMPeeywgrb1K8dxYPqMb4OhEpG+h7R94sxXKeEQtKcAqXFT 9gOg== 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=ef0H4I03ALRV5kjR0FP1fl1h/8I8Oxd6ATnWd2x61GQ=; b=k/0rnxIUhuxhx5SQ/RPqYtI9tAhYKd4zlIMBRsWafSR1q4sb6dDcOndRIbv0wPX8DN 6CZh03WxhBZhTTRJC8a6pkrRr247cFCnkp4a7HvdIV6i318zh67QPfabX+MTQw2jnk/m Yne1dVWeMyvO3sn5mVWvmBSXQFoaVDhFvykzZ5zy80MOgyUmXn8IVgG73GHJJsE336m7 3SI9UXOXxWvWwoO0YCETQb/bk6MJwaSg8UxnFj88bF2e41Td4xr+vUKDvecAjPOqYVpJ NRP7Je04+Ktn/rpzdbKpGVCX8Rz3+SsDJFO8ynfdP6sfjZZmKDKLBzhMgqn25s2MMjfH JkUg== X-Gm-Message-State: AJaThX5K1rma5vmjQzNLoML1ioERKbHE7yPsMwakMOJxZ85hH9y6iHZ6 htGfza9lzBwEBN0drsuwLdatKrAgSl2ZLpjSiFAukvgkYPY= X-Google-Smtp-Source: AGs4zMYy1vcKW+e7zb3dksDVO9J+5kSKQmXovpZE6UmpkjmqLsJqK6BHa9J6bccjx6a/vH6+qEBxzl5cRsvP9GO2d+g= X-Received: by 10.28.183.132 with SMTP id h126mr5516787wmf.17.1510972077894; Fri, 17 Nov 2017 18:27:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.92.141 with HTTP; Fri, 17 Nov 2017 18:27:57 -0800 (PST) From: Richard Barnes Date: Sat, 18 Nov 2017 10:27:57 +0800 Message-ID: To: perc@ietf.org, Jonathan Lennox Content-Type: multipart/alternative; boundary="001a1148f4a6f80175055e3899d4" Archived-At: Subject: [Perc] EKT role negotiation 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, 18 Nov 2017 02:28:01 -0000 --001a1148f4a6f80175055e3899d4 Content-Type: text/plain; charset="UTF-8" Hey PERC folks, In response to Jonathan's comments at the PERC meeting, I put together a PR that decouples EKT roles (who sends the EKTKey) from DTLS roles, using the same methodology as in RFC 4145. https://github.com/ietf/perc-wg/pull/148 This complicates EKT a little, but it doesn't seem tragic. Interested in what other folks think. --Richard --001a1148f4a6f80175055e3899d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey PERC folks,

In response = to Jonathan's comments at the PERC meeting, I put together a PR that de= couples EKT roles (who sends the EKTKey) from DTLS roles, using the same me= thodology as in RFC 4145.

https://github.com/ietf/perc-wg/pull/148

This complicates EKT a little, but it doesn't s= eem tragic.=C2=A0 Interested in what other folks think.

--Richard
--001a1148f4a6f80175055e3899d4-- From nobody Fri Nov 17 20:51: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 1337312711A for ; Fri, 17 Nov 2017 20:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpy6YSDQN1pF for ; Fri, 17 Nov 2017 20:51:52 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 D6C24126D73 for ; Fri, 17 Nov 2017 20:51:52 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id j16so3427136pgn.9 for ; Fri, 17 Nov 2017 20:51:52 -0800 (PST) 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=stV2uLx75QvUyC+4mYi1+wil5PLpllI0Mxj2o+9kClo=; b=IModvN+XVlMM29Hq8pGCo9UUMrdTOHzUHAgk5ha2HdlpxxSliOeFSI7grb3QdtyvRf n8Qrj8/2b4/jSonJyB3oj+xu1KPRUPYfc0N16sSjg7W3NOw78fqQor5unP3WQDRFS16F ZYJvo49lFMtGp6v0ws7frdXIRWu6To04oQtBw= 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=stV2uLx75QvUyC+4mYi1+wil5PLpllI0Mxj2o+9kClo=; b=cbmw+A/TnzO4K079g3aXwnTznv1N6niqPTHhaHerF/ioifpcvZlYW2VV/X9matCqk4 olUvctDBtDBWIcfrgtv7HCoh5grqlfnsR6UyOv2ntav8VT2TJRHgGYX/YwxZj8NZTC9E 9JNpaeDaL0u8j2+qrXwol3NBlVOt5A8+NG2jF4PZqKotrMB3vItsxzvJRIUxqNppa7uH OCVbhMYL1VJES6sp6NngHF37+aB5JvVJkMgwWyu2WbHG5f3PORKS7c7mxGIcRZTBPqt0 jmgaXpHmyiY+lXlW03xd0+ULzbCfJ1dWaF4SPFktbsKX0u0ygaCXsXIUhF8Aok+C11Qo Kf4g== X-Gm-Message-State: AJaThX6/NgVWcY3wbwNp8vFrH0AH8jCUhrXyjZYb6/DtefVvJ5xyEfL2 1IviYqGcPAW8NJziTdIK5MoCpg== X-Google-Smtp-Source: AGs4zMbweM9PDGJwcHPcPmZju+9ocGeI4dsZPpLHaCLvqb/uMIAJzthvFv/EIiRvkGLJoGeYkFfCVw== X-Received: by 10.84.217.2 with SMTP id o2mr7005923pli.338.1510980711838; Fri, 17 Nov 2017 20:51:51 -0800 (PST) Received: from [172.19.248.76] ([38.98.37.142]) by smtp.gmail.com with ESMTPSA id a87sm9858552pfg.159.2017.11.17.20.51.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 20:51:50 -0800 (PST) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B29CF2C4-A4DC-4010-A57C-5893D4A91043"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Sat, 18 Nov 2017 12:51:12 +0800 In-Reply-To: Cc: perc@ietf.org, Jonathan Lennox To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Perc] EKT role negotiation 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, 18 Nov 2017 04:51:55 -0000 --Apple-Mail=_B29CF2C4-A4DC-4010-A57C-5893D4A91043 Content-Type: multipart/alternative; boundary="Apple-Mail=_E48D7B23-5839-42F5-B27B-556F6825067F" --Apple-Mail=_E48D7B23-5839-42F5-B27B-556F6825067F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, > On Nov 18, 2017, at 10:27, Richard Barnes wrote: >=20 > In response to Jonathan's comments at the PERC meeting, I put together = a PR that decouples EKT roles (who sends the EKTKey) from DTLS roles, = using the same methodology as in RFC 4145. >=20 > https://github.com/ietf/perc-wg/pull/148 = >=20 > This complicates EKT a little, but it doesn't seem tragic. Interested = in what other folks think. I think it makes sense to decouple the EKT role from the DTLS role, = because without it I would be concerned that one day someone comes up = with a scenario where he/she needs to operate with unusual roles and = then can=E2=80=99t get the KD to actually distribute the keys. Thanks Nils Ohlmeier - as an individual contributor --Apple-Mail=_E48D7B23-5839-42F5-B27B-556F6825067F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

On Nov 18, 2017, at 10:27, = Richard Barnes <rlb@ipv.sx> wrote:

In response to Jonathan's comments at the = PERC meeting, I put together a PR that decouples EKT roles (who sends = the EKTKey) from DTLS roles, using the same methodology as in RFC = 4145.

https://github.com/ietf/perc-wg/pull/148

This complicates EKT a = little, but it doesn't seem tragic.  Interested in what other folks = think.

I think = it makes sense to decouple the EKT role from the DTLS role, because = without it I would be concerned that one day someone comes up with a = scenario where he/she needs to operate with unusual roles and then = can=E2=80=99t get the KD to actually distribute the keys.

Thanks
  Nils Ohlmeier - as an = individual contributor


= --Apple-Mail=_E48D7B23-5839-42F5-B27B-556F6825067F-- --Apple-Mail=_B29CF2C4-A4DC-4010-A57C-5893D4A91043 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----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAloPvEAACgkQY2o/VmzJ +KFFKA//cyoPPQ4G6MA0vqIwQc0/0yaWZhILqVzsNb2f1m/6FsP8xE9o6sWHu/M+ FGmeR6Wo8t+kAZ473yhRID+p9cxuU2mUbXAkBGVYu2A9Ns5RTofrVRE4ermmv5oc aS8gwkMqc0UOq4OunA/POYvz643faLJV180zp2kixWZ7BXSEfrMWWUs2SnQC7wu1 7t6ZaPQmR3tQ1ZFHX57ms5jtdnPSEBGB7PMMzPFOATwI/Cq6qA7soU36GUuwwiDI +luukIyy70tkGuQJvmE6vvT8Rht+fN/uLcmqn1HdkpVGKSqaczZ7aZq3OEVw/PXU UBcigGlxQohqlLUXyKnLzFa4RPTXzFAavyrOsfrZ8GKwkebX5aPS1hIkVColQwLv 4U8reLkVC6//3B0NMYHjQUGMIhkfmLuh82dMNCkjGjGPrM4jrYP+GEovwoUgPa++ Nv0yJY/A3ODsJdRfJHn5TQqqdZilfIFqBTYUN4kmqWkZYw8POuNtWL4/ULaqgVhv YcIEfA+Rk5YIVMXMBoGHtBIMP4EOq6Lq1ZNAGPzy15789v1oOMLIHTOeVAjzXWcf IMxB2yXwKB2O+Q/mszRu7NhzdBjqW87ScvwGdJzDBdBEiN5MNt9CxeBpSe2xVV5c McMDORoAtwGZYPp7+gjTm69UMVVpg/naQcx/u8NP+l9+NKoMuI0= =8akZ -----END PGP SIGNATURE----- --Apple-Mail=_B29CF2C4-A4DC-4010-A57C-5893D4A91043--