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

Bernard Aboba <> Mon, 11 November 2019 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C80C120BFA; Mon, 11 Nov 2019 10:37:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z9X6BYqKF343; Mon, 11 Nov 2019 10:37:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C49AC120B85; Mon, 11 Nov 2019 10:37:38 -0800 (PST)
Received: by with SMTP id d6so10269671lfc.0; Mon, 11 Nov 2019 10:37:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <>
In-Reply-To: <>
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-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

Martin said:

"Right now, there is a big hole that screams "key management problems"

[BA] There is an RFC 4107 on Key Management Guidelines:

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

      Any stream cipher (such as RC4 [TK
<>], 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