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

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

Return-Path: <sean@pion.ly>
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 60981120130 for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2019 14:39:59 -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 7U7l-Y_DxZxt for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2019 14:39:57 -0800 (PST)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 2C34412011D for <rtcweb@ietf.org>; Tue, 12 Nov 2019 14:39:57 -0800 (PST)
Received: by mail-qt1-x844.google.com with SMTP id p20so317535qtq.5 for <rtcweb@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=SQV5PpKKa48Fhij9RUq7zu0bXkYKO1hM1NtRNcHPkhOWMHxV6YceEGIulUjYn2O2GV 6ZmSxs1L07ZgW/U4pVLNYc1kQT0Ov9sP3gXnK3ODvhhGKBSkrikketCYJFMB/xyttOl2 QvZtB6u7OmLxD7s0c8w5CQf0a+2KvwWDpduiyI2EtIwTv1ggQx84n5ctZSNVfDrigKuv R4GYjIglcv1J3iXNuEM3rtZCh/CKpZkTfmSLqqD6DXBBB6hjP8mPXuM4Any2qmoMtPFg aYC6zIwfxlWUkfkqD2o9KRGEnTZdMw85Rblw+Zp8gshyok/BfOrk/BX6T/sb0YVcyJU8 IwOw==
X-Gm-Message-State: APjAAAXzKS0q88HzxDrEpeJP+yz72dbMv69sxLS6YeiUjq5ggdrjjJoP Xv77ecpD3AmH/oWVwibv0MrshQ==
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/rtcweb/3pYLH3yLAKkBh3_grfIbwTeQbg4>
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 22:39:59 -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
> >
>