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
>