From nobody Fri Nov 1 13:06:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D69B120907 for ; Fri, 1 Nov 2019 13:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gaw5dzAlA1u for ; Fri, 1 Nov 2019 13:06:34 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 EE09D12008A for ; Fri, 1 Nov 2019 13:06:33 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id n16so9216159oig.2 for ; Fri, 01 Nov 2019 13:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=UR/b6DHplhsguZtMyneAME/LNlf4Iu8WKwkNlgv92ho=; b=eqXs6DpZvBjULXp6MkNgzYtbHVOLcqaX9RDCFGblmMvWsssqU8in7uW+U4XxrKYaSW JkRNNMZWoYemJGSwW4Ep0TSNX+qipcIp0GTneP+4wbJSTJYb1qrZsUu46qF3AAtGfASf 0M+Es6Q5/64v370aXm97QIF21XoxUw0OSecOfh6evHZop4F3KInoBkvVY0WUgfIgX39D ohseIyR7AWi0PdwhQ8nWysbgNBD8B3gCUIwCawfZsFte5n/aAQNIaOUbNkxXUIwrw3ex sjTlXdFoKnwm7UxRMZ3Idpv6wk71Zs1FWm11vtOULUhPEJSAqoDE7nd2FdVVx80VQuVW rXOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=UR/b6DHplhsguZtMyneAME/LNlf4Iu8WKwkNlgv92ho=; b=T5/rewRRsHqpLwlKjVUhwppHAG849dy8xAjtQ60WmIEqFcsge53WCJISApGERyOSuv BzgdePFC39JyQvKeKMaO+BsX/tN5+buXKiit2X6REtDJuzPr0cvUZhUKoqvhzleucJxt ipGYImbn3RKhBrZ3YMDcCFUJPBU++WgiH126UuD8wyMSpj8iSI0UeLLKrc8whinwTuJf IN+bEQzyOiZ9v7D2UQgmxZNEh74CoMtJchTWuPAw/LaV4Y4RZyLt6ZTRyTIOe1ksB7iu hXzrN4TJrIXhDZng0lliEQ70GFAaf75RSJztV5S7czA0HhOhnmjGLlooMep5o7sqeN8G PU1g== X-Gm-Message-State: APjAAAWNysK/B92Zj50ROkkcUvOoviQMfI1edjZnhDRlTry4OURgbmIo qXa+6PxhIfzl8hUdrKm3dsu6DhIRcehdVpRdmhHSfw== X-Google-Smtp-Source: APXvYqw3xGNSRfs50Yxf1XU7crCgvN1oTNVuCBygAKBl0f7wJzjtZMh6bkusE+5CIq4BsYmS1GMrBup8sKAiLTBph5o= X-Received: by 2002:aca:df41:: with SMTP id w62mr1977655oig.90.1572638793019; Fri, 01 Nov 2019 13:06:33 -0700 (PDT) MIME-Version: 1.0 From: Qingsi Wang Date: Fri, 1 Nov 2019 13:06:22 -0700 Message-ID: To: mmusic@ietf.org Cc: rtcweb@ietf.org, Alex Drake , Justin Uberti Content-Type: multipart/alternative; boundary="0000000000009ea01e05964e80da" Archived-At: Subject: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 20:06:36 -0000 --0000000000009ea01e05964e80da Content-Type: text/plain; charset="UTF-8" Greetings. This draft ( https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) proposes a complementary solution to the mDNS candidate detailed in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in this proposal, and it aims to address the connectivity challenge from the mDNS technique in these managed environments. The current work on this draft is tracked in https://github.com/tQsW/encrypted-ice-candidates. Regards, Qingsi --0000000000009ea01e05964e80da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings.

This draft (https= ://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) p= roposes a complementary solution to the mDNS candidate detailed in=C2=A0dra= ft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. IPs = of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in thi= s proposal, and it aims to address the connectivity challenge from the mDNS= technique in these managed environments. The current work on this draft is= tracked in=C2=A0https://github.com/tQsW/encrypted-ice-candidates.<= /div>

Regards,
Qingsi
--0000000000009ea01e05964e80da-- From nobody Sun Nov 3 19:36:17 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0621200FD; Sun, 3 Nov 2019 19:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=TO8IqNYM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XWdkR2Wc 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 lIh010t7AuOT; Sun, 3 Nov 2019 19:36:13 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2151D120121; Sun, 3 Nov 2019 19:36:13 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BE8E421B2C; Sun, 3 Nov 2019 22:36:11 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 03 Nov 2019 22:36:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=yT/4DlU4q98BCjjQ7bxVDZczlxqq dLPgtYcyAK1sfCo=; b=TO8IqNYMq38AVHUEK7b5+N7pSumIJlTw5LKnlDdHj1p6 WMqHoSH9b6wlejFocmd+Rwb1KCA8jBeU9mgDX2ehjs4YOqAv7NuD91m6UxtiG9t+ XgrvAKXp5y4j3uS97mO9s8DrVsfPDmTvWolzkRZvNo8tpyXNcnOIc6elIkMIJRI6 XXjHXmFpL2kkyeeBgtNEMic2i67Z4QT9UeF8LEdLz4C/cB+5Xbt0gxRFvlWbewe+ Z1HGAZVYF/+ihIkI6sPGXGAdH3ClfH4OI8acf9jA8/KIoijMPx3dAtVad9eT/t96 wK7OxXp/bd71RmX6iq12o0u66cDEu/qmYuL1ijUYvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yT/4Dl U4q98BCjjQ7bxVDZczlxqqdLPgtYcyAK1sfCo=; b=XWdkR2Wc1K/JVfcOTU9hBy aBlKciB6sitK4twQPKQs8bGQCjXH+FVkDFJwxTLwFWIxq1CHBWyLCPBTIIyvSDfK ZIVQ73d6XchLGiPNmFGL7D6GOZEUvYbCmJJYKD8ZuyDU5OrEieoQ5187TfR/CgKP +tFM6AzFCQFApG/G0cNFZCSyOXR+3TWSAkJ0FDEXumwh8VR86qcSxyFM1wUg9nq2 JXocH3HtCxkSo+E+x/3RpLUc5gsY1hl/hW8w3DpP24/rOEo1FaNjnUBmBLZO4riY t3syGqUY5FZnkFP8PVnjXYx8xxIX+c16JLjY9NvgyHTMUNilmzcim0Vee+6C4/Xw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 36E78E00A5; Sun, 3 Nov 2019 22:36:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 04 Nov 2019 14:35:51 +1100 From: "Martin Thomson" To: "Qingsi Wang" , mmusic Cc: "Alex Drake" , rtcweb@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [rtcweb] =?utf-8?q?=5BMMUSIC=5D_Draft_new=3A_draft-wang-mmusic-e?= =?utf-8?q?ncrypted-ice-candidates?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 03:36:15 -0000 This draft has the effect of defining a new gTLD. That's problematic, and likely unnecessary. I would encourage you to look into ways to signal these candidates differently. a=encrypted-candidate might work, for instance. You might be able to encrypt more data than an IP address in the process. I also don't see how key management works here. The goal of the draft is to define a set of entities that you are OK with reading your IP address, but I don't see any text that addresses the difficulty of a) identifying the entities in that set, and b) getting those entities the necessary keys. Those are the really hard problems in this space. I don't see how this provides any sort of algorithm agility or ability to identify the keys that are in use. Maybe trial decryption is acceptable in this context, but that can get unwieldy fairly rapidly. On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote: > Greetings. > > This draft > (https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) proposes a complementary solution to the mDNS candidate detailed in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in this proposal, and it aims to address the connectivity challenge from the mDNS technique in these managed environments. The current work on this draft is tracked in https://github.com/tQsW/encrypted-ice-candidates. > > Regards, > Qingsi > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Nov 5 11:15:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E539D120A15 for ; Tue, 5 Nov 2019 11:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBAD1eCdL9JF for ; Tue, 5 Nov 2019 11:15:30 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 B501B120A00 for ; Tue, 5 Nov 2019 11:15:30 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id m15so9868321otq.7 for ; Tue, 05 Nov 2019 11:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wXixCTnBK1S/W6+rTXf/XE+vR4OKvXBeDN7blCiJovE=; b=PiMJHoBHGj6uD/8ufYSYIiIcZz8wrU7GhscJiqdsey8corS/YvwCT47C7iQJe1P8bb +A8bgeB4kNYrCYOE7CtorV8r34W8qumzj2VqZjYlfCmsf6f+ByvoaPxTPWj2gcJNV5Si +3MmuN1UxnxHaVmpkTQD+DIGPlM31g/Xg1AkR6XPqI283j+VouzSXvqIcS9fp++qFyFo lmt6/BO9xXWErboQsk8F4kaigFbL56YLWhvingWNF2mKXn3vCaKV6bDcPkiqxcNYmrEk I3JkOjWE25ALdWWWuUxZ2sRcz9jytlsO0f7zN1GFVswZjcLyU7gYn4oaXKlPc8O4R11y ed9g== 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=wXixCTnBK1S/W6+rTXf/XE+vR4OKvXBeDN7blCiJovE=; b=qNyg2yItKVqgHY5hElrxQ4SHw+bqUjt6I8vV+4BHuaqBwTJxOaCjie1UMgBC2TS7SF wtgQ6Q9kE8g5rHGLzcyNabIrXwp/nK6yyl/sWfvY0LKv138wk8W4bYYPFV2KyaVy66eV nTtAn1llL1o3t48g/e3SNeCFiq2W1MmhK2qNvxI0cyWpgSCpU7CC7MsghGqLq12JfUWA 3K1n8krktT9jZKBUEHQimNwQwVYtYdyunzYF7NT7R+aYxdK6FKVzyuuiVwzusU8Lizc/ 47H4WPjAWrHnXor8HI1wJyJFTW9Us6Ean2O8GcUKcb7Dc/P+Jl7FuVhR0DApP1swTT64 tBOA== X-Gm-Message-State: APjAAAXKHJQVWWPMPAsKxTYfEXagvzUpWPLfOxPUE0jiwlN7dlzjWxqn L2eEx1cuVj6TDs/5Erm1sJY8IW690aFsmxqAVujaf+VXXpE= X-Google-Smtp-Source: APXvYqz8WoiKVwKW1pQJkp8/zvZExiwbUsAOyuyml4RiWH9efFydvO8iBbi/DxgtDi9UHc+rwyjM1mVVjdNw53EwKvs= X-Received: by 2002:a9d:52a:: with SMTP id 39mr22944092otw.133.1572981329694; Tue, 05 Nov 2019 11:15:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Qingsi Wang Date: Tue, 5 Nov 2019 11:15:18 -0800 Message-ID: To: Martin Thomson Cc: mmusic , Alex Drake , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="0000000000006592c205969e416b" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 19:15:33 -0000 --0000000000006592c205969e416b Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks a lot for the feedback. We agree a=encrypted-candidate should be able to achieve an equivalent result as this initial version or even beyond encrypting IPs, without modifying the core procedure. We'll edit the draft accordingly with this suggestion. On the key management, we think this should be deferred to implementations, given different options to solve this problem. Chrome enterprise policy is currently an example for such a solution in managed environments, and it allows admins to push configuration settings to managed endpoints. For example, policies like AudioCaptureAllowedUrls can set up a whitelist and DeviceKerborosEncryptionTypes configures certain ciphersuites. DHCP could be another example of configuring managed endpoints in addition to Chrome enterprise policy above. TLS-PSK similarly delegates the communication of PSK among parties outside the spec space. Given the diversity of applications even in managed environments, the definition of the key management feels out of the scope for this document, but this draft can include example implementations for illustration. As for errors from key rotation, MAC verification will cause such candidates to be discarded, and clients will fall back to mDNS, STUN, or TURN as appropriate. If we feel like that we need to solve this problem more thoroughly, some implementation guidelines can also be included regarding maintaining a brief key history and using trial decryption as needed. We'd appreciate suggestions on further improving these guidelines. Regards, Qingsi On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson wrote: > This draft has the effect of defining a new gTLD. That's problematic, and > likely unnecessary. I would encourage you to look into ways to signal > these candidates differently. a=encrypted-candidate might work, for > instance. You might be able to encrypt more data than an IP address in the > process. > > I also don't see how key management works here. The goal of the draft is > to define a set of entities that you are OK with reading your IP address, > but I don't see any text that addresses the difficulty of a) identifying > the entities in that set, and b) getting those entities the necessary > keys. Those are the really hard problems in this space. > > I don't see how this provides any sort of algorithm agility or ability to > identify the keys that are in use. Maybe trial decryption is acceptable in > this context, but that can get unwieldy fairly rapidly. > > On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote: > > Greetings. > > > > This draft > > ( > https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) > proposes a complementary solution to the mDNS candidate detailed in > draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. > IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in > this proposal, and it aims to address the connectivity challenge from the > mDNS technique in these managed environments. The current work on this > draft is tracked in https://github.com/tQsW/encrypted-ice-candidates. > > > > Regards, > > Qingsi > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --0000000000006592c205969e416b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

= Thanks a lot for the feedback. We agree a=3Dencrypted-candidate should be a= ble to achieve an equivalent result as this initial version or even beyond = encrypting IPs, without modifying the core procedure. We'll edit the dr= aft accordingly with this suggestion.=C2=A0

On the key management,= we think this should be deferred to implementations, given different optio= ns to solve this problem. Chrome enterprise policy is currently an example = for such a solution in managed environments, and it allows admins to push c= onfiguration settings to managed endpoints. For example, policies like=C2= =A0AudioCaptureAllowedUrls=C2=A0can set up = a whitelist and=C2=A0DeviceKerborosEncryp= tionTypes configures certain ciphersuites.

DHCP could be another= example of configuring managed endpoints in addition to Chrome enterprise = policy above. TLS-PSK similarly delegates the communication of PSK among pa= rties outside the spec space. Given the diversity of applications even in m= anaged environments, the definition of the key management feels out of the = scope for this document, but this draft can include example implementations= for illustration.

As for errors from key rotation, MAC verification= will cause such candidates to be discarded, and clients will fall back to = mDNS, STUN, or TURN as appropriate. If we feel like that we need to solve t= his problem more thoroughly, some implementation guidelines can also be inc= luded regarding maintaining a brief key history and using trial decryption = as needed. We'd appreciate suggestions on further improving these guide= lines.

Regards,
Qingsi

On Sun, Nov 3,= 2019 at 7:36 PM Martin Thomson <mt= @lowentropy.net> wrote:
This draft has the effect of defining a new gTLD.=C2=A0 That= 's problematic, and likely unnecessary.=C2=A0 I would encourage you to = look into ways to signal these candidates differently.=C2=A0 a=3Dencrypted-= candidate might work, for instance.=C2=A0 You might be able to encrypt more= data than an IP address in the process.

I also don't see how key management works here.=C2=A0 The goal of the d= raft is to define a set of entities that you are OK with reading your IP ad= dress, but I don't see any text that addresses the difficulty of a) ide= ntifying the entities in that set, and b) getting those entities the necess= ary keys.=C2=A0 Those are the really hard problems in this space.

I don't see how this provides any sort of algorithm agility or ability = to identify the keys that are in use.=C2=A0 Maybe trial decryption is accep= table in this context, but that can get unwieldy fairly rapidly.

On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote:
> Greetings.
>
> This draft
> (https://tools.ietf.or= g/html/draft-wang-mmusic-encrypted-ice-candidates-00) proposes a comple= mentary solution to the mDNS candidate detailed in draft-ietf-rtcweb-mdns-i= ce-candidates, specifically for managed networks. IPs of ICE candidates are= encrypted via PSK and signaled as pseudo-FQDNs in this proposal, and it ai= ms to address the connectivity challenge from the mDNS technique in these m= anaged environments. The current work on this draft is tracked in https://github.com/tQsW/encrypted-ice-candidates.
>
> Regards,
> Qingsi
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >
--0000000000006592c205969e416b-- From nobody Tue Nov 5 11:17:57 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF688120A2D; Tue, 5 Nov 2019 11:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 RCiuM1mWJdqe; Tue, 5 Nov 2019 11:17:47 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B17EC120A23; Tue, 5 Nov 2019 11:17:47 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id s17so23891030iol.12; Tue, 05 Nov 2019 11:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7LIIb2MYeIBos0lFHPBlXZbcGhiKn/bz7Z9GYa6vubk=; b=QuKhHvzSQZd/LehBB3yu4+As7Nx/BVP0JprqQhEzEuTrTazk7VzqV7gGLr/+HwMVGS FfVu8InJUO1ugHU8ae/w4SIZqgiF5Y3oJuwkCjn7WWY/Wfrgb6ohCy0sRrL1OZS5x31k zJeKEZtNl3dypl5aAE4y/F1U+emCSgO+goq19gZRfr6ZW8YC1poPPh0cI7miJ097QUAd 9N7zJDZNSCNXg9J8ONZCQWyOfQiwS2BfpqUrmsVe1ZySzSk46wFYh0ddFuBooz3mwvWL Np64Uvr5WpbiywIWTRyakFMFoVYl0UIM4c/8iJ+pi1dWPY2sguLblcV0Tnrppiuka89W wF0Q== 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=7LIIb2MYeIBos0lFHPBlXZbcGhiKn/bz7Z9GYa6vubk=; b=hjUporhpNDMe28F6zsa194SodIWs46Zdm24J1pUxzlGS8zfcAT/RHphAmduFtHZYHj Gq7FIsoeyWAXHPKB8IKq/46JRESX9z2Cy6IOkDFWYEFE40L0v4egQqR5Vqh/CJAfWbDV XH0Hu6+ifk3UeuPq/Sav6WvZNmUSj3mF4gKEpjrhHcPKzOw5zaJ14Z4mg2Ztqon4Ndxb hXE760k+0vqkfc4J1uKmXfH0zzLdg08G83kzhO7xY5yzOVs5D6H+f2XzBhDEPuAcYN5J a7CsBNO10uNInnLqZtY0NgGfdGFEqyjwY3Zz4S3KRroMKkU7wnZjzuTp/abci23png9c EO7g== X-Gm-Message-State: APjAAAVXEY5rqH1WRdQgqTjE6oSJkVlTHPB8CfsePFb3IyOrakteWM6P EKOsxejnML3LbQuT2ofY/33iMRlskfXufRV47jc= X-Google-Smtp-Source: APXvYqxCGb953VNMeYXO7NQziC919rJt6R1GIHZmKSpGjtaq6vxIJj1/Y5sVTbviIv8iPFvmi/7kaMvdLR+dLJr+6Z0= X-Received: by 2002:a6b:7c09:: with SMTP id m9mr2228108iok.139.1572981466837; Tue, 05 Nov 2019 11:17:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Tue, 5 Nov 2019 11:17:19 -0800 Message-ID: To: Martin Thomson Cc: Qingsi Wang , mmusic , Alex Drake , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000091b8df05969e4903" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 19:17:50 -0000 --00000000000091b8df05969e4903 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson wrote: > This draft has the effect of defining a new gTLD. That's problematic, and > likely unnecessary. I would encourage you to look into ways to signal > these candidates differently. a=encrypted-candidate might work, for > instance. You might be able to encrypt more data than an IP address in the > process. > > I agree with Martin that the use of a .encrypted pseudo-TLD is not necessary. If you need a special use name, the IAB has signaled willingness to permit registrations under .arpa. I don't personally think this is the best approach, but that tree is the right choice if you conclude a special use name is the way to go. regards, Ted > I also don't see how key management works here. The goal of the draft is > to define a set of entities that you are OK with reading your IP address, > but I don't see any text that addresses the difficulty of a) identifying > the entities in that set, and b) getting those entities the necessary > keys. Those are the really hard problems in this space. > > I don't see how this provides any sort of algorithm agility or ability to > identify the keys that are in use. Maybe trial decryption is acceptable in > this context, but that can get unwieldy fairly rapidly. > > On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote: > > Greetings. > > > > This draft > > ( > https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) > proposes a complementary solution to the mDNS candidate detailed in > draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. > IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in > this proposal, and it aims to address the connectivity challenge from the > mDNS technique in these managed environments. The current work on this > draft is tracked in https://github.com/tQsW/encrypted-ice-candidates. > > > > Regards, > > Qingsi > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000091b8df05969e4903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 3, 2019 at 7:36 PM Martin Tho= mson <mt@lowentropy.net> wro= te:
This draft has the effect of defining a new gTLD.=C2=A0 That= 's problematic, and likely unnecessary.=C2=A0 I would encourage you to = look into ways to signal these candidates differently.=C2=A0 a=3Dencrypted-= candidate might work, for instance.=C2=A0 You might be able to encrypt more= data than an IP address in the process.

I agree with Martin that the use of a=C2=A0 .encrypte= d pseudo-TLD is not necessary.=C2=A0 If you need a special use name, the IA= B has signaled willingness to permit registrations under .arpa.=C2=A0 I don= 't personally think this is the best approach, but that tree is the rig= ht choice if you conclude a special use name is the way to go.
regards,

Ted

=

=C2=A0
I also don't see how key management works here.=C2=A0 The goal of the d= raft is to define a set of entities that you are OK with reading your IP ad= dress, but I don't see any text that addresses the difficulty of a) ide= ntifying the entities in that set, and b) getting those entities the necess= ary keys.=C2=A0 Those are the really hard problems in this space.

I don't see how this provides any sort of algorithm agility or ability = to identify the keys that are in use.=C2=A0 Maybe trial decryption is accep= table in this context, but that can get unwieldy fairly rapidly.

On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote:
> Greetings.
>
> This draft
> (https://tools.ietf.or= g/html/draft-wang-mmusic-encrypted-ice-candidates-00) proposes a comple= mentary solution to the mDNS candidate detailed in draft-ietf-rtcweb-mdns-i= ce-candidates, specifically for managed networks. IPs of ICE candidates are= encrypted via PSK and signaled as pseudo-FQDNs in this proposal, and it ai= ms to address the connectivity challenge from the mDNS technique in these m= anaged environments. The current work on this draft is tracked in https://github.com/tQsW/encrypted-ice-candidates.
>
> Regards,
> Qingsi
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000091b8df05969e4903-- From nobody Tue Nov 5 13:30:06 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07482120BD2 for ; Tue, 5 Nov 2019 13:29:57 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9mF8AeQbBp2 for ; Tue, 5 Nov 2019 13:29:54 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 83A12120BC9 for ; Tue, 5 Nov 2019 13:29:54 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id r4so16910161pfl.7 for ; Tue, 05 Nov 2019 13:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cK+SHkfET3DgaSPG9uwbRTrRq/OFnEj0k1wjESgtGj8=; b=vt96niTHS0ImMZ97pk9jebOdJqXd/fEqXS04p43eTgNM6gFXW/92j2LWySgc1iB/6l eneW5B03G2NYhiUkO1AHlMgE0a3yayxt65tZanA78nJ1SvmfiTGfy/ATVpCWZcfllmlc dLRwELDpX6762mTLKpiw6YN9dpnka9L/H6RkAKC+U0DnFSosocxZot7LFGD2SaPfmMP9 iWQw/tRb5SxlS7TDuU9VsrPDtD37IC9gBsuuZuSM+RdZM5+forKmHA/pclBFowZcH5dy X+EQb6t5buoE9roOKeWhEkmwbDKCcrr8r5Xc1wgLR4Z8cCS6HHuAIM/mNN4gZVl4DvuO zb3g== 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=cK+SHkfET3DgaSPG9uwbRTrRq/OFnEj0k1wjESgtGj8=; b=IoeJOUkRBj5T4u4kaZACvQhCJuV8qMeEPsDfEKVk0j6G2qub5s5FDhg5cZJgBwquRz RyMc/pkxew2F98pyEhLI3clWrN0n3xtV4fOt8VR8sBelXRAyr1lN19ZnjZc9cqqoLNFi 1ofXThepkFxRb7qCqyudh2gYWK7aghhdKl9eyNvri1P4F093MIgstWgYqfg7Iral5zW5 kZzHn+MdGf0cAwpz86rG2uHLpkGC8TmNKbPPvhWEwPfMYdBNUyAY33kXx9Buis/iv9pX h1sYFC6Bit1wIHegymuAMdRsOco48sNpe+rA7dP1IBpQgjXrH67t8S7zg3eaOOKaAt9Q cO2A== X-Gm-Message-State: APjAAAXtH1j5eFN9Y4//K62eA5eWc7xUCVtsMD/p4mIbixnpBr+zWIsR veFsFEpp+ys8xruy0MbvnoGuN3Id3Ec= X-Google-Smtp-Source: APXvYqwUvp4SwpQKQgYkN74zV+b0oUWYC99pizXcx0MvmminPSuKNLfp8RBVRstjfzBio3j/iuONnA== X-Received: by 2002:a17:90a:77c7:: with SMTP id e7mr1447018pjs.133.1572989393242; Tue, 05 Nov 2019 13:29:53 -0800 (PST) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id s8sm6870534pgi.54.2019.11.05.13.29.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Nov 2019 13:29:51 -0800 (PST) Received: by mail-pf1-f172.google.com with SMTP id d13so16931980pfq.2; Tue, 05 Nov 2019 13:29:50 -0800 (PST) X-Received: by 2002:a62:8705:: with SMTP id i5mr210346pfe.238.1572989390560; Tue, 05 Nov 2019 13:29:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 5 Nov 2019 16:29:39 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: Martin Thomson , Alex Drake , RTCWeb IETF , Qingsi Wang , mmusic Content-Type: multipart/alternative; boundary="000000000000dc228c0596a02114" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 21:29:57 -0000 --000000000000dc228c0596a02114 Content-Type: text/plain; charset="UTF-8" One thing that I thought would make all DNS in ICE candidate work better is some sort of "addrtype" candidate extension. It would work like: a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host addrtype inipv4 a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns4 a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns6 a=candidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host addrtype dns6 This way client would know which DNS request (A or AAAA) should be used to resolve the DNS name in the candidate. c= and m= line can also be generated unambiguously if address type is specified in the candidate and is not determined during resolution time. For encrypted candidate, distribution of the actual encryption key can be implementation specific, but there should be some way to identify which key is used to encrypt the candidates. This will likely require additional candidate extension, such as "keyid": a=candidate:1 1 UDP 2130706431 2122262783 8c9bd03bb7a5a76a5803eebc688f0388.fa991acbdf116f6b72fd3a781174cd58.local 8998 typ host addrtype dnsipv6 keyid foo.bar.com This way you do not need an additional gTLD and encrypted candidate can be identified using the extra candidate extension. Furthermore, local addresses before encryption should be prefixed with some random nonce so that encrypted local addresses cannot be used for fingerprinting. Finally, probably in W3C we need to discuss if any API updates are required to enable encryption in ICE candidates. I think an additional option to createOffer/createAnswer that specifies which key to use for candidate encryption would probably be the best solution. Distributing actual keys can then be done via enterprise policies or keys can be pre-provisioned with web browsers via some sort of enrollment mechanism. Best Regards, _____________ Roman Shpount On Tue, Nov 5, 2019 at 2:17 PM Ted Hardie wrote: > On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson wrote: > >> This draft has the effect of defining a new gTLD. That's problematic, >> and likely unnecessary. I would encourage you to look into ways to signal >> these candidates differently. a=encrypted-candidate might work, for >> instance. You might be able to encrypt more data than an IP address in the >> process. >> >> I agree with Martin that the use of a .encrypted pseudo-TLD is not > necessary. If you need a special use name, the IAB has signaled > willingness to permit registrations under .arpa. I don't personally think > this is the best approach, but that tree is the right choice if you > conclude a special use name is the way to go. > > regards, > > Ted > > > > >> I also don't see how key management works here. The goal of the draft is >> to define a set of entities that you are OK with reading your IP address, >> but I don't see any text that addresses the difficulty of a) identifying >> the entities in that set, and b) getting those entities the necessary >> keys. Those are the really hard problems in this space. >> >> I don't see how this provides any sort of algorithm agility or ability to >> identify the keys that are in use. Maybe trial decryption is acceptable in >> this context, but that can get unwieldy fairly rapidly. >> >> On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote: >> > Greetings. >> > >> > This draft >> > ( >> https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) >> proposes a complementary solution to the mDNS candidate detailed in >> draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. >> IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in >> this proposal, and it aims to address the connectivity challenge from the >> mDNS technique in these managed environments. The current work on this >> draft is tracked in https://github.com/tQsW/encrypted-ice-candidates. >> > >> > Regards, >> > Qingsi >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000dc228c0596a02114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One thing that I thought would make all DNS in ICE candida= te work better is some sort of "addrtype" candidate extension.=C2= =A0

It would work like:
a=3Dcandidate:1 1 UDP = 2130706431 203.0.113.141 8998 typ host addrtype inipv4
a=3Dcandid= ate:1 1 UDP 2130706431 foo.bar.com 8998 = typ host addrtype dns4
a=3Dcandidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns6
a= =3Dcandidate:1 1 udp 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local = 54596 typ host=C2=A0 addrtype dns6

This way client would know which DNS reque= st (A or AAAA) should be used to resolve the DNS name in the candidate. c= =3D and m=3D line can also be generated unambiguously=C2=A0if address type = is specified in the candidate and is not determined during resolution time.=
=C2=A0
For encrypted candidate, distribution of the actual encryption key can= be implementation=C2=A0specific, but there should be some way to identify = which key is used to encrypt the candidates. This will likely require addit= ional candidate extension, such as "keyid":

a=3Dcandidate:1 1 UDP 2130706431=C2=A02122262783 8c9bd03bb7a5a76a5803eebc688f0388.fa991<= span style=3D"color:rgb(0,0,0);font-size:13.3333px">acbdf116f6b72fd3a781174= cd58.local=C2=A08998 typ host addrtype dnsipv6 keyid foo.bar.com

This way you do no= t need an additional gTLD and encrypted candidate can be identified using t= he extra candidate extension.

Furthermore, local a= ddresses before encryption should be prefixed with some random nonce so tha= t encrypted local addresses cannot be used for fingerprinting.
Finally, probably in W3C we need to discuss if any API updates= are required to enable encryption in ICE candidates. I think an additional= option to createOffer/createAnswer that specifies which key to use for can= didate encryption would probably be the best solution. Distributing actual = keys can then be done via enterprise policies or keys can be pre-provisione= d with web browsers via some sort of enrollment mechanism.

Best Regards,
_____________
Roman Shpo= unt


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 5, 2019 at 2:17 PM Ted Har= die <ted.ietf@gmail.com> wr= ote:
On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson <mt@lowentropy.net&= gt; wrote:
This draft has the effect of defining a new gTLD.=C2= =A0 That's problematic, and likely unnecessary.=C2=A0 I would encourage= you to look into ways to signal these candidates differently.=C2=A0 a=3Den= crypted-candidate might work, for instance.=C2=A0 You might be able to encr= ypt more data than an IP address in the process.

I agree with Martin that the use of a=C2=A0 .encrypte= d pseudo-TLD is not necessary.=C2=A0 If you need a special use name, the IA= B has signaled willingness to permit registrations under .arpa.=C2=A0 I don= 't personally think this is the best approach, but that tree is the rig= ht choice if you conclude a special use name is the way to go.
regards,

Ted

=

=C2=A0
I also don't see how key management works here.=C2=A0 The goal of the d= raft is to define a set of entities that you are OK with reading your IP ad= dress, but I don't see any text that addresses the difficulty of a) ide= ntifying the entities in that set, and b) getting those entities the necess= ary keys.=C2=A0 Those are the really hard problems in this space.

I don't see how this provides any sort of algorithm agility or ability = to identify the keys that are in use.=C2=A0 Maybe trial decryption is accep= table in this context, but that can get unwieldy fairly rapidly.

On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote:
> Greetings.
>
> This draft
> (https://tools.ietf.or= g/html/draft-wang-mmusic-encrypted-ice-candidates-00) proposes a comple= mentary solution to the mDNS candidate detailed in draft-ietf-rtcweb-mdns-i= ce-candidates, specifically for managed networks. IPs of ICE candidates are= encrypted via PSK and signaled as pseudo-FQDNs in this proposal, and it ai= ms to address the connectivity challenge from the mDNS technique in these m= anaged environments. The current work on this draft is tracked in https://github.com/tQsW/encrypted-ice-candidates.
>
> Regards,
> Qingsi
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000dc228c0596a02114-- From nobody Tue Nov 5 16:13:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967BB1200E9 for ; Tue, 5 Nov 2019 16:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2ALQsDW0e0W for ; Tue, 5 Nov 2019 16:13:26 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 DEB1C120121 for ; Tue, 5 Nov 2019 16:13:25 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id s25so2400086uap.1 for ; Tue, 05 Nov 2019 16:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LbM5kJDq5fvuNv2uOj1LeQkghe2NgwGGHPHqUteFTfg=; b=b8kZhYiPKLLFG6xWAujF5RxWaCMF1lIBdN25En5Zhs3lJqtMaOJZ/VX6WRJTjvlJxH grCYwA+JtYGItz5XzwJAlcogIWswYA7EdnmFvNPytkSqvwGk5tlWMUFvXOntvDztGBqU R+bjt05EmS/rgJXgsBaqTSFcO5Xn7IQChvSMHE0GwLsK6E4k/7MyNZgRFbB/DD1IQ3m2 w/CErzSLorDX07BVlRduoMiQLjmOMq/0zSGcSfOIn2n4N5ywkfIHjeZZj7TfwyE7MM1h tooxTrnwh8VwcklfDl4ubH0xo9cw6DTxl6g1FzGvaJGAeUPo46g2lJEGr/lMWb86g6SY yvAQ== 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=LbM5kJDq5fvuNv2uOj1LeQkghe2NgwGGHPHqUteFTfg=; b=FqrQkXUgMjxhjnkaBgd5EJv79Ag01a/If8lydnUmqTn2OqP/q/vJ00JnyfWi4lELb/ m+A8D4GSiucGtz2sbYuqfvrLJpqUu2/8pnW50vbe/OXPRmekj6SUq0qQCOdI3re1oV1F WPtIvf1YRJkGJOyNbifJDKLLpsEL2e+EflX/NQ4VnGX3x9jYYjUMOTYCJ08YGEKRpNx5 ozh0OnW8dmNE+kkBbZKtB3W4BBGwMPvhLy80Bguu0PwY+yLDPAKWA7BazM8fCJw/e+Ng c6mfKfp2kRwIGRGsTVCBrwAeL+XV9tLQDVDxexiGAz4rbmphMVSdlwn2dVdp0wqjTeGN JIMw== X-Gm-Message-State: APjAAAWU54gwJxSP9cP23T+2RcAoK43ji1RqkZK6JjMRWkdqAJBzRE9i qtgtCqPdvBf7/NUN/AwU6EMZnRK+0ZwZqsx16GJ0Xw== X-Google-Smtp-Source: APXvYqwexfFwqwv8K9r73z8nPd6LcG8LfyKXPeUCA5u3MBdtfGu25JPuhopCdywuKgeFA66KwhW/CxF7zsys8EFyfKo= X-Received: by 2002:ab0:62a:: with SMTP id f39mr16610171uaf.56.1572999204227; Tue, 05 Nov 2019 16:13:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 5 Nov 2019 16:13:12 -0800 Message-ID: To: Roman Shpount Cc: Ted Hardie , Alex Drake , RTCWeb IETF , Qingsi Wang , mmusic Content-Type: multipart/alternative; boundary="000000000000cd4bfa0596a26a0d" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 00:13:29 -0000 --000000000000cd4bfa0596a26a0d Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount wrote: > One thing that I thought would make all DNS in ICE candidate work better > is some sort of "addrtype" candidate extension. > > It would work like: > a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host addrtype inipv4 > a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns4 > a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns6 > a=candidate:1 1 udp 2122262783 <(212)%20226-2783> > 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host addrtype dns6 > > This way client would know which DNS request (A or AAAA) should be used to > resolve the DNS name in the candidate. c= and m= line can also be generated > unambiguously if address type is specified in the candidate and is not > determined during resolution time. > I think this might be useful, but it seems separate from the encryption proposal, so let's discuss that in its own thread. > > For encrypted candidate, distribution of the actual encryption key can be > implementation specific, but there should be some way to identify which key > is used to encrypt the candidates. This will likely require additional > candidate extension, such as "keyid": > > a=candidate:1 1 UDP 2130706431 2122262783 <(212)%20226-2783> > 8c9bd03bb7a5a76a5803eebc688f0388.fa991acbdf116f6b72fd3a781174cd58.local 8998 > typ host addrtype dnsipv6 keyid foo.bar.com > > This way you do not need an additional gTLD and encrypted candidate can be > identified using the extra candidate extension. > Not sure we need a keyid, but marking the encrypted candidate type somehow in the candidate-attribute seems like a good thing to consider. > > Furthermore, local addresses before encryption should be prefixed with > some random nonce so that encrypted local addresses cannot be used for > fingerprinting. > This is already described in the draft - the ice-pwd value is used for the IV, which ensures the encryption output will be different across PeerConnections. > > Finally, probably in W3C we need to discuss if any API updates are > required to enable encryption in ICE candidates. I think an additional > option to createOffer/createAnswer that specifies which key to use for > candidate encryption would probably be the best solution. Distributing > actual keys can then be done via enterprise policies or keys can be > pre-provisioned with web browsers via some sort of enrollment mechanism. > > Can you explain more as to why? We don't want app developers to have to care about this, or else this solution will never get off the ground. > Best Regards, > _____________ > Roman Shpount > > > On Tue, Nov 5, 2019 at 2:17 PM Ted Hardie wrote: > >> On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson wrote: >> >>> This draft has the effect of defining a new gTLD. That's problematic, >>> and likely unnecessary. I would encourage you to look into ways to signal >>> these candidates differently. a=encrypted-candidate might work, for >>> instance. You might be able to encrypt more data than an IP address in the >>> process. >>> >>> I agree with Martin that the use of a .encrypted pseudo-TLD is not >> necessary. If you need a special use name, the IAB has signaled >> willingness to permit registrations under .arpa. I don't personally think >> this is the best approach, but that tree is the right choice if you >> conclude a special use name is the way to go. >> >> regards, >> >> Ted >> >> >> >> >>> I also don't see how key management works here. The goal of the draft >>> is to define a set of entities that you are OK with reading your IP >>> address, but I don't see any text that addresses the difficulty of a) >>> identifying the entities in that set, and b) getting those entities the >>> necessary keys. Those are the really hard problems in this space. >>> >>> I don't see how this provides any sort of algorithm agility or ability >>> to identify the keys that are in use. Maybe trial decryption is acceptable >>> in this context, but that can get unwieldy fairly rapidly. >>> >>> On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote: >>> > Greetings. >>> > >>> > This draft >>> > ( >>> https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) >>> proposes a complementary solution to the mDNS candidate detailed in >>> draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks. >>> IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in >>> this proposal, and it aims to address the connectivity challenge from the >>> mDNS technique in these managed environments. The current work on this >>> draft is tracked in https://github.com/tQsW/encrypted-ice-candidates. >>> > >>> > Regards, >>> > Qingsi >>> > _______________________________________________ >>> > rtcweb mailing list >>> > rtcweb@ietf.org >>> > https://www.ietf.org/mailman/listinfo/rtcweb >>> > >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000cd4bfa0596a26a0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 5, 2019 at 1:30 PM Roman = Shpount <roman@telurix.com> = wrote:
One thing that I thought would make all DNS in ICE candidate work = better is some sort of "addrtype" candidate extension.=C2=A0
=
It would work like:
a=3Dcandidate:1 1 UDP 21307064= 31 203.0.113.141 8998 typ host addrtype inipv4
a=3Dcandidate:1 1 = UDP 2130706431 foo.bar.com= 8998 typ host addrtype dns4
a=3Dcandidate:1 1 UDP 2130706431= foo.bar.com 8998 typ = host addrtype dns6
a=3Dcandidate:1 1 udp 2122262783 1f4712db-ea17-4= bcf-a596-105139dfd8bf.local 54596 typ host=C2=A0 addrtype dns6

This way client would know which DNS reque= st (A or AAAA) should be used to resolve the DNS name in the candidate. c= =3D and m=3D line can also be generated unambiguously=C2=A0if address type = is specified in the candidate and is not determined during resolution time.=

I think this might be usef= ul, but it seems separate from the encryption proposal, so let's discus= s that in its own thread.=C2=A0
=C2=A0
For encrypted candidate, distribution of the actual encryption key can= be implementation=C2=A0specific, but there should be some way to identify = which key is used to encrypt the candidates. This will likely require addit= ional candidate extension, such as "keyid":

a=3Dcandidate:1 1 UDP 2130706431=C2=A02122262783 8c9bd03bb7a5a76a5803eebc688f0388.fa991acbdf116f6b72fd3a781= 174cd58.local=C2=A08998 typ host addrtype dnsipv6 keyid foo.bar.com

This way you do not need an additional gTLD and encrypted candidate can = be identified using the extra candidate extension.
<= /blockquote>

Not sure we need a keyid, but marking the e= ncrypted candidate type somehow in the candidate-attribute seems like a goo= d thing to consider.

Furthermore, local addresse= s before encryption should be prefixed with some random nonce so that encry= pted local addresses cannot be used for fingerprinting.

This is already described in the draft= - the ice-pwd value is used for the IV, which ensures the encryption outpu= t will be different across PeerConnections.

Fina= lly, probably in W3C we need to discuss if any API updates are required to = enable encryption in ICE candidates. I think an additional option to create= Offer/createAnswer that specifies which key to use for candidate encryption= would probably be the best solution. Distributing actual keys can then be = done via enterprise policies or keys can be pre-provisioned with web browse= rs via some sort of enrollment mechanism.

<= /div>
Can you explain more as to why? We don't want ap= p developers to have to care about this, or else this solution will never g= et off the ground.=C2=A0
=C2=A0
Best Regards,
_____________
Roman Shpount
<= br>

On Tue, Nov 5, 2019 at 2:17 PM Ted Hardie <ted.ietf@gmail.com>= wrote:
On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson <= ;mt@lowentropy.net> wrote:
This draft has the effect of defining a new gTLD.= =C2=A0 That's problematic, and likely unnecessary.=C2=A0 I would encour= age you to look into ways to signal these candidates differently.=C2=A0 a= =3Dencrypted-candidate might work, for instance.=C2=A0 You might be able to= encrypt more data than an IP address in the process.



=

=C2=A0
I also don't see how key management works here.=C2=A0 The goal of the d= raft is to define a set of entities that you are OK with reading your IP ad= dress, but I don't see any text that addresses the difficulty of a) ide= ntifying the entities in that set, and b) getting those entities the necess= ary keys.=C2=A0 Those are the really hard problems in this space.

I don't see how this provides any sort of algorithm agility or ability = to identify the keys that are in use.=C2=A0 Maybe trial decryption is accep= table in this context, but that can get unwieldy fairly rapidly.

On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote:
> Greetings.
>
> This draft
> (https://tools.ietf.or= g/html/draft-wang-mmusic-encrypted-ice-candidates-00) proposes a comple= mentary solution to the mDNS candidate detailed in draft-ietf-rtcweb-mdns-i= ce-candidates, specifically for managed networks. IPs of ICE candidates are= encrypted via PSK and signaled as pseudo-FQDNs in this proposal, and it ai= ms to address the connectivity challenge from the mDNS technique in these m= anaged environments. The current work on this draft is tracked in https://github.com/tQsW/encrypted-ice-candidates.
>
> Regards,
> Qingsi
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000cd4bfa0596a26a0d-- From nobody Tue Nov 5 19:16:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF2E120826; Tue, 5 Nov 2019 19:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=b/8UIQyK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GYhN/lu+ 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 igzaBp6hKgOD; Tue, 5 Nov 2019 19:16:22 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D7612002E; Tue, 5 Nov 2019 19:16:22 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 52EAF21EBC; Tue, 5 Nov 2019 22:16:21 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 22:16:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=s3o7c7FIShUTHNvBDTauS14YjEHd +Nusjhw1DomlkL4=; b=b/8UIQyKf3X6ZXFOCT6SJCiYSGIDyrNi/DOmBRLDEgGE SWqt9TJCx3MHE38eS8YMdIVyTyC8SbrbXFMSwQ+SRDNPt6a9uXDjCnijVtTCEaAf W3MWG3rVEeSyRQttDhlGj/jB2FSvtYjhiATL2D3YZ2bq/wi8k1C3FSmOthOaXmns x8fZy8APfoXDe2k4Guv6R5vR/O8x8j3kPmS4qSIlrxWdv+spQNWeag4Kn3JHGdPS /KrO6Ts1m1kUxkCuA9TuNvIAQugwy1S9jMRmf1KYWYqlYtlfa+c7yMseLzvZUYDH xu7JRGCFh41AKwTEQ8dxr3GDv+LpvY+HasErq0HypQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=s3o7c7 FIShUTHNvBDTauS14YjEHd+Nusjhw1DomlkL4=; b=GYhN/lu+z0Yzr81KBsu7vz w3YY/EwFTyTDbK5oItuazowM2FNsOuw4e4+2/V6raS2WrkLW9qONmoSpFwbPLxT+ jav4zJjzCMn+d6lzh8KzEhZAq1djYetK+Hl9eEg/yoJ4XjVVifGRABbg17UeNjq1 huC8UmkNbmcdoy5hHmWA/GpoYITTY+jh+dqe3hiJG2neTPv7i+hGEtBsKW94WogE b/SQwRNoJC68iEC4c4HsfGH8IZMBAPMLyDhZl9bjK0sGdRCqRFSXAyuLlsoPzuQs CV+ZOHw5DGQVxYDQa0hfOevDp8UlV9wHyO1zdNa+Ry+WRirFWGxTZ84Go54dGW3Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C44ADE00A5; Tue, 5 Nov 2019 22:16:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <6f18c4d8-e4a7-46be-ac81-032ef2d1e03f@www.fastmail.com> In-Reply-To: References: Date: Wed, 06 Nov 2019 14:16:00 +1100 From: "Martin Thomson" To: "Qingsi Wang" Cc: mmusic , "Alex Drake" , rtcweb@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [rtcweb] =?utf-8?q?=5BMMUSIC=5D_Draft_new=3A_draft-wang-mmusic-e?= =?utf-8?q?ncrypted-ice-candidates?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 03:16:24 -0000 On Wed, Nov 6, 2019, at 06:15, Qingsi Wang wrote: > On the key management, we think this should be deferred to > implementations, given different options to solve this problem. Chrome > enterprise policy is currently an example for such a solution in > managed environments, and it allows admins to push configuration > settings to managed endpoints. If there is an assumption that key provisioning works this way then I can see how you reached this conclusion. I think that you need to be very careful to describe how that constrains the design in the draft though. Right now, there is a big hole that screams "key management problems". I wasn't asking you to define the key management system, just to articulate what properties this design assumes and maybe offer some guidance for implementation. If this is as simple as you describe, that's great. I don't think that it is that simple - this is a combination of policy and context that is hard to get right. If I take that managed device home, why would I hide my address? Or, why would I share my address with my colleagues? Finally, you are talking about a secret that many people will know. For instance, I can easily imagine people posting the Foo company corporate shared key on forums to aid in debugging. > As for errors from key rotation, MAC verification will cause such > candidates to be discarded, and clients will fall back to mDNS, STUN, > or TURN as appropriate. If we feel like that we need to solve this > problem more thoroughly, some implementation guidelines can also be > included regarding maintaining a brief key history and using trial > decryption as needed. We'd appreciate suggestions on further improving > these guidelines. For the very constrained configuration you describe, it might be appropriate to rely on trial decryption, but that assumes that all deployments will be able to manage with a very simple scheme. That's rarely appropriate in the general case. I'd suggest that some sort of key identifier is probably necessary. From nobody Mon Nov 11 01:04:09 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0E120898 for ; Mon, 11 Nov 2019 01:04:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 360wGQd8pRUe for ; Mon, 11 Nov 2019 01:03:59 -0800 (PST) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 8F883120897 for ; Mon, 11 Nov 2019 01:03:59 -0800 (PST) Received: by mail-pf1-x441.google.com with SMTP id q26so10242957pfn.11 for ; Mon, 11 Nov 2019 01:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GYd5AZF17YDjO/Wbhz5IIkDmx1tI1Gb6hxljPYFq29I=; b=F4Vi0GWjkKB3cpvxIDJ2Wr8L3mLW+Rg5D0E7Tu3ocOQ2DA4zHHnNoCeRaSruXcLxiY awqdCzQ6tOTRfAVXKnqbpS2VFI3U4pIqet2T/ymwJdlTYkmxnFA7ajlwDFcXJEJKhEmH l0zvjqKta2Glh9fmISVCEAMLbpznJkkgSxL3VtqejCEh5WZy0XSDTjpg8+OxQi+/D4Yn Bmrq4J9NYlG/ZApHBnZ05NuLlmBlA21da38dE3eEHRhXCkoI4OchnASSxtkSqw1vFEKM JT5rR9GR3JM5BgYsDZ46wDueKmm/AWbosmnpIOo2ryGlzMah/ialLKkjUCGhgwOoWzxf zrzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GYd5AZF17YDjO/Wbhz5IIkDmx1tI1Gb6hxljPYFq29I=; b=c7J1PTEk4acwopobETFmR1aFkNHDgnUBaIdLm6kgmE9cE1SjzcG+TH26G3nS3cVPtK CrVpBHoP1WCmBnBJdOHM01aI6jgCEeKNYtL4vOOJQaQkRTeQLxb8TlBHeJ90myLcoOGE ncf3A1n+O8euaC1Qcprnzgd1e0dj6hBHLObOs9KjRCvbL1IYlBVaoJCbEp6hr2HDWv4E 0VQbR4Mqwp+A7TL2oyaIwzaVQLWfWRU5RM3vJWRJu1RK1jqdHfZleG/IfQJNTxy8g53p FK7/kUMco5v1aEPlbY8pjcnjjeNsr8RZAMENGiR4+xxpvoCsuc+q2dLDxKls2ncyVEFY 6yVQ== X-Gm-Message-State: APjAAAXM8a0e77IC2CWfBMZ+zmALdtSUw3doKp53zvxlXzw/RqDeqnsZ ef4borC8f6cfDSkIPgrnIdrbKg== X-Google-Smtp-Source: APXvYqwaGRtNbuXZrW7GSV1fY2R5nXXCFnF0JkbFhA912BitBNQTxM3Bq8IpiFAQB1J4TyutL+aFUQ== X-Received: by 2002:a65:48c7:: with SMTP id o7mr6002658pgs.276.1573463038426; Mon, 11 Nov 2019 01:03:58 -0800 (PST) Received: from 38f9d359441f.ant.amazon.com ([23.252.60.236]) by smtp.gmail.com with ESMTPSA id q20sm13385494pff.134.2019.11.11.01.03.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2019 01:03:57 -0800 (PST) Date: Mon, 11 Nov 2019 01:03:56 -0800 From: Sean DuBois To: Qingsi Wang Cc: mmusic@ietf.org, Alex Drake , rtcweb@ietf.org Message-ID: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 09:04:04 -0000 On Fri, Nov 01, 2019 at 01:06:22PM -0700, Qingsi Wang wrote: > Greetings. > > This draft ( > https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) > proposes a complementary solution to the mDNS candidate detailed > in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed > networks. IPs of ICE candidates are encrypted via PSK and signaled as > pseudo-FQDNs in this proposal, and it aims to address the connectivity > challenge from the mDNS technique in these managed environments. The > current work on this draft is tracked in > https://github.com/tQsW/encrypted-ice-candidates. > > Regards, > Qingsi > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Hi, Really excited to see this RFC. This is a real pain point, and glad it is being addressed. I implemented this over the weekend and everything fell into place. Have you thought about/explored encrypting the entire SessionDescription? There might be some issues I am not aware of, but it would give us some other nice things! * No more SDP munging (or at least make it harder) - People shoot themselves in the foot constantly by editing things - Will push people to communicate API needs more, instead of more hacks * Host candidates aren't the only thing you can be fingerprinted off of - Agents craft very different SDPs (FireFox vs Chromium) - SDPs reveal hardware attributes (Chromium Android has H264 only with HW Accel) - Agent may have different experiments/settings (attributes at session/media level) * Changes to candidate strings is going to cause more breakage Maybe this doesn't matter as much, but I anticipate this is going to cause more bugs. Some clients/SFUs/MCUs... blew up when mDNS came out, I bet another change is going to cause the same thing. It sounds like this will be much less likely because people will need to setup something up to get the PSK going. ------- I would love to see example implementations of the Key Management. Is there any precedent for configuration of the WebRTC agent in managed networks? From nobody Mon Nov 11 02:59:33 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31491200CE; Mon, 11 Nov 2019 02:59:31 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyhMeDNS4fdM; Mon, 11 Nov 2019 02:59:29 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9928C120255; Mon, 11 Nov 2019 02:59:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3DB4F7C4B35; Mon, 11 Nov 2019 11:59:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mltDtr7GWWWD; Mon, 11 Nov 2019 11:59:22 +0100 (CET) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id B0DE57C39E3; Mon, 11 Nov 2019 11:59:22 +0100 (CET) To: Sean DuBois , Qingsi Wang Cc: Alex Drake , rtcweb@ietf.org, mmusic@ietf.org References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <909be25d-740a-03fd-ecbf-f3fb73f0723d@alvestrand.no> Date: Mon, 11 Nov 2019 11:59:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 10:59:32 -0000 Den 11.11.2019 10:03, skrev Sean DuBois: > On Fri, Nov 01, 2019 at 01:06:22PM -0700, Qingsi Wang wrote: >> Greetings. >> >> This draft ( >> https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) >> proposes a complementary solution to the mDNS candidate detailed >> in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed >> networks. IPs of ICE candidates are encrypted via PSK and signaled as >> pseudo-FQDNs in this proposal, and it aims to address the connectivity >> challenge from the mDNS technique in these managed environments. The >> current work on this draft is tracked in >> https://github.com/tQsW/encrypted-ice-candidates. >> >> Regards, >> Qingsi > >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > Hi, > > Really excited to see this RFC. This is a real pain point, and glad it > is being addressed. I implemented this over the weekend and everything > fell into place. > > Have you thought about/explored encrypting the entire SessionDescription? This would destroy interoperability with any currently fielded implementation, so it's unlikely to be popular. It also requires setting up a shared key before you can exchange SDP, which is a pain (as this draft makes clear). > There might be some issues I am not aware of, but it would give us some > other nice things! > > * No more SDP munging (or at least make it harder) > - People shoot themselves in the foot constantly by editing things > - Will push people to communicate API needs more, instead of more hacks > > * Host candidates aren't the only thing you can be fingerprinted off of > - Agents craft very different SDPs (FireFox vs Chromium) > - SDPs reveal hardware attributes (Chromium Android has H264 only with HW Accel) > - Agent may have different experiments/settings (attributes at session/media level) > > * Changes to candidate strings is going to cause more breakage > Maybe this doesn't matter as much, but I anticipate this is going to > cause more bugs. Some clients/SFUs/MCUs... blew up when mDNS came out, > > I bet another change is going to cause the same thing. It sounds like > this will be much less likely because people will need to setup > something up to get the PSK going. > ------- > > I would love to see example implementations of the Key Management. Is > there any precedent for configuration of the WebRTC agent in managed > networks? > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Nov 11 03:28:26 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622C51200BA; Mon, 11 Nov 2019 03:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FYLyNDsFvLV8; Mon, 11 Nov 2019 03:28:23 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140054.outbound.protection.outlook.com [40.107.14.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061D2120820; Mon, 11 Nov 2019 03:28:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B95zDa9XzuTgRjwqK7HpnLAkT/GU5Zc3EjVl+dL/cpZDZoNncZpd5d2RYq/YcoE3kqJcX03WZ4yCknXUG+ts7P3djtulF52ys0Fav29dJ2UJbOtnqouhaZ6XCkTJ3LxzWK0n7krDeFQb83cy6c/uHEknkPe1/ggdIh5tt7kpb7Svwoc0mYHYp93hiOHzfmcks+HdkEHowt/Olx9XC0Dx+FYwrONFfsGGs+lcFnFh5Vv7WgblZck9XK90roo1UVu8/pagwtT4Lpb7iCwnBXEM9K4HXc1J+IYlmHDYN0IjOUtajcye3KgOSZG8hpO0LKkiB67Aef2rCKnuSzU1H3G6Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bZM8ZpdXSfWZitkIEdbCho8210SDRPj44r/b+EKJYag=; b=eHGg3AmTqqEiP4fFak0cagvKfVCp05/fBi7Eaoapdvi5YAkyn6SXBbdwELiGWUl+HPtPdsW2DhLvMh+fl39GIDR8NlM5YJHEjlLR8+l2uewj6Q/nMFxX5xP1vsX83fJr2wuhhJbPmVCplreC2ulM5Zy2NfzYT6tb5OhL46kATr2F6FUfR87euykzs5JoekemKHfZqkvTncqWl1jHflKRNPUtbeHluPHQKtEtWwjHRh7EmM6jX5OMvASWgVkxtIQwUS+P1+qfXSbI0MV/NHq7k4dr2SFTmZmtMmCNVot0pWNayaHIluvo3AdSCD0amggUqRTke9UTD/ZP7h5yEO2dXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bZM8ZpdXSfWZitkIEdbCho8210SDRPj44r/b+EKJYag=; b=dyRoBOZ8AE6lSMj04oFHVlkaLLl4Fxiop7uVeJWNh8/enyiseulCXnS8EQHLgpTbQggJU6HmtcTz6RgQI4nLjK8B18nLv17j5bBVY2nVztrRqSHCs5X6aYwy+jSL04j+kLLF3wkGLlS+l9zVYPdHdFioO0CEWJ/S9l5QgTNgPcA= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4284.eurprd07.prod.outlook.com (20.176.166.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.21; Mon, 11 Nov 2019 11:28:20 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2451.018; Mon, 11 Nov 2019 11:28:20 +0000 From: Christer Holmberg To: Sean DuBois , Qingsi Wang CC: Alex Drake , "rtcweb@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] [rtcweb] Draft new: draft-wang-mmusic-encrypted-ice-candidates Thread-Index: AQHVmG8DZgrwPAupCUS7MAkIXrOXA6eF9uWA Date: Mon, 11 Nov 2019 11:28:19 +0000 Message-ID: References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> In-Reply-To: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8579993a-5a76-495e-b038-08d7669a4126 x-ms-traffictypediagnostic: HE1PR07MB4284: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(199004)(189003)(476003)(2906002)(4744005)(486006)(256004)(44832011)(102836004)(6116002)(11346002)(71190400001)(110136005)(14444005)(26005)(76176011)(71200400001)(446003)(3846002)(4326008)(6246003)(5660300002)(8936002)(6506007)(186003)(86362001)(2616005)(81166006)(8676002)(81156014)(76116006)(66066001)(91956017)(25786009)(36756003)(99286004)(14454004)(7736002)(66946007)(305945005)(6512007)(58126008)(54906003)(6486002)(6436002)(229853002)(66446008)(66556008)(64756008)(66476007)(478600001)(316002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4284; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tytKMup2sDZKv0FaAQfEEUI75ZQ3oGQ1XWFDf7oF39KV+zsb5QdsL7KdECj36FHvbtCDiqO8yq12hCty1XRPJJ1U0F1UCkNwSElD4nd+hzWUVR6EUIJ1ZA8oKlvxSAJu3fflBuALgGo6ffDUaZIhquaSkIdZgkXb68Z0hH0Yk2N3Gf26Ctjv7eE78+9VMyW7bKPkcU6vxIkG8chiWMqXcDU3StMSbsc255B0ouYwEIiK1OStnZE2wUKZLtwEpn0nm5rkI185wjttCRi82fw/yLO0NH8eZy5a6P3dPdPnO0Cn0Vmr+n+Omdu3ZLMqIhcgOM3gmMlL92ul4BoPBbCy+omxI1UASEWTaFzBOoD7YsdCLWTTNmIHGwjEgzajzsLfKcj9cjHR7FWmnpOIDydVicqzgQ6GRv3YSucSL4y2qZElFNHNyzfzNwh/tIcMX7GI x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8579993a-5a76-495e-b038-08d7669a4126 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 11:28:19.8596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sckMvU6oaxzZyLkAKftZPBDcYtz38ekNwb9OoqFpH5JxZBRzLruqeoPj2lMjBtOLyt7vvuGdV+Js2Gc6DdmDpF/PJNIyxlC3QRwXatyIXqQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4284 Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 11:28:25 -0000 SEksDQogICAgDQo+ICAgIFJlYWxseSBleGNpdGVkIHRvIHNlZSB0aGlzIFJGQy4gVGhpcyBpcyBh IHJlYWwgcGFpbiBwb2ludCwgYW5kIGdsYWQgaXQNCj4gICAgaXMgYmVpbmcgYWRkcmVzc2VkLiBJ IGltcGxlbWVudGVkIHRoaXMgb3ZlciB0aGUgd2Vla2VuZCBhbmQgZXZlcnl0aGluZw0KPiAgICBm ZWxsIGludG8gcGxhY2UuDQo+ICAgIA0KPiAgICBIYXZlIHlvdSB0aG91Z2h0IGFib3V0L2V4cGxv cmVkIGVuY3J5cHRpbmcgdGhlIGVudGlyZSBTZXNzaW9uRGVzY3JpcHRpb24/DQo+ICAgIFRoZXJl IG1pZ2h0IGJlIHNvbWUgaXNzdWVzIEkgYW0gbm90IGF3YXJlIG9mLCBidXQgaXQgd291bGQgZ2l2 ZSB1cyBzb21lDQo+ICAgIG90aGVyIG5pY2UgdGhpbmdzIQ0KPiAgIA0KPiAgICogTm8gbW9yZSBT RFAgbXVuZ2luZyAob3IgYXQgbGVhc3QgbWFrZSBpdCBoYXJkZXIpDQo+ICAgICAgIC0gUGVvcGxl IHNob290IHRoZW1zZWx2ZXMgaW4gdGhlIGZvb3QgY29uc3RhbnRseSBieSBlZGl0aW5nIHRoaW5n cw0KDQpQZW9wbGUgZG9uJ3QgbW9kaWZ5IFNEUCBqdXN0IGJlY2F1c2UgdGhleSBjYW4gLSB0aGV5 IG1ha2UgaXQgaW4gb3JkZXIgdG8gbWFrZSB0aGluZ3Mgd29yay4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KIA0KDQo= From nobody Mon Nov 11 10:37:55 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80C120BFA; Mon, 11 Nov 2019 10:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9X6BYqKF343; Mon, 11 Nov 2019 10:37:44 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 C49AC120B85; Mon, 11 Nov 2019 10:37:38 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id d6so10269671lfc.0; Mon, 11 Nov 2019 10:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HEhH8Of/G/+SsSfNbAawCjew7TUOWEXVEs++vU0neiU=; b=pbnVPN/a4RFVL2nGyG22pDyU12Ua1JWUvcZ9yQLpZ/8hr4VR9W0iquhwFdV5HLfJ/I jxCIs5ysUpVUMRIkh0H5KztGHrLVpsR8LzlETea6XCkCU7ljH+CMkKVFzgxiBzshNdop qVk4BQTKKZxqiq98nfnm3WQsCBqgrHmQXfDTjvPb1F3EKOEEriG9mlh+rnSfl1lOq58G vyEP2LS5/JVLYGEoqF3FfQS6U/bmg7ulQMXONJ0nPkfZqSDbUegrSPKZjKAKWmRNv1p1 rbIJ5vrq4RPmT52HvZgg2BEMZY45yAKxhPXNb0VvJlmjZsl3R9bp/pYKMSVxLUiJWfdD IrLQ== 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=HEhH8Of/G/+SsSfNbAawCjew7TUOWEXVEs++vU0neiU=; b=Ggtpv93ME5uLwcB2TgTL/jEc/4ClRHz52v0RSrAeGEC8dLq7lFBoq4+I6LqkgpNFqO 1EIemDp7NFCd4nAq8aHEyarAtMY/Zun+iAapk5ToxlGnB+WUtddFA1HI3pOP3T4QcNb0 JEtXB7qYCgtlVDf9QdAauy8CmvrLJuYLy5GfZQ3w23dMK5jJcPe8devuMJtzxerrXcrh 2ktl5r+oI6Q9QVdaWIpF0rerszRUChS8APrN3xueF3hiw4MA2gPmIJl+5wgvzmOi7LXz Ii5w2rkFJ/DTqrv6AgR8hJlpbHEsBTbqO/tfKnEqSdUxuGHRYlOfFCxrh25b6kJCRTLG TzGg== X-Gm-Message-State: APjAAAXjTSy3xue4N+VwrEv8hDmIn5MElWrW6adH9BEj6ShjsCM5DQLi dLAg76lp6CGjAa62C3ml3hVEd2jGYD4dmy9SbjI= X-Google-Smtp-Source: APXvYqwQkd8vqUI6CVMaUd13M6j6wd4GMl6mwKgv9U8gcb9HhnqnO3RRDGM+4TLHVZ1rixVKFfYYqI6cPj6EZhMHXW0= X-Received: by 2002:ac2:539b:: with SMTP id g27mr15926171lfh.110.1573497456460; Mon, 11 Nov 2019 10:37:36 -0800 (PST) MIME-Version: 1.0 References: <6f18c4d8-e4a7-46be-ac81-032ef2d1e03f@www.fastmail.com> In-Reply-To: <6f18c4d8-e4a7-46be-ac81-032ef2d1e03f@www.fastmail.com> From: Bernard Aboba Date: Mon, 11 Nov 2019 10:37:25 -0800 Message-ID: To: Martin Thomson Cc: Qingsi Wang , Alex Drake , RTCWeb IETF , mmusic Content-Type: multipart/alternative; boundary="000000000000f289700597166c17" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 18:37:47 -0000 --000000000000f289700597166c17 Content-Type: text/plain; charset="UTF-8" Martin said: "Right now, there is a big hole that screams "key management problems" [BA] There is an RFC 4107 on Key Management Guidelines: https://tools.ietf.org/html/rfc4107 Section 2.1 states: Automated key management MUST be used if any of these conditions hold: A party will have to manage n^2 static keys, where n may become large. Any stream cipher (such as RC4 [TK ], AES-CTR [NIST ], or AES-CCM [WHF ]) is used. An initialization vector (IV) might be reused, especially an implicit IV. Note that random or pseudo-random explicit IVs are not a problem unless the probability of repetition is high. Large amounts of data might need to be encrypted in a short time, causing frequent change of the short-term session key. Long-term session keys are used by more than two parties. Multicast is a necessary exception, but multicast key management standards are emerging in order to avoid this in the future. Sharing long-term session keys should generally be discouraged. The likely operational environment is one where personnel (or device) turnover is frequent, causing frequent change of the short-term session key. On Tue, Nov 5, 2019 at 7:16 PM Martin Thomson wrote: > On Wed, Nov 6, 2019, at 06:15, Qingsi Wang wrote: > > On the key management, we think this should be deferred to > > implementations, given different options to solve this problem. Chrome > > enterprise policy is currently an example for such a solution in > > managed environments, and it allows admins to push configuration > > settings to managed endpoints. > > If there is an assumption that key provisioning works this way then I can > see how you reached this conclusion. I think that you need to be very > careful to describe how that constrains the design in the draft though. > Right now, there is a big hole that screams "key management problems". I > wasn't asking you to define the key management system, just to articulate > what properties this design assumes and maybe offer some guidance for > implementation. If this is as simple as you describe, that's great. > > I don't think that it is that simple - this is a combination of policy and > context that is hard to get right. If I take that managed device home, why > would I hide my address? Or, why would I share my address with my > colleagues? > > Finally, you are talking about a secret that many people will know. For > instance, I can easily imagine people posting the Foo company corporate > shared key on forums to aid in debugging. > > > As for errors from key rotation, MAC verification will cause such > > candidates to be discarded, and clients will fall back to mDNS, STUN, > > or TURN as appropriate. If we feel like that we need to solve this > > problem more thoroughly, some implementation guidelines can also be > > included regarding maintaining a brief key history and using trial > > decryption as needed. We'd appreciate suggestions on further improving > > these guidelines. > > For the very constrained configuration you describe, it might be > appropriate to rely on trial decryption, but that assumes that all > deployments will be able to manage with a very simple scheme. That's > rarely appropriate in the general case. I'd suggest that some sort of key > identifier is probably necessary. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000f289700597166c17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin = said:=C2=A0

"Right now, there is a big hole that sc= reams "key management problems"

[BA] The= re is an RFC 4107 on Key Management Guidelines:=C2=A0


Automated key ma=
nagement MUST be used if any of these conditions hold:

      A party will have to manage n^2 static keys, where n may become
      large.

      Any stream cipher (such as RC4 [NIST], or AES-CCM
      [WHF]) is used.

      An initialization vector (IV) might be reused, especially an
      implicit IV.  Note that random or pseudo-random explicit IVs are
      not a problem unless the probability of repetition is high.

      Large amounts of data might need to be encrypted in a short time,
      causing frequent change of the short-term session key.

      Long-term session keys are used by more than two parties.
      Multicast is a necessary exception, but multicast key management
      standards are emerging in order to avoid this in the future.
      Sharing long-term session keys should generally be discouraged.

      The likely =
operational environment is one where personnel (or
      device) turnover is frequent, causing frequent change of the
      short-term session key.


On Tue, Nov 5, 2019 at 7:16 PM= Martin Thomson <mt@lowentropy.net<= /a>> wrote:
O= n Wed, Nov 6, 2019, at 06:15, Qingsi Wang wrote:
> On the key management, we think this should be deferred to
> implementations, given different options to solve this problem. Chrome=
> enterprise policy is currently an example for such a solution in
> managed environments, and it allows admins to push configuration
> settings to managed endpoints.

If there is an assumption that key provisioning works this way then I can s= ee how you reached this conclusion.=C2=A0 I think that you need to be very = careful to describe how that constrains the design in the draft though.=C2= =A0 Right now, there is a big hole that screams "key management proble= ms".=C2=A0 I wasn't asking you to define the key management system= , just to articulate what properties this design assumes and maybe offer so= me guidance for implementation.=C2=A0 If this is as simple as you describe,= that's great.

I don't think that it is that simple - this is a combination of policy = and context that is hard to get right.=C2=A0 If I take that managed device = home, why would I hide my address?=C2=A0 Or, why would I share my address w= ith my colleagues?

Finally, you are talking about a secret that many people will know.=C2=A0 F= or instance, I can easily imagine people posting the Foo company corporate = shared key on forums to aid in debugging.

=C2=A0> As for errors from key rotation, MAC verification will cause suc= h
> candidates to be discarded, and clients will fall back to mDNS, STUN, =
> or TURN as appropriate. If we feel like that we need to solve this > problem more thoroughly, some implementation guidelines can also be > included regarding maintaining a brief key history and using trial > decryption as needed. We'd appreciate suggestions on further impro= ving
> these guidelines.

For the very constrained configuration you describe, it might be appropriat= e to rely on trial decryption, but that assumes that all deployments will b= e able to manage with a very simple scheme.=C2=A0 That's rarely appropr= iate in the general case.=C2=A0 I'd suggest that some sort of key ident= ifier is probably necessary.

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000f289700597166c17-- From nobody Mon Nov 11 10:59:17 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2B1208ED for ; Mon, 11 Nov 2019 10:59:09 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKyimyOhQr6M for ; Mon, 11 Nov 2019 10:59:07 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 42FAF1209DF for ; Mon, 11 Nov 2019 10:59:07 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id ay6so8181766plb.0 for ; Mon, 11 Nov 2019 10:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lFmw6ipAwL19dSPjd2i8sxGVBkVKLipvEfnPEbKr8jg=; b=Vanmz+DPgjMQKQLnoKQauJfjtLDy2gBeGwrUa4dmYN82LF2iodsMeKp8oJxJ/ySzOM wHhaoTI9HWjRt11d+kIMHzmuc84jrCHFgDigEDGYBwvlUwChYjz0jHns0BkIdJQytVQG /eHHqGx9kC1SMHmp+MEj/3V83rQR3eOIlwTngKakgK/XeqgZ8IAqi8ba1rmTcXpYEr4z NYwGTMvQrvIB1cLaD6a/kbipU0PBBuLQxlqhEHJwYRyrxmoC7fWhBytcQJUaRMd97KPC ttfQTYZl6zwds6v9pVQw2YTZwMqsLRqKEjeWDrkeiC7EEC+too6n82wNCVXVnqRZHgMC rzLQ== 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=lFmw6ipAwL19dSPjd2i8sxGVBkVKLipvEfnPEbKr8jg=; b=JAkenNpCaaKbTDATYC7Gg8aFpE1DbQko4DeehwGKolVrmp+2Rlk7bpn/ZJGFwBBAn1 RWZVTSEiaLu3Gt8UbXWWVUYMrJD7wiIO6MALGx5v5tsxf2MPiOGaZlWw0S80e8Leelfm +vsj/4Tj1ndL1J5l67XkSXiAswF/05ZduJNkZg8u0v73ReSFfHypoDlZWXOUL4k6z447 uYTrWqRsxCZz0Lie0zx0RKLz6k9JtRXV3mShdTmXY56FAQZS1NVqK97Oux52wKwgC49B DWjSHNA4Exn/PjLDq9f3fHRwlhaIRtyD0BxyIJXLtNR2vSr8NacWnBp2YQW4vF3HNazr OsVw== X-Gm-Message-State: APjAAAWCmOrUxeh7GiQ42iqwU9Ndf7xFujcfBLvdYTM9qI4A6nw3kyZw J405qiVU12jfooaECU4ei3jhhtTeO4U= X-Google-Smtp-Source: APXvYqwbOGx/KET1xhmnX3BKyCyvq0jzS/Y0ZYKt9rJGnNfp93q68VtLggAA25Q7kKQdf9/Q88yRfg== X-Received: by 2002:a17:902:8f94:: with SMTP id z20mr27278661plo.21.1573498746223; Mon, 11 Nov 2019 10:59:06 -0800 (PST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com. [209.85.210.174]) by smtp.gmail.com with ESMTPSA id m65sm572782pje.3.2019.11.11.10.59.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 10:59:05 -0800 (PST) Received: by mail-pf1-f174.google.com with SMTP id 193so11236539pfc.13; Mon, 11 Nov 2019 10:59:04 -0800 (PST) X-Received: by 2002:a17:90b:110f:: with SMTP id gi15mr690084pjb.128.1573498744529; Mon, 11 Nov 2019 10:59:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 11 Nov 2019 13:58:53 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Ted Hardie , Alex Drake , RTCWeb IETF , Qingsi Wang , mmusic Content-Type: multipart/alternative; boundary="000000000000b8eccd059716b948" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 18:59:10 -0000 --000000000000b8eccd059716b948 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 7:13 PM Justin Uberti wrote: > > On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount wrote: > >> One thing that I thought would make all DNS in ICE candidate work better >> is some sort of "addrtype" candidate extension. >> >> It would work like: >> a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host addrtype inipv4 >> a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns4 >> a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns6 >> a=candidate:1 1 udp 2122262783 <(212)%20226-2783> >> 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host addrtype dns6 >> >> This way client would know which DNS request (A or AAAA) should be used >> to resolve the DNS name in the candidate. c= and m= line can also be >> generated unambiguously if address type is specified in the candidate and >> is not determined during resolution time. >> > > I think this might be useful, but it seems separate from the encryption > proposal, so let's discuss that in its own thread. > We will need to update ice-sip-sdp to allow DNS (including mdns and encrypted candidates). I think adding addrtype should address most of the issues with the existing DNS ice-candidates. We just need to make sure that people who care about DNS in ice candidate review it. For encrypted candidate, distribution of the actual encryption key can be >> implementation specific, but there should be some way to identify which key >> is used to encrypt the candidates. This will likely require additional >> candidate extension, such as "keyid": >> >> a=candidate:1 1 UDP 2130706431 2122262783 <(212)%20226-2783> >> 8c9bd03bb7a5a76a5803eebc688f0388.fa991acbdf116f6b72fd3a781174cd58.local 8998 >> typ host addrtype dnsipv6 keyid foo.bar.com >> >> This way you do not need an additional gTLD and encrypted candidate can >> be identified using the extra candidate extension. >> > > Not sure we need a keyid, but marking the encrypted candidate type somehow > in the candidate-attribute seems like a good thing to consider. > What I am concerned about are graceful key updates in the enterprise. This might require several keys to be operational at the same time with one key used for encryption and multiple keys used to de-crypt. Furthermore, local addresses before encryption should be prefixed with some >> random nonce so that encrypted local addresses cannot be used for >> fingerprinting. >> > > This is already described in the draft - the ice-pwd value is used for the > IV, which ensures the encryption output will be different across > PeerConnections. > Clear. I missed it on the first read. Finally, probably in W3C we need to discuss if any API updates are required >> to enable encryption in ICE candidates. I think an additional option to >> createOffer/createAnswer that specifies which key to use for candidate >> encryption would probably be the best solution. Distributing actual keys >> can then be done via enterprise policies or keys can be pre-provisioned >> with web browsers via some sort of enrollment mechanism. >> >> >> Can you explain more as to why? We don't want app developers to have to > care about this, or else this solution will never get off the ground. > I guess we can get away without the API and keep key management completely outside of JavaScript. _____________ Roman Shpount --000000000000b8eccd059716b948 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 5, 2019 at 7:13 PM Justin Ube= rti <juberti@google.com> wr= ote:

On Tue, Nov 5, 2019 at 1:= 30 PM Roman Shpount <roman@telurix.com> wrote:
One thing that I thought would make a= ll DNS in ICE candidate work better is some sort of "addrtype" ca= ndidate extension.=C2=A0

It would work like:
a= =3Dcandidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host addrtype inipv4=
a=3Dcandidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns4
a= =3Dcandidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns6
a=3Dcandidate:1 1 ud= p 2122262783 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host= =C2=A0 addrtype dns6

This way client would know which DNS reque= st (A or AAAA) should be used to resolve the DNS name in the candidate. c= =3D and m=3D line can also be generated unambiguously=C2=A0if address type = is specified in the candidate and is not determined during resolution time.=

I think this might be usef= ul, but it seems separate from the encryption proposal, so let's discus= s that in its own thread.=C2=A0

We will need to update ice-sip-sdp to allow DNS (including mdns and= =C2=A0 encrypted candidates). I think adding addrtype should address most o= f the issues with the existing DNS ice-candidates. We just need to make sur= e that people who care about DNS in ice candidate review it.

=
=
=C2=A0For encrypted candidate, distribution of the ac= tual encryption key can be implementation=C2=A0specific, but there should b= e some way to identify which key is used to encrypt the candidates. This wi= ll likely require additional candidate extension, such as "keyid"= :

a=3Dcandidate:1 1 UDP 2130706431=C2=A02122262783 8c9bd03bb7a5a76a580= 3eebc688f0388.fa991acbdf116f6b72fd3a781174cd58.local=C2=A08998 typ host addrtype dn= sipv6 keyid foo.bar.com


=

What I am concerned about are graceful key updates in t= he enterprise. This might require several keys to be operational at the sam= e time with one key used for encryption and multiple keys used to de-crypt.=

Furthermore, local addresses before en= cryption should be prefixed with some random nonce so that encrypted local = addresses cannot be used for fingerprinting.

This is already described in the draft - the ice-pwd valu= e is used for the IV, which ensures the encryption output will be different= across PeerConnections.


=
Finally, probably in W3C we need to discuss if any API updates are req= uired to enable encryption in ICE candidates. I think an additional option = to createOffer/createAnswer that specifies which key to use for candidate e= ncryption would probably be the best solution. Distributing actual keys can= then be done via enterprise policies or keys can be pre-provisioned with w= eb browsers via some sort of enrollment mechanism.


Can you explain more as to why? We don't wa= nt app developers to have to care about this, or else this solution will ne= ver get off the ground.=C2=A0

=
I guess we can get away without the API and keep key management comple= tely outside of JavaScript.
_____________
Roman Shpount=C2=A0
--000000000000b8eccd059716b948-- From nobody Tue Nov 12 08:10:21 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361D5120108 for ; Tue, 12 Nov 2019 08:10:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 CxKKYsizfRHV for ; Tue, 12 Nov 2019 08:10:10 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 5C6F012006E for ; Tue, 12 Nov 2019 08:10:10 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id o82so4568317vka.5 for ; Tue, 12 Nov 2019 08:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JPXEr/lFCD5EV199rQ0vo9MiJC/OE1FvtmhLFz9x+IQ=; b=ds4JCYQT4bBQUTbCGuw050CoLFV6c2Pog+V0DYI/0+F8rPseqvR//blmYumhJYu+Ir Ic+IMDRioJpnQHPxK28oZMf6Ft1yQLDzpGACmif4VVDL6pK+snxnH6EE+I4c6lUoMVkd 3a+jGTH8no/KTmAulJVx1TO45OGctvl2HZmkfcQit+flsfIdiQvjsNmKog+/bUCgFfYD ySeNlDrn+uSMTQ8Qq2R4Nt+qIbIxpE7w0CdBU2vaLjqiGNb8fV9rZvJ2LPt9ZRlwB6eb L7cBV/MD58mzmarqXFsHWeVsNHpGiU5xnzG+0A5reE4qAapkpmEAKbUjqCOHC7jXgS2a cbVA== 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:content-transfer-encoding; bh=JPXEr/lFCD5EV199rQ0vo9MiJC/OE1FvtmhLFz9x+IQ=; b=UXYDLgWPeqyKNREXo09ClY2sSlIzWQOLkWMmOGA3iyklrYJ8MYAm9X9dzPjckhQ+lp 94X3/Kh61HmZxJDqHalEg4gC5p3HUBGhpvA9fEXA15TrcYPEOIuiLcGK0V8RD7NdA+sQ 4bJMS0AKIoSfgoYSO8tBzXiKnDA8ZP8oJ76Z2s+ddFr+jBInRg5KYksvMDY9Q4TuX+Wv bzuztbqeaGLBrAaNBqeypY6iXSzvCbu9nZKJvRayj6PbWV9TSvVk4wQ0ikTj3nTw3Dtw OY9D2iIoB9mbEO1vb5vN5UQzya75Ug/YAAC/ULajoQbZqldeKTiLb14gKEqE+Y1RjTMD kFzg== X-Gm-Message-State: APjAAAW4rSg11KlFKlU7GviN+JMUKIhEI1WgAmXG7uxJw4aGnDW0U2YE V1JkLXEhXMfPf6HP3B7Vbfjcm7THoyBaMX9jY5OTJw== X-Google-Smtp-Source: APXvYqzcIqeP4tDAI9eZH7FDBcxMg07BIYsvHVxsdn6HbqilVj7iyxJHhiLfqnt46kKsvgdRiurua0jsN1mxwFFOzZQ= X-Received: by 2002:a1f:14d4:: with SMTP id 203mr21371719vku.40.1573575008982; Tue, 12 Nov 2019 08:10:08 -0800 (PST) MIME-Version: 1.0 References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> In-Reply-To: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 12 Nov 2019 17:09:57 +0100 Message-ID: To: Sean DuBois Cc: Qingsi Wang , Alex Drake , RTCWeb IETF , mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 16:10:13 -0000 On Mon, 11 Nov 2019 at 10:04, Sean DuBois wrote: > Have you thought about/explored encrypting the entire SessionDescription? We can already use TLS (HTTPS or WSS) to exchange SDPs (or "parameters" that the receiver will use to build a "remote SDP"). We don't need yet another encryption layer to transmit a "blob" / "string" between endpoints. > There might be some issues I am not aware of, but it would give us some > other nice things! > > * No more SDP munging (or at least make it harder) > - People shoot themselves in the foot constantly by editing things We don't do it for fun. > - Will push people to communicate API needs more, instead of more hack= s Breaking the existing ability (even if hacky) to set stereo, inband FEC, DTX, etc. for OPUS transmission by making it impossible does not seem a good idea. Yes, a better and real API is needed, but that does not justify breaking the only way we have to do it nowadays. --=20 I=C3=B1aki Baz Castillo From nobody Tue Nov 12 11:23:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8799120807 for ; Tue, 12 Nov 2019 11:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGbhLlBE2awS for ; Tue, 12 Nov 2019 11:23:35 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 3C1C6120974 for ; Tue, 12 Nov 2019 11:23:30 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id s5so16615272iln.4 for ; Tue, 12 Nov 2019 11:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2CIoQGxUXMZKrIzmJ6NSZR+swZG0iaTUKy+tl55CFpc=; b=N8uubtjsSwMwZ+jKLndNugeS5BgUyPAKsxO0rbP9gv+NmG+0613XUrAxEP0+Talbwb 7PNZ6GAgXSAxNZ9en18SKjAGqomT4LfthE7wY7IgYiOWm/dtl3QOx+qpUOyL2WV7h2Vx IMUqtBAWyI8xkQIiOt0q9sF37duykgPU8OgPb05OJc58Zv9k+mXcneKiOeK2NMLjWA+y GakyOWEaF7CHZomV1VGu2hosyyse3NCT/yClknn/21EKsD6uXvlDD0xsAMLkhtjC/hTg COgml70ZiphHoaXezsfK3mmZb4SPdGBJLEwTizZt2aRB0t97owOCv+Ak8O+Ll4ENF3/T 5atQ== 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=2CIoQGxUXMZKrIzmJ6NSZR+swZG0iaTUKy+tl55CFpc=; b=hH2ifsVZ6pUwHUiSrTUf36napC3WPdyyBh89uSXuUAvrPMn6Nl/9LH/Qc482bz9p8r QM0birEZJm+0sX+1f+aHwZVosdKeknl2ySyTy7up9fJUFv6OBW5ApYGKbP6B8y/+KHgp up38ZyZ1DBjIXqgt/bCbcwlbEhRY/5chZS1l85xcBbfW2MCB+adR+eap3c+5LyhyMMdv pVI1kAigiufqnwNTlGkdkfkyYMdEQNo34s45pa+JQSNev2Nh7Q7oXkR6nehVowuPd4j/ Ayll0LAwFvass34VOmAiwHwC9yo91PElkA8rp4jaxC4hjnFYtqBcmjXzsriMOxt5QptR UUGQ== X-Gm-Message-State: APjAAAVEMnGoFjGPcLFSYKBB/AUzs1h4a6gkFSzftB98CIzV3J61WFSi ax8gaN9TU150ULl4ypkhZrfk5Kah9LCMDgwo+L90lw== X-Google-Smtp-Source: APXvYqxHaO+mKQJLkmDdEdPcD2Kc9Ub6Y2cyQj62lRDwLhd2e0J4fy55cH9Ail8oYQZXvty3Ry5fca59bwW+Z7reSNk= X-Received: by 2002:a92:8983:: with SMTP id w3mr40391118ilk.108.1573586608950; Tue, 12 Nov 2019 11:23:28 -0800 (PST) MIME-Version: 1.0 References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> In-Reply-To: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> From: Justin Uberti Date: Tue, 12 Nov 2019 11:23:16 -0800 Message-ID: To: Sean DuBois Cc: Qingsi Wang , Alex Drake , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000d9f8a605972b2e7d" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 19:23:38 -0000 --000000000000d9f8a605972b2e7d Content-Type: text/plain; charset="UTF-8" As for precedent for managing Chrome in an enterprise environment, https://cloud.google.com/docs/chrome-enterprise/policies/ gives a rundown on what is currently supported, and is the easiest way to do this sort of thing. DHCP could also be used, but requires OS support. On Mon, Nov 11, 2019 at 1:04 AM Sean DuBois wrote: > On Fri, Nov 01, 2019 at 01:06:22PM -0700, Qingsi Wang wrote: > > Greetings. > > > > This draft ( > > > https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) > > proposes a complementary solution to the mDNS candidate detailed > > in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed > > networks. IPs of ICE candidates are encrypted via PSK and signaled as > > pseudo-FQDNs in this proposal, and it aims to address the connectivity > > challenge from the mDNS technique in these managed environments. The > > current work on this draft is tracked in > > https://github.com/tQsW/encrypted-ice-candidates. > > > > Regards, > > Qingsi > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > Hi, > > Really excited to see this RFC. This is a real pain point, and glad it > is being addressed. I implemented this over the weekend and everything > fell into place. > > Have you thought about/explored encrypting the entire SessionDescription? > There might be some issues I am not aware of, but it would give us some > other nice things! > > * No more SDP munging (or at least make it harder) > - People shoot themselves in the foot constantly by editing things > - Will push people to communicate API needs more, instead of more hacks > > * Host candidates aren't the only thing you can be fingerprinted off of > - Agents craft very different SDPs (FireFox vs Chromium) > - SDPs reveal hardware attributes (Chromium Android has H264 only with > HW Accel) > - Agent may have different experiments/settings (attributes at > session/media level) > > * Changes to candidate strings is going to cause more breakage > Maybe this doesn't matter as much, but I anticipate this is going to > cause more bugs. Some clients/SFUs/MCUs... blew up when mDNS came out, > > I bet another change is going to cause the same thing. It sounds like > this will be much less likely because people will need to setup > something up to get the PSK going. > ------- > > I would love to see example implementations of the Key Management. Is > there any precedent for configuration of the WebRTC agent in managed > networks? > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000d9f8a605972b2e7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As for precedent for managing Chrome in an enterprise envi= ronment,=C2=A0https://cloud.google.com/docs/chrome-enterprise/policies/=C2= =A0gives a rundown on what is currently supported, and is the easiest way t= o do this sort of thing.

DHCP could also be used, but re= quires OS support.

On Mon, Nov 11, 2019 at 1:04 AM Sean DuBois <sean@pion.ly> wrote:
On Fri, Nov 01, 2019 at 01:06:22PM= -0700, Qingsi Wang wrote:
> Greetings.
>
> This draft (
> https://tools.ietf.org= /html/draft-wang-mmusic-encrypted-ice-candidates-00)
> proposes a complementary solution to the mDNS candidate detailed
> in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed
> networks. IPs of ICE candidates are encrypted via PSK and signaled as<= br> > pseudo-FQDNs in this proposal, and it aims to address the connectivity=
> challenge from the mDNS technique in these managed environments. The > current work on this draft is tracked in
> https://github.com/tQsW/encrypted-ice-candidate= s.
>
> Regards,
> Qingsi

> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
Hi,

Really excited to see this RFC. This is a real pain point, and glad it
is being addressed. I implemented this over the weekend and everything
fell into place.

Have you thought about/explored encrypting the entire SessionDescription? There might be some issues I am not aware of, but it would give us some
other nice things!

* No more SDP munging (or at least make it harder)
=C2=A0 =C2=A0- People shoot themselves in the foot constantly by editing th= ings
=C2=A0 =C2=A0- Will push people to communicate API needs more, instead of m= ore hacks

* Host candidates aren't the only thing you can be fingerprinted off of=
=C2=A0 - Agents craft very different SDPs (FireFox vs Chromium)
=C2=A0 - SDPs reveal hardware attributes (Chromium Android has H264 only wi= th HW Accel)
=C2=A0 - Agent may have different experiments/settings (attributes at sessi= on/media level)

* Changes to candidate strings is going to cause more breakage
=C2=A0 Maybe this doesn't matter as much, but I anticipate this is goin= g to
=C2=A0 cause more bugs. Some clients/SFUs/MCUs... blew up when mDNS came ou= t,

=C2=A0 I bet another change is going to cause the same thing. It sounds lik= e
=C2=A0 this will be much less likely because people will need to setup
=C2=A0 something up to get the PSK going.
-------

I would love to see example implementations of the Key Management. Is
there any precedent for configuration of the WebRTC agent in managed
networks?

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000d9f8a605972b2e7d-- From nobody Tue Nov 12 14:40:01 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60981120130 for ; Tue, 12 Nov 2019 14:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 7U7l-Y_DxZxt for ; Tue, 12 Nov 2019 14:39:57 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 2C34412011D for ; Tue, 12 Nov 2019 14:39:57 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id p20so317535qtq.5 for ; Tue, 12 Nov 2019 14:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wH9jgUkK0upK2ssqv2Mr2vgPLeZCy43NAVOyWhXFYM4=; b=IlF6l0KhWEsw1xdJvxGEyiTnd4y1b37CSracq+OZz9IgY8zWK2stBNFTpRpvoToGB3 PtSsdWZ5QMGoRklJtV45Gsk4kWNnD5lFy4dC7JwVRBJkwwMLQDgolbhmXeuG52lr6hck otnh3dp/jkfomnXgpQHO19JAHeoiuHoWZikJJHsJ8F4F4is9m9GzM7dqaJzABzQQ4Lb4 EPllhXlv46edTuQIAp/zc7Kz4F8E4IixsSPJPtY7Z+sD1NTHj26gROW8AECYYTtIqpbr BnjLcxflykXDjLAyR5hOOAzGByG8A0oyXS5TQilvgxV4vr7xFjxi2SL6wuDEGjD/cImn qthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wH9jgUkK0upK2ssqv2Mr2vgPLeZCy43NAVOyWhXFYM4=; b=SQV5PpKKa48Fhij9RUq7zu0bXkYKO1hM1NtRNcHPkhOWMHxV6YceEGIulUjYn2O2GV 6ZmSxs1L07ZgW/U4pVLNYc1kQT0Ov9sP3gXnK3ODvhhGKBSkrikketCYJFMB/xyttOl2 QvZtB6u7OmLxD7s0c8w5CQf0a+2KvwWDpduiyI2EtIwTv1ggQx84n5ctZSNVfDrigKuv R4GYjIglcv1J3iXNuEM3rtZCh/CKpZkTfmSLqqD6DXBBB6hjP8mPXuM4Any2qmoMtPFg aYC6zIwfxlWUkfkqD2o9KRGEnTZdMw85Rblw+Zp8gshyok/BfOrk/BX6T/sb0YVcyJU8 IwOw== X-Gm-Message-State: APjAAAXzKS0q88HzxDrEpeJP+yz72dbMv69sxLS6YeiUjq5ggdrjjJoP Xv77ecpD3AmH/oWVwibv0MrshQ== X-Google-Smtp-Source: APXvYqxLCLWK5Tl/ZwA0vZn8ea/uK4uuC7LUHnNDtcLpXmDoFxEWEHFFWDZ9tPBE1hTjYnzXb85pMQ== X-Received: by 2002:ac8:6919:: with SMTP id e25mr5904415qtr.199.1573598395952; Tue, 12 Nov 2019 14:39:55 -0800 (PST) Received: from siobud.com (mail.siobud.com. [165.227.221.230]) by smtp.gmail.com with ESMTPSA id a10sm140336qtd.29.2019.11.12.14.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 14:39:55 -0800 (PST) Date: Tue, 12 Nov 2019 22:39:53 +0000 From: Sean DuBois To: Harald Alvestrand Cc: Qingsi Wang , Alex Drake , rtcweb@ietf.org, mmusic@ietf.org Message-ID: <20191112223953.GA3851@siobud.com> References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <909be25d-740a-03fd-ecbf-f3fb73f0723d@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <909be25d-740a-03fd-ecbf-f3fb73f0723d@alvestrand.no> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 22:39:59 -0000 On Mon, Nov 11, 2019 at 11:59:22AM +0100, Harald Alvestrand wrote: > Den 11.11.2019 10:03, skrev Sean DuBois: > > On Fri, Nov 01, 2019 at 01:06:22PM -0700, Qingsi Wang wrote: > >> Greetings. > >> > >> This draft ( > >> https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00) > >> proposes a complementary solution to the mDNS candidate detailed > >> in draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed > >> networks. IPs of ICE candidates are encrypted via PSK and signaled as > >> pseudo-FQDNs in this proposal, and it aims to address the connectivity > >> challenge from the mDNS technique in these managed environments. The > >> current work on this draft is tracked in > >> https://github.com/tQsW/encrypted-ice-candidates. > >> > >> Regards, > >> Qingsi > > > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > Hi, > > > > Really excited to see this RFC. This is a real pain point, and glad it > > is being addressed. I implemented this over the weekend and everything > > fell into place. > > > > Have you thought about/explored encrypting the entire SessionDescription? > > This would destroy interoperability with any currently fielded > implementation, so it's unlikely to be popular. > It also requires setting up a shared key before you can exchange SDP, > which is a pain (as this draft makes clear). > These changes are already going to break interoperability. In a perfect world you can discard candidates that are invalid, but lots of bad code is just going to break. Maybe encrypting the whole SDP isn't the right answer. My concern is that we are going to revisit this issue again because of the points I called out, I would like to explore solving the root issue. > > There might be some issues I am not aware of, but it would give us some > > other nice things! > > > > * No more SDP munging (or at least make it harder) > > - People shoot themselves in the foot constantly by editing things > > - Will push people to communicate API needs more, instead of more hacks > > > > * Host candidates aren't the only thing you can be fingerprinted off of > > - Agents craft very different SDPs (FireFox vs Chromium) > > - SDPs reveal hardware attributes (Chromium Android has H264 only with HW Accel) > > - Agent may have different experiments/settings (attributes at session/media level) > > > > * Changes to candidate strings is going to cause more breakage > > Maybe this doesn't matter as much, but I anticipate this is going to > > cause more bugs. Some clients/SFUs/MCUs... blew up when mDNS came out, > > > > I bet another change is going to cause the same thing. It sounds like > > this will be much less likely because people will need to setup > > something up to get the PSK going. > > ------- > > > > I would love to see example implementations of the Key Management. Is > > there any precedent for configuration of the WebRTC agent in managed > > networks? > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > From nobody Tue Nov 12 14:52:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71612011D for ; Tue, 12 Nov 2019 14:52:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 Rkw4LJX9BXQd for ; Tue, 12 Nov 2019 14:52:48 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5E2120089 for ; Tue, 12 Nov 2019 14:52:48 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id z24so12847415pgu.4 for ; Tue, 12 Nov 2019 14:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=BSTR2hBwqXwePaahrBmKbL19RTx2qzudX5SkW+LKa+E=; b=P1t/EOMfBS2TSDtY2QORsZwpZOUxjV4KuZPTcQWyXdnEhZXl3dv14FsJZPSq3HfgQP E6PXbaejByeYMrcZrngMmMzYO52mI6NjbbLobepXfuGL09qmHUenYG2GnX+pFJ/k1KIo OTQMQ5JuoQt+rTv7Ch9ew+ylb1DKXsxudtpM2ifVTTCpBNbevoZGxkcEboWtWAdhWRPS t8A8Qh3i9gH3LAPvlHAd3N6i8R48oWmUa1o1b7yGDBc4a7ptNDUcligbc4lFvRGEt30l oqlWEwKDP42qSOEVy1yiTjr3dTfT9zfG47j0KcS28oYW4wCc3MLaY4U5I5UNS/NhI+wm bG5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BSTR2hBwqXwePaahrBmKbL19RTx2qzudX5SkW+LKa+E=; b=tKvQviuZV/Di7veowzsA6Bdap/6JIcLUnrDYgpzcZR04zq2UMgb7caNHcW3BP4/wEd G9Ggw4OQXCTbVSVV86WEYFE3GQOpHWSTOA5BFftMD8Y/9yTmDX+xQTscmFvX5OegIYFB JT5eziVsDY3bY9xaz48+zoyUE9OLXbvFYLvp/4jC/QEeEpJHJvsviq74KQDVdn5Qy8zC eIL8jdVbPDuPVFeY+s+JUYcnkc0R0KDvwdXTisDhqNy6Gj+HWnuMw8mah74OmOXfHWSu Q8Z80z29DPpA6Sf3MN5w4hY6IPg4/LK5l610Xoo53tV/7WB2kgvOCEsH9OsNjlA3SHd/ sXKw== X-Gm-Message-State: APjAAAUJ6A80QC0yuk/6Wh+sEd4GfjZjPhc1Cf8YxKGzLjzaaRsgrd4s GKyPMm9pbkZ1MKBzTZ3iM0OIQQ== X-Google-Smtp-Source: APXvYqxbMfzGEzlq0/bsDUsjoIIcEL6hRxsWEh0x+bXqWjaSnYCMmxQpob9A4t5fOxJBnGQL0h4nPQ== X-Received: by 2002:a63:c103:: with SMTP id w3mr38030774pgf.275.1573599168156; Tue, 12 Nov 2019 14:52:48 -0800 (PST) Received: from 38f9d359441f.ant.amazon.com (54-240-196-190.amazon.com. [54.240.196.190]) by smtp.gmail.com with ESMTPSA id u3sm37949pgp.51.2019.11.12.14.52.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 14:52:47 -0800 (PST) Date: Tue, 12 Nov 2019 14:52:47 -0800 From: Sean DuBois To: Christer Holmberg Cc: Qingsi Wang , Alex Drake , "rtcweb@ietf.org" , "mmusic@ietf.org" Message-ID: <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 22:52:51 -0000 On Mon, Nov 11, 2019 at 11:28:19AM +0000, Christer Holmberg wrote: > HI, > > > Really excited to see this RFC. This is a real pain point, and glad it > > is being addressed. I implemented this over the weekend and everything > > fell into place. > > > > Have you thought about/explored encrypting the entire SessionDescription? > > There might be some issues I am not aware of, but it would give us some > > other nice things! > > > > * No more SDP munging (or at least make it harder) > > - People shoot themselves in the foot constantly by editing things > > People don't modify SDP just because they can - they make it in order to make things work. > > Regards, > > Christer > > > Agree, but we are failing developers every time they had to do this. WebRTC agents should provide standardized APIs so they don't need to touch the SDP to make things work. Maybe I am wrong, but when developers using Pion WebRTC do SDP munging I try to figure out what APIs they need. I have no way to get them into the W3C though, so far I just have a bucket of 'Proprietary APIs I wish I could figure out how to upstream. From nobody Tue Nov 12 14:56:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5091212011D for ; Tue, 12 Nov 2019 14:56:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=aliax-net.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 eL1kJ0a-7zwo for ; Tue, 12 Nov 2019 14:56:09 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 E80EC120018 for ; Tue, 12 Nov 2019 14:56:08 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id e205so111492vke.2 for ; Tue, 12 Nov 2019 14:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W3bsYYy6Li2gKYF6dLH8m0bKdjombawtidzFWja4u5A=; b=ish1pKDjFaIS+BdUWTJRBFZTjQfOfnwgD3fMXuSqfwjY9zGnoB7nsAOvPW0PNGJybP OVEeeJlBgZrau75ArGLZyst65uWJfagpRWn+QmEoohtEEi0AS8ft4pTc/XSnPGALQTeC dyngIfigBzXZaUxG7A5/A68AzCdD1YJV/+CDjyLTfbt+9Buh+7/jzfSug7ddxkln/G/Z uiGO6HRktg2A7JfP9W8uibqUQikHCydgQOW0ZRyQlzPB7x4Xs8DCt35E1ebC5AEpLh0X Twk1wi6OQ3Su2rkUV6clS3gYEerCFejEUKLoUN8wdUWZsFOaW8sRd6VsxUzU3QjRYN/K owGA== 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:content-transfer-encoding; bh=W3bsYYy6Li2gKYF6dLH8m0bKdjombawtidzFWja4u5A=; b=iXUUQ3PiGAF7K4J9PATa9QT8I5M++i6zKzUCjDvINbt/dCw4JS27Y12yfjl82SGUal g3do8o8NewUKyq5AxOWa+7wGHP6QgsB/bjo7+Sii4i4SyFMc7p6UBzCopFHF/e65Qaor 65asM6wSk+sprGDKdan2ilqcQES59ONRBw1Gu58dWOX2Llio5kv3M4STu7+MkKBhRC/z KrBH9d7zwBZA0nWGeoBx4SHMEUbHExtxevgrn+pMd8sxtm3ZTgvUO0M86TlIDaPVpuJg WdM8qdGYGFDXYaydQYW71XSAjwWlCRPOVRJ9dfOdA021Nw38hFzk6zCcFlXmNK10Hz9G FpGQ== X-Gm-Message-State: APjAAAWwef2UnMT4YwZkYdK66zlPWqdQwRR92Y/D05DxwbzQdtwBwJMj xWxHSZDnXf2D2JyyAMa9tIbL1rraySTr2Qm3WrYZjQ== X-Google-Smtp-Source: APXvYqzc36SHehCMfOTkvwvDlMEIHcHZsDZhMOusuz6mOl9koff6NDbNegyCd30N1NFT2OALnXUM7+22cd+R7t8bfvY= X-Received: by 2002:a1f:6a43:: with SMTP id f64mr23620857vkc.96.1573599367635; Tue, 12 Nov 2019 14:56:07 -0800 (PST) MIME-Version: 1.0 References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> In-Reply-To: <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 12 Nov 2019 23:55:55 +0100 Message-ID: To: Sean DuBois Cc: Christer Holmberg , Alex Drake , "rtcweb@ietf.org" , Qingsi Wang , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 22:56:11 -0000 On Tue, 12 Nov 2019 at 23:52, Sean DuBois wrote: > Agree, but we are failing developers every time they had to do this. > WebRTC agents should provide standardized APIs so they don't need to > touch the SDP to make things work. I do not transmit SDPs in the wire but parameters, and then build the "remote SDP" locally just to make the PeerConnection API happy. Can we assume then that "encrypted SDP" makes absolutely no sense? I do agree that a MUCH better WebRTC API is needed, but "SDP encryption" has zero relationship with that. --=20 I=C3=B1aki Baz Castillo From nobody Tue Nov 12 15:08:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1AB1200B9 for ; Tue, 12 Nov 2019 15:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 HP4RXESm7Skg for ; Tue, 12 Nov 2019 15:08:29 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 D7F7F12008D for ; Tue, 12 Nov 2019 15:08:29 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id 3so157300pfb.10 for ; Tue, 12 Nov 2019 15:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=YjB6aRduZ/jSOJ/feSHWQ5fiaI80R3NIHtkpPsITxgY=; b=RN9kao7P5gZCXKWeiMq1/qrBBdig+XV1rGWIZWgjapTNpZV8bUtlspa8s5nKylPyoy 5bv3yze+R5pwsJid5AViKgrHGpxm7R9JlNpVRF+Z1kSVS+bObn4hqaxeg6KCx6rS7982 IAODDbqMQKYvb9WKFF4ByZI9ZnrpowxeUPlNKk0XlIpZ0QxOEk/IrJ3FOIo4TBLtsMLM m5wfELDqUbf2KdIQ/VZZ7ywfrZPheLbCdJlTNAvaq0/F/Xfj/aJtNNWMiVlUgrHQkRqt BXc7TqIBxY79TS71MXmUOHocUThw1JyjKVbq6QJ/cuS0mC9VjFRZh3K9VoP8uUwHgk2i DNCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=YjB6aRduZ/jSOJ/feSHWQ5fiaI80R3NIHtkpPsITxgY=; b=YoNzZFh5LhNk2NtDuYIHsMC5F30F4k4Uqr9fweK8aG4MwTnC8SRHaeptr7RwGiWT3b Dn9uyahJ8W8cQtemeMsK8bzKX9yAxO2HW+0eIqrfgWhaqim1Iusn+bASDLCtyWk14H2g Mp1i4xAbgjTDkUKxRhfMwQDxuhobR/Xv7Sjkwj+bGcsEsXSLrpf+1FFNa1CPUD0BYsps iQwfh9klDDHZPjQP26pdDCjBlZz9KadF6HY8hW8dpErIdIEbk3PH/iItBBZtVAbSu9KC hroYkaPbFXJovHd7XddJYd68scwDV0H7dIhDw52/pm6btmok+lMWTEsiQ/0Wo1c8IP2W c4gA== X-Gm-Message-State: APjAAAXT/L+5QgoDYcyniOcqhqzqK9pLsCPmk7OxIuOx9MXzfUNRtGeM ml+XZ9sw2MTe7DVkj1GjK9Fz5g== X-Google-Smtp-Source: APXvYqw/auxTJYm92QaxYChdIg6pvvYs5n74fMaqGissq4KNi0z37dzwPwbc+OjqPtC0iL6DpB61lA== X-Received: by 2002:a17:90a:380d:: with SMTP id w13mr371887pjb.133.1573600109330; Tue, 12 Nov 2019 15:08:29 -0800 (PST) Received: from 38f9d359441f.ant.amazon.com (54-240-196-190.amazon.com. [54.240.196.190]) by smtp.gmail.com with ESMTPSA id j4sm165376pjf.25.2019.11.12.15.08.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 15:08:28 -0800 (PST) Date: Tue, 12 Nov 2019 15:08:28 -0800 From: Sean DuBois To: =?utf-8?B?ScOxYWtp?= Baz Castillo Cc: Christer Holmberg , Alex Drake , "rtcweb@ietf.org" , Qingsi Wang , "mmusic@ietf.org" Message-ID: <20191112230828.cuyvl4h2rqzuz3yl@38f9d359441f.ant.amazon.com> References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 23:08:31 -0000 On Tue, Nov 12, 2019 at 11:55:55PM +0100, Iņaki Baz Castillo wrote: > On Tue, 12 Nov 2019 at 23:52, Sean DuBois wrote: > > > Agree, but we are failing developers every time they had to do this. > > WebRTC agents should provide standardized APIs so they don't need to > > touch the SDP to make things work. > > I do not transmit SDPs in the wire but parameters, and then build the > "remote SDP" locally just to make the PeerConnection API happy. Can we > assume then that "encrypted SDP" makes absolutely no sense? I do agree > that a MUCH better WebRTC API is needed, but "SDP encryption" has zero > relationship with that. That is fine with me, I am not tied to a singular idea! I just want to accomplish the points in my original email. > > -- > Iņaki Baz Castillo > From nobody Tue Nov 12 15:15:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135DE12011D for ; Tue, 12 Nov 2019 15:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 HjEGep1ED_VB for ; Tue, 12 Nov 2019 15:15:08 -0800 (PST) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 A32F31200B7 for ; Tue, 12 Nov 2019 15:15:08 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id p24so189760pfn.4 for ; Tue, 12 Nov 2019 15:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=cSSbcqR/x1O9zSMSCF6lQ5IdU+2A962Htrog4J/eaDM=; b=obaZvDTjRQIU6W+oSvzQkWml0OwfCneFIWcHXSnKkMyVZ3xKALLslnXe+Jj++tP9yM gpPEv4pLwR1r64w9beIALX+3bJLtmrsEUXj+sMR5VX9XVtE6Ykpqm4QeF+ke+DzkLigM jEP8GsfADhmww2yI6YkVHTVb6W6IqrC9HIswsd6Oo4/1trGbZTBNmqB+nkFwL/27yQWW EZQJM51zTct/1NrD/2zt+LstM9GJlWO3SP7z33F4kgLiWwtMsQR9uvaEcQCWenkz90BL O2fHPkNV6lw504EN3fFQF2lwuf4PpSA3zKikMpsMU1XHKBsiovA3YWas0V8EycU8PGqa 3A0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=cSSbcqR/x1O9zSMSCF6lQ5IdU+2A962Htrog4J/eaDM=; b=RFKpPUy2YQNZ3YSiBsFxir04kVfrCg4joqigjioikBuZxk+b2w0kAJJcPqihkpoC3g WExf55DhqC4eZejFj74KxQmVEMh1qocS9EEDyBLP9ZI0u9KHayyH9BTO6v9cY3vqp9Xp vs0wESvZARgv2wprUWiqH9fYjLR/Ch0iXcOjmAhp8TpDc/oOuJmPm+v5ePP7Wm61KCAN W9x52EFQC3P86k7DWhNHkC+T6TsUUNRsU4mJykFXVLwW7wpryk/WjW8dLcG7jMeAMzP3 +RYb25oyq1CBmO0UdXftK999AL7s3Ved8ku8dvXaxW6QxXEm3ncG5uxDGNyzCAnDV0a6 FlSA== X-Gm-Message-State: APjAAAXz6qGCdoCwQyJEL9U1I4kEcaiBHpj3c8obSyPAkcXs+va1XFMa zSQkJMDSYccpZmBN8xtaGU00Lg== X-Google-Smtp-Source: APXvYqyoBPNBn0rwAMEKPQOuFZ3drs2yBgQUP7sh0AnHm7XQACG+oohf+mWKoAq2TtXF+dTD1K/riw== X-Received: by 2002:a62:1595:: with SMTP id 143mr468590pfv.67.1573600043372; Tue, 12 Nov 2019 15:07:23 -0800 (PST) Received: from 38f9d359441f.ant.amazon.com (54-240-196-190.amazon.com. [54.240.196.190]) by smtp.gmail.com with ESMTPSA id q185sm20500pfc.153.2019.11.12.15.07.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 15:07:22 -0800 (PST) Date: Tue, 12 Nov 2019 15:07:22 -0800 From: Sean DuBois To: =?utf-8?B?ScOxYWtp?= Baz Castillo Cc: Qingsi Wang , Alex Drake , RTCWeb IETF , mmusic@ietf.org Message-ID: <20191112230722.47vai7liav2ynfu4@38f9d359441f.ant.amazon.com> References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 23:15:10 -0000 On Tue, Nov 12, 2019 at 05:09:57PM +0100, Iņaki Baz Castillo wrote: > On Mon, 11 Nov 2019 at 10:04, Sean DuBois wrote: > > > Have you thought about/explored encrypting the entire SessionDescription? > > We can already use TLS (HTTPS or WSS) to exchange SDPs (or > "parameters" that the receiver will use to build a "remote SDP"). We > don't need yet another encryption layer to transmit a "blob" / > "string" between endpoints. > > I want to also solve these issues. * Creating a PeerConnection just so that it can fingerprint the user * Having to trust the signaling server. It would be nice if I could use a 'unsecured' signaling server and not worry about a MITM. https://saltyrtc.org/pages/why-saltyrtc.html convinced me this matters. > > There might be some issues I am not aware of, but it would give us some > > other nice things! > > > > * No more SDP munging (or at least make it harder) > > - People shoot themselves in the foot constantly by editing things > > We don't do it for fun. > > > - Will push people to communicate API needs more, instead of more hacks > > Breaking the existing ability (even if hacky) to set stereo, inband > FEC, DTX, etc. for OPUS transmission by making it impossible does not > seem a good idea. Yes, a better and real API is needed, but that does > not justify breaking the only way we have to do it nowadays. > I would love for these APIs to exist. I don't know how to make it happen though. I believe the existence of SDP munging is causing these APIs to not exist. There isn't enough pressure because these things can be accomplished (and only if you know enough). Currently The next generation of WebRTC developers is going to have to re-discover all these hacks. Also since they aren't standardized they could just go away, and no one is officially 'on the hook' to make sure they exist. > > > > -- > Iņaki Baz Castillo > From nobody Wed Nov 13 12:33:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFF812008C for ; Wed, 13 Nov 2019 12:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YvXH79AeK7Q for ; Wed, 13 Nov 2019 12:33:43 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 B9CAF12003E for ; Wed, 13 Nov 2019 12:33:43 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id x21so2273884vsp.6 for ; Wed, 13 Nov 2019 12:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q+sT7XhvPxbcf9BI48+95yACytjjXlnDj/b2ZdX2c04=; b=jSVetJREfOtmV1iEnGnkbDYE6FkLW7jvawVQ+j/J2TTrzMgw/TwmHc4cyC5CCdAape MOrOHOFG9pdfBh75o8oRzw3k7PrQ4m8HhIZGStkltahc40Az5kyxbtRQZAD3gPm85tGy Uc1K6sivG0oCsbHWNKQ5QZPgWeF32EFMQvykPadeqpufHN1VVEa7eV5gFi6IsoTE3JUQ uH6GPFxttvfvCaq2QnONvB2TMLMguVcxWFAyb0HkHlEMUSRHvd3TAlR3mcT98qJI41RR /cEaSulPU/ouj/TKdWrWf4PzvFEFUZ/x206cy6artXPaJrkGFqa2rHEBjpq8vYGGMRSP o6gA== 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=Q+sT7XhvPxbcf9BI48+95yACytjjXlnDj/b2ZdX2c04=; b=oszC/r9atM/wyrpOK6e5LqmPbspjZlJJlLX29RLS2EZDT5u/j/lc6fLqYc1eYBGtF6 uhszxrH13Pkpt6hE4LEo4HZECT5F0QgdxLhq7tJBtXuHz+/7Svf85DEZ7cJVCijabYEK 9PuZy/si3D9FJTG8gc5DbS7/fe3XR+5AHAhNKNaCfwoTYkMp4YbgRbGI2vz3JXf6Cbbl STx56fw3IFB4kSY556lQnIM8EDq7SHYVWCUoKm8k+b6QGJAcoNyhbRvHyBJ8l3qI91c3 J/bJRdjh/+8b6X1SMsk4C/NMylIbzbMYwAOXNbIvrICtOkKjieMWert26e/CA5ImiuK3 3SVA== X-Gm-Message-State: APjAAAWTtwQ4Sv7kwCeBx+NympSnLGM1CESPNpjrXediPvNHSM7V6XB8 9/eYfhOxee+E7dG2YkM67tl7CbzBZg8SVP26i8LYhA== X-Google-Smtp-Source: APXvYqxHDWK7Rt2uApSbz4Ni5/ry7itxLCaNEiVIj47EnXfXyLIK4W+Q+bNyplArUkeeAEjx+isLi6DTzvYPh3uACC8= X-Received: by 2002:a67:5d47:: with SMTP id r68mr3416254vsb.103.1573677222019; Wed, 13 Nov 2019 12:33:42 -0800 (PST) MIME-Version: 1.0 References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> <20191112230828.cuyvl4h2rqzuz3yl@38f9d359441f.ant.amazon.com> In-Reply-To: <20191112230828.cuyvl4h2rqzuz3yl@38f9d359441f.ant.amazon.com> From: Justin Uberti Date: Wed, 13 Nov 2019 12:33:29 -0800 Message-ID: To: Sean DuBois Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , Alex Drake , "mmusic@ietf.org" , "rtcweb@ietf.org" , Qingsi Wang , Christer Holmberg Content-Type: multipart/alternative; boundary="000000000000d00c340597404784" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 20:33:47 -0000 --000000000000d00c340597404784 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I appreciate the desire to solve a more general problem but I think said problem is much more difficult than what we are trying to address here - improving connectivity without sacrificing privacy in a managed network that doesn't support mDNS. Because the network is managed, key distribution is much less complicated than it otherwise would be in the general case. I would suggest we focus on solving this specific problem and, if successful, we can see if we can take this solution further. On Tue, Nov 12, 2019 at 3:08 PM Sean DuBois wrote: > On Tue, Nov 12, 2019 at 11:55:55PM +0100, I=C3=B1aki Baz Castillo wrote: > > On Tue, 12 Nov 2019 at 23:52, Sean DuBois wrote: > > > > > Agree, but we are failing developers every time they had to do this. > > > WebRTC agents should provide standardized APIs so they don't need to > > > touch the SDP to make things work. > > > > I do not transmit SDPs in the wire but parameters, and then build the > > "remote SDP" locally just to make the PeerConnection API happy. Can we > > assume then that "encrypted SDP" makes absolutely no sense? I do agree > > that a MUCH better WebRTC API is needed, but "SDP encryption" has zero > > relationship with that. > That is fine with me, I am not tied to a singular idea! > > I just want to accomplish the points in my original email. > > > > > -- > > I=C3=B1aki Baz Castillo > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000d00c340597404784 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I appreciate the desire to solve a more general problem bu= t I think said problem is much more difficult than what we are trying to ad= dress here - improving connectivity without=C2=A0sacrificing privacy in a m= anaged network that doesn't support mDNS.

Because th= e network is managed, key distribution is much less complicated than it oth= erwise would be in the general case. I would suggest we focus on solving th= is specific problem and, if successful, we can see if we can take this solu= tion further.

On Tue, Nov 12, 2019 at 3:08 PM Sean DuBois <sean@pion.ly> wrote:
On Tue, Nov 12, 2019 at 11:55:55PM +01= 00, I=C3=B1aki Baz Castillo wrote:
> On Tue, 12 Nov 2019 at 23:52, Sean DuBois <sean@pion.ly> wrote:
>
> > Agree, but we are failing developers every time they had to do th= is.
> > WebRTC agents should provide standardized APIs so they don't = need to
> > touch the SDP to make things work.
>
> I do not transmit SDPs in the wire but parameters, and then build the<= br> > "remote SDP" locally just to make the PeerConnection API hap= py. Can we
> assume then that "encrypted SDP" makes absolutely no sense? = I do agree
> that a MUCH better WebRTC API is needed, but "SDP encryption"= ; has zero
> relationship with that.
That is fine with me, I am not tied to a singular idea!

I just want to accomplish the points in my original email.

>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000d00c340597404784-- From nobody Wed Nov 13 12:49:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65B1200B4 for ; Wed, 13 Nov 2019 12:49:45 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgGHzo2RegW9 for ; Wed, 13 Nov 2019 12:49:41 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 DE08E12011A for ; Wed, 13 Nov 2019 12:49:41 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id h13so1577156plr.1 for ; Wed, 13 Nov 2019 12:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6+lB/73GVK4ip+XaUhH+CnTvLCh0vP4gwLj8Z2pu6v4=; b=L0Q/Py4n9sTKBbu8SfvoN3pWrGyOPPTewLlkxMGIPfdUGowPfowXkRKUVRmLWDhTOp wGOjUz2cq/TtpNNOnJDvoneXnb0chn+Wz87YFGOOhM3L4FdsmvnZfc2X+zXrkfaNhqSC sEc3BFHizq994EDtwuByRW5YsIUZvCMz/M1WIeSGlS3AVOkhUmcfpgdRCn4bBB0sgDM+ LhTYypQABVHx897ato2O1D0dc05I50iE2Nhm9BGO2yNmxWJy4y3vuN1/LfMNCVpx+7Q1 WTqUUWlcQ3WkfGH1l3TDV1Nof7R2CS//mV//nq+VyASPaKcBfdeZNlysxMRNkirzADJK wYiA== 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=6+lB/73GVK4ip+XaUhH+CnTvLCh0vP4gwLj8Z2pu6v4=; b=MOhHUDORXGtszZWSr6b+k3kKX/WV58udRlU0e6QSkUTQLFZ/qOdHl1sFtSfLdF7Ran iNKxpiDwBo8UB1x//6fYw2dej2HC8zKVsEEX2SJuZOZ+OxqR29V/p/mh6YcnoEZLeWse OrOyWXqoQ4nuqIx5A07C4LOTHE2YClOGKOYM2poyT5ghcukc42BiixCcn8nV4W3U35yt xqxGBRZFhmV4GMb3SoWgATkUiHgaAUQ6NWcyOlMj2qOwVGpxlsaUfP43WMA8wUvSyn0F Bv9AZ+/WG9UTe/0huQn+hJA8zzqLHc6RQybeD1/lz2g5cRcND+TpTINAQvpqWWu6+E7d BUdA== X-Gm-Message-State: APjAAAW/xJj2JUA1S0cR+H8WuFYye+dR3WgfxelNsslJX7OCDFcrr1bK QgslyUeY7B5uK2RQenn0L/WM/w== X-Google-Smtp-Source: APXvYqyURPF0eQOz7vn0LGwHi3aX6+6tl3vWp+/mDnisxDMJ8DLslFIperTZoUz/SE/NAkbaFnDiqg== X-Received: by 2002:a17:902:8502:: with SMTP id bj2mr3815816plb.303.1573678181401; Wed, 13 Nov 2019 12:49:41 -0800 (PST) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com. [209.85.210.173]) by smtp.gmail.com with ESMTPSA id f24sm3183391pjp.12.2019.11.13.12.49.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 12:49:40 -0800 (PST) Received: by mail-pf1-f173.google.com with SMTP id q26so2423662pfn.11; Wed, 13 Nov 2019 12:49:40 -0800 (PST) X-Received: by 2002:a63:b20f:: with SMTP id x15mr5848925pge.65.1573678179591; Wed, 13 Nov 2019 12:49:39 -0800 (PST) MIME-Version: 1.0 References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> <20191112230828.cuyvl4h2rqzuz3yl@38f9d359441f.ant.amazon.com> In-Reply-To: From: Roman Shpount Date: Wed, 13 Nov 2019 15:49:26 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "mmusic@ietf.org" , Alex Drake , "rtcweb@ietf.org" , Christer Holmberg , Qingsi Wang Content-Type: multipart/alternative; boundary="000000000000e2acb10597408056" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 20:49:47 -0000 --000000000000e2acb10597408056 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 3:33 PM Justin Uberti wrote: > Because the network is managed, key distribution is much less complicated > than it otherwise would be in the general case. I would suggest we focus on > solving this specific problem and, if successful, we can see if we can take > this solution further. > I agree that since network is managed, solution is much simpler, but we still might need to deal with some key distribution issues, specifically procedure for key upgrade within the network. During such upgrade one keys is typically used for encryption but multiple set of keys can be used to decrypt the candidate (due to key propagation delay through the network). One option is to try all available keys and only discard the candidate if it cannot be decoded using any available key. _____________ Roman Shpount --000000000000e2acb10597408056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 13, 2019 at 3:33 PM Justin Ub= erti <juberti=3D40google.= com@dmarc.ietf.org> wrote:
Because = the network is managed, key distribution is much less complicated than it o= therwise would be in the general case. I would suggest we focus on solving = this specific problem and, if successful, we can see if we can take this so= lution further.
=C2=A0
I agree that = since network is managed, solution is much simpler, but we still might need= to deal with some key distribution issues, specifically procedure for key = upgrade within the network. During such upgrade one keys is typically used = for encryption but multiple set of keys can be used to decrypt the candidat= e (due to key propagation delay through the network). One option is to try = all available keys and only discard the candidate if it cannot be decoded u= sing any available key.
_____________
Roman Shpount=C2=A0
--000000000000e2acb10597408056-- From nobody Wed Nov 13 13:12:49 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591C61200B4 for ; Wed, 13 Nov 2019 13:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tlD9Ik8dpDA for ; Wed, 13 Nov 2019 13:12:34 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 2479312004D for ; Wed, 13 Nov 2019 13:12:34 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id y23so2375597vso.1 for ; Wed, 13 Nov 2019 13:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CujT6xysj6VEmMCXPOwcHlMmZeCYxSUYyNtrv5GXOc8=; b=MlAyvNs2UtewAQJvdScjSHz8SXJh3IOoLyADp1bgZ3QtNFe/7ky3DuoEpApeZVoGxf Sv1vT2wnrt/wcz7Qtz01qJfE//EP5X5cdIQCIc9wdGOA5oaXgs/cQ3fM4Qn5v67ddcfQ a0WHuIPrGxZCg4wVGBhegu4Yhaa2SIWaxXbFff2Xy169s7jkBMX/t41SzF37yuFGoSWX wCJZlha8+P7bEMdNydXjl4tBV8drIMF/qsf0poUFgtxg1FVg+rcYGSnbHkJnbpLxjfuP MyQcR+XtlXfHcnM38UlplLk1SoBAgbF4bkKFDmvd/xc4ezew5toRG+vTME+tkhy5jRhk GXgw== 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=CujT6xysj6VEmMCXPOwcHlMmZeCYxSUYyNtrv5GXOc8=; b=JvSmK2ceWOmfdceHyAJs7plgVOaN0nhnsoAJoMYw2QMJw8QFrdcImfSZA9WRO3YrY7 AdxUfFfcABliAsLz836919NHp4UkWMJ/rpOgc2LtFh+FDAPcVSmU6+Cw9P/f81jL3b8H W2MNRL6WY/jF5CDfypljRmQUc73/8xvfQ30Stn7pK796m0r+hmId5y8V+MeK05u4AxoX GonYGDsf0cGGKP3Mv1r/jv1gnK788oa3laVv2eoMTuSoyjtJmVUvAnMJyURk6IBWJnhv GtdByyObrMnw46fatqDHYA5l2wgpnZBNsqhwbICI5PfBbK/ICQSV4hKwXtJMxWmYEM/U vI0w== X-Gm-Message-State: APjAAAUxR9HHHYj7+mRVlZqimvVYDhqof2stHbBmfvPKC4E6OAHm2l8q Ggv+gD9NHCZg9WVJi+15LuF5YRwyfsQw23fsM/27zw== X-Google-Smtp-Source: APXvYqzN6TwR3JxNVUul6KEO1lMNE2M+kaU6pG1LlwYaOHNZQ9uxIS8MXdMqxtMSuDTyZkopyAffunOQX+3rXwo7rBI= X-Received: by 2002:a05:6102:1c5:: with SMTP id s5mr3454492vsq.1.1573679552582; Wed, 13 Nov 2019 13:12:32 -0800 (PST) MIME-Version: 1.0 References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> <20191112230828.cuyvl4h2rqzuz3yl@38f9d359441f.ant.amazon.com> In-Reply-To: From: Justin Uberti Date: Wed, 13 Nov 2019 13:12:19 -0800 Message-ID: To: Roman Shpount Cc: "mmusic@ietf.org" , Alex Drake , "rtcweb@ietf.org" , Christer Holmberg , Qingsi Wang Content-Type: multipart/alternative; boundary="000000000000b938bc059740d2ef" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 21:12:36 -0000 --000000000000b938bc059740d2ef Content-Type: text/plain; charset="UTF-8" agreed, there is some discussion on this in https://github.com/tQsW/encrypted-ice-candidates/issues/13. On Wed, Nov 13, 2019 at 12:49 PM Roman Shpount wrote: > On Wed, Nov 13, 2019 at 3:33 PM Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> Because the network is managed, key distribution is much less complicated >> than it otherwise would be in the general case. I would suggest we focus on >> solving this specific problem and, if successful, we can see if we can take >> this solution further. >> > > I agree that since network is managed, solution is much simpler, but we > still might need to deal with some key distribution issues, specifically > procedure for key upgrade within the network. During such upgrade one keys > is typically used for encryption but multiple set of keys can be used to > decrypt the candidate (due to key propagation delay through the network). > One option is to try all available keys and only discard the candidate if > it cannot be decoded using any available key. > _____________ > Roman Shpount > --000000000000b938bc059740d2ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
agreed, there is some discussion on this in=C2=A0https://git= hub.com/tQsW/encrypted-ice-candidates/issues/13.

On Wed, Nov 13, 2019 at= 12:49 PM Roman Shpount <roman@telu= rix.com> wrote:
On Wed, Nov 13, 2019 at 3:33 PM Ju= stin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
Because the network is managed, key distribution is much l= ess complicated than it otherwise would be in the general case. I would sug= gest we focus on solving this specific problem and, if successful, we can s= ee if we can take this solution further.
=C2= =A0
I agree that since network is managed, solution is much simpl= er, but we still might need to deal with some key distribution issues, spec= ifically procedure for key upgrade within the network. During such upgrade = one keys is typically used for encryption but multiple set of keys can be u= sed to decrypt the candidate (due to key propagation delay through the netw= ork). One option is to try all available keys and only discard the candidat= e if it cannot be decoded using any available key.
_____________
Roman Shpount=C2=A0
--000000000000b938bc059740d2ef-- From nobody Thu Nov 14 01:11:56 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746CE1209C4; Thu, 14 Nov 2019 01:11:52 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA8UO5wPg8Oy; Thu, 14 Nov 2019 01:11:50 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B56B120951; Thu, 14 Nov 2019 01:11:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BC3507C3AE2; Thu, 14 Nov 2019 10:11:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC_nf46PQuPj; Thu, 14 Nov 2019 10:11:47 +0100 (CET) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2DA027C0C87; Thu, 14 Nov 2019 10:11:47 +0100 (CET) To: Sean DuBois , Christer Holmberg Cc: Alex Drake , "rtcweb@ietf.org" , Qingsi Wang , "mmusic@ietf.org" References: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <8e276814-c71b-dd98-88a6-285053ae77d7@alvestrand.no> Date: Thu, 14 Nov 2019 10:11:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191112224957.47lozyfu67lflz23@38f9d359441f.ant.amazon.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 09:11:52 -0000 Den 12.11.2019 23:52, skrev Sean DuBois: > On Mon, Nov 11, 2019 at 11:28:19AM +0000, Christer Holmberg wrote: >> HI, >> >>> Really excited to see this RFC. This is a real pain point, and glad it >>> is being addressed. I implemented this over the weekend and everything >>> fell into place. >>> >>> Have you thought about/explored encrypting the entire SessionDescription? >>> There might be some issues I am not aware of, but it would give us some >>> other nice things! >>> >>> * No more SDP munging (or at least make it harder) >>> - People shoot themselves in the foot constantly by editing things >> >> People don't modify SDP just because they can - they make it in order to make things work. >> >> Regards, >> >> Christer >> >> >> > > Agree, but we are failing developers every time they had to do this. > WebRTC agents should provide standardized APIs so they don't need to > touch the SDP to make things work. > > Maybe I am wrong, but when developers using Pion WebRTC do SDP munging I try to > figure out what APIs they need. I have no way to get them into the W3C > though, so far I just have a bucket of 'Proprietary APIs I wish I could > figure out how to upstream. Have you tried sending a pointer to the public-webrtc@w3.org list and asking if anyone wants to champion them? (I take it from context that pion is not a W3C member) > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >