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

Justin Uberti <juberti@google.com> Tue, 12 November 2019 19:23 UTC

Return-Path: <juberti@google.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 E8799120807 for <rtcweb@ietfa.amsl.com>; 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 <rtcweb@ietfa.amsl.com>; 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 <rtcweb@ietf.org>; Tue, 12 Nov 2019 11:23:30 -0800 (PST)
Received: by mail-il1-x136.google.com with SMTP id s5so16615272iln.4 for <rtcweb@ietf.org>; 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: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com>
In-Reply-To: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 12 Nov 2019 11:23:16 -0800
Message-ID: <CAOJ7v-3EjSgUDvVAPWp34bEoB1ASw3MEjLLqd_uXYOYP2U7Yww@mail.gmail.com>
To: Sean DuBois <sean@pion.ly>
Cc: Qingsi Wang <qingsi=40google.com@dmarc.ietf.org>, Alex Drake <alexdrake@google.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d9f8a605972b2e7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/khAIWxjZ431UVHEuXP9fmGzyPzY>
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: Tue, 12 Nov 2019 19:23:38 -0000

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 <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
> > 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
>