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

Sean DuBois <sean@pion.ly> Tue, 12 November 2019 22:40 UTC

Return-Path: <sean@pion.ly>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED98120854 for <mmusic@ietfa.amsl.com>; Tue, 12 Nov 2019 14:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.20150623.gappssmtp.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 m5dOYnBQsTfG for <mmusic@ietfa.amsl.com>; Tue, 12 Nov 2019 14:39:57 -0800 (PST)
Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 2390E1200B9 for <mmusic@ietf.org>; Tue, 12 Nov 2019 14:39:57 -0800 (PST)
Received: by mail-qt1-x843.google.com with SMTP id l24so287230qtp.10 for <mmusic@ietf.org>; Tue, 12 Nov 2019 14:39:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wH9jgUkK0upK2ssqv2Mr2vgPLeZCy43NAVOyWhXFYM4=; b=IlF6l0KhWEsw1xdJvxGEyiTnd4y1b37CSracq+OZz9IgY8zWK2stBNFTpRpvoToGB3 PtSsdWZ5QMGoRklJtV45Gsk4kWNnD5lFy4dC7JwVRBJkwwMLQDgolbhmXeuG52lr6hck otnh3dp/jkfomnXgpQHO19JAHeoiuHoWZikJJHsJ8F4F4is9m9GzM7dqaJzABzQQ4Lb4 EPllhXlv46edTuQIAp/zc7Kz4F8E4IixsSPJPtY7Z+sD1NTHj26gROW8AECYYTtIqpbr BnjLcxflykXDjLAyR5hOOAzGByG8A0oyXS5TQilvgxV4vr7xFjxi2SL6wuDEGjD/cImn qthQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wH9jgUkK0upK2ssqv2Mr2vgPLeZCy43NAVOyWhXFYM4=; b=ReLRzbp/M65iWaGMlerIOAlWET+/NWtoKN+QoF9237ufTjfxCPeYyskQOrnvHXWeKW 4gPEXqD5/SQ4Qh8ncjXHTQ2iFc8YMvg2ijl6u+nMtn11E9sz9FQosU9pUwGwb7BYHg3W 5gaDuKvsOFkmeCiCBB8kcsrotgT2OziqETEQRfP/FDcIvf4l9+Q9WndX83ZDI/MRZzJf L/vbwWZa4br3JfvfbxY6ikV770PD4Xtq+lE0yR+sQJoeMw92zt6abCVXegvXrcITjwnp yDVUoMqvkouJFJBSUbSWtSVc3ZxR4MQgsJHuAR4eEkRl11XWt/BzQb5OCVxMpzWQ9ui5 HHtw==
X-Gm-Message-State: APjAAAUg+V2W6Gitqt05wMxL7ofxR740j9GDRHw5Hh4zhD4XxjgBvTHV izneOYSn1VRV20OD8XOuLUw/cQ==
X-Google-Smtp-Source: APXvYqxLCLWK5Tl/ZwA0vZn8ea/uK4uuC7LUHnNDtcLpXmDoFxEWEHFFWDZ9tPBE1hTjYnzXb85pMQ==
X-Received: by 2002:ac8:6919:: with SMTP id e25mr5904415qtr.199.1573598395952; Tue, 12 Nov 2019 14:39:55 -0800 (PST)
Received: from siobud.com (mail.siobud.com. [165.227.221.230]) by smtp.gmail.com with ESMTPSA id a10sm140336qtd.29.2019.11.12.14.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 14:39:55 -0800 (PST)
Date: Tue, 12 Nov 2019 22:39:53 +0000
From: Sean DuBois <sean@pion.ly>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Qingsi Wang <qingsi=40google.com@dmarc.ietf.org>, Alex Drake <alexdrake@google.com>, rtcweb@ietf.org, mmusic@ietf.org
Message-ID: <20191112223953.GA3851@siobud.com>
References: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com> <909be25d-740a-03fd-ecbf-f3fb73f0723d@alvestrand.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <909be25d-740a-03fd-ecbf-f3fb73f0723d@alvestrand.no>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/7wyVmYZUB5DvPmKEPVUL7Wsapyo>
Subject: Re: [MMUSIC] [rtcweb] Draft new: draft-wang-mmusic-encrypted-ice-candidates
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 22:40:01 -0000

On Mon, Nov 11, 2019 at 11:59:22AM +0100, Harald Alvestrand wrote:
> Den 11.11.2019 10:03, skrev Sean DuBois:
> > 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?
>
> This would destroy interoperability with any currently fielded
> implementation, so it's unlikely to be popular.
> It also requires setting up a shared key before you can exchange SDP,
> which is a pain (as this draft makes clear).
>
These changes are already going to break interoperability. In a perfect
world you can discard candidates that are invalid, but lots of bad code
is just going to break.

Maybe encrypting the whole SDP isn't the right answer. My concern is
that we are going to revisit this issue again because of the points I
called out, I would like to explore solving the root issue.

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