Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates

"Martin Thomson" <mt@lowentropy.net> Wed, 06 November 2019 03:16 UTC

Return-Path: <mt@lowentropy.net>
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: <xms:BDvCXWzY9cT3Asa4u69pnnGL4DRdZXfLXLzoVzNylZVVg5Vlr4c2-g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:BDvCXR8DNh9-i27dR51rN992xlNWdw0WZ0HZSZZHCD882HKcgK327A> <xmx:BDvCXTJ0O-Znql8UaRpSx09y7c64Ybofe83vMMWGibgU-haHYGtY-A> <xmx:BDvCXe8gHgqX9XTVFHTHI7qkJSugyaodX0P5h2AxMvukO6aIPRjSnQ> <xmx:BTvCXViANgWm4e8lIAJcfUsIx9HExEZr6AgqKaTPjz7WlSPmK_0sbg>
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: <CA+m752LrouhP+MZ0o+mY7RwdjLjKC7OwxUVOaEoEK_43ZWtPMg@mail.gmail.com>
References: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <df740bf1-304f-4123-8cd0-e0eb1a9dd089@www.fastmail.com> <CA+m752LrouhP+MZ0o+mY7RwdjLjKC7OwxUVOaEoEK_43ZWtPMg@mail.gmail.com>
Date: Wed, 06 Nov 2019 14:16:00 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "Qingsi Wang" <qingsi@google.com>
Cc: mmusic <mmusic@ietf.org>, "Alex Drake" <alexdrake@google.com>, rtcweb@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/aylfmLA1A_yDKcFwawu-iWYPpp4>
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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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.