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

Sean DuBois <sean@pion.ly> Mon, 11 November 2019 09:04 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 8DD0E120898 for <rtcweb@ietfa.amsl.com>; Mon, 11 Nov 2019 01:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 360wGQd8pRUe for <rtcweb@ietfa.amsl.com>; Mon, 11 Nov 2019 01:03:59 -0800 (PST)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 8F883120897 for <rtcweb@ietf.org>; Mon, 11 Nov 2019 01:03:59 -0800 (PST)
Received: by mail-pf1-x441.google.com with SMTP id q26so10242957pfn.11 for <rtcweb@ietf.org>; Mon, 11 Nov 2019 01:03:59 -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=GYd5AZF17YDjO/Wbhz5IIkDmx1tI1Gb6hxljPYFq29I=; b=F4Vi0GWjkKB3cpvxIDJ2Wr8L3mLW+Rg5D0E7Tu3ocOQ2DA4zHHnNoCeRaSruXcLxiY awqdCzQ6tOTRfAVXKnqbpS2VFI3U4pIqet2T/ymwJdlTYkmxnFA7ajlwDFcXJEJKhEmH l0zvjqKta2Glh9fmISVCEAMLbpznJkkgSxL3VtqejCEh5WZy0XSDTjpg8+OxQi+/D4Yn Bmrq4J9NYlG/ZApHBnZ05NuLlmBlA21da38dE3eEHRhXCkoI4OchnASSxtkSqw1vFEKM JT5rR9GR3JM5BgYsDZ46wDueKmm/AWbosmnpIOo2ryGlzMah/ialLKkjUCGhgwOoWzxf zrzA==
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=GYd5AZF17YDjO/Wbhz5IIkDmx1tI1Gb6hxljPYFq29I=; b=c7J1PTEk4acwopobETFmR1aFkNHDgnUBaIdLm6kgmE9cE1SjzcG+TH26G3nS3cVPtK CrVpBHoP1WCmBnBJdOHM01aI6jgCEeKNYtL4vOOJQaQkRTeQLxb8TlBHeJ90myLcoOGE ncf3A1n+O8euaC1Qcprnzgd1e0dj6hBHLObOs9KjRCvbL1IYlBVaoJCbEp6hr2HDWv4E 0VQbR4Mqwp+A7TL2oyaIwzaVQLWfWRU5RM3vJWRJu1RK1jqdHfZleG/IfQJNTxy8g53p FK7/kUMco5v1aEPlbY8pjcnjjeNsr8RZAMENGiR4+xxpvoCsuc+q2dLDxKls2ncyVEFY 6yVQ==
X-Gm-Message-State: APjAAAXM8a0e77IC2CWfBMZ+zmALdtSUw3doKp53zvxlXzw/RqDeqnsZ ef4borC8f6cfDSkIPgrnIdrbKg==
X-Google-Smtp-Source: APXvYqwaGRtNbuXZrW7GSV1fY2R5nXXCFnF0JkbFhA912BitBNQTxM3Bq8IpiFAQB1J4TyutL+aFUQ==
X-Received: by 2002:a65:48c7:: with SMTP id o7mr6002658pgs.276.1573463038426; Mon, 11 Nov 2019 01:03:58 -0800 (PST)
Received: from 38f9d359441f.ant.amazon.com ([23.252.60.236]) by smtp.gmail.com with ESMTPSA id q20sm13385494pff.134.2019.11.11.01.03.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2019 01:03:57 -0800 (PST)
Date: Mon, 11 Nov 2019 01:03:56 -0800
From: Sean DuBois <sean@pion.ly>
To: Qingsi Wang <qingsi=40google.com@dmarc.ietf.org>
Cc: mmusic@ietf.org, Alex Drake <alexdrake@google.com>, rtcweb@ietf.org
Message-ID: <20191111090356.mfkn2nbzim7xvhg4@38f9d359441f.ant.amazon.com>
References: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/CrnyQmeTozP41UUSgL3nd2NZEdk>
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 09:04:04 -0000

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?