Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates
Bernard Aboba <bernard.aboba@gmail.com> Mon, 11 November 2019 18:37 UTC
Return-Path: <bernard.aboba@gmail.com>
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: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <df740bf1-304f-4123-8cd0-e0eb1a9dd089@www.fastmail.com> <CA+m752LrouhP+MZ0o+mY7RwdjLjKC7OwxUVOaEoEK_43ZWtPMg@mail.gmail.com> <6f18c4d8-e4a7-46be-ac81-032ef2d1e03f@www.fastmail.com>
In-Reply-To: <6f18c4d8-e4a7-46be-ac81-032ef2d1e03f@www.fastmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 11 Nov 2019 10:37:25 -0800
Message-ID: <CAOW+2duq0nVAALGvkmoAFFRfBy-zSKwFP1QfRbgp6DAmbuX6Aw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: Qingsi Wang <qingsi@google.com>, Alex Drake <alexdrake@google.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f289700597166c17"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/c1ZSSKpyFuO_7Uzj9iGjUf3P49A>
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 <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: Mon, 11 Nov 2019 18:37:47 -0000
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 <https://tools.ietf.org/html/rfc4107#ref-TK>], AES-CTR [NIST <https://tools.ietf.org/html/rfc4107#ref-NIST>], or AES-CCM [WHF <https://tools.ietf.org/html/rfc4107#ref-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> 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 >
- [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-en… Qingsi Wang
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Martin Thomson
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Qingsi Wang
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Ted Hardie
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Roman Shpount
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Justin Uberti
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Martin Thomson
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Sean DuBois
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Harald Alvestrand
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Christer Holmberg
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Bernard Aboba
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Roman Shpount
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Iñaki Baz Castillo
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Justin Uberti
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Sean DuBois
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Sean DuBois
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Iñaki Baz Castillo
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Sean DuBois
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Sean DuBois
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Justin Uberti
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Roman Shpount
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Justin Uberti
- Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusi… Harald Alvestrand