IETF Logo Mail Archive

Re: [MMUSIC] [rtcweb] 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: 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 6A9C8120889 for <mmusic@ietfa.amsl.com>; Mon, 11 Nov 2019 01:04:01 -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=ham 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 QJWbexxliou6 for <mmusic@ietfa.amsl.com>; Mon, 11 Nov 2019 01:03:59 -0800 (PST)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 93228120895 for <mmusic@ietf.org>; Mon, 11 Nov 2019 01:03:59 -0800 (PST)
Received: by mail-pg1-x543.google.com with SMTP id f19so9045377pgk.11 for <mmusic@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=BVhvtTCh2i7+mkKJDsODwhv84ZV/67N5acW16edcYb/PfaX6ixw/NfK5lQw2md9qTt 1F2paVUdKGAnvJW01ZgNPkosrXW5GbxGPUItyJDQZGHlAxymt+qBjHWxuBBw7us3pERs T/JOIZCrYIOf4OY44FIpBRaZcx+pM+VgB+TwaS9K42L+MJrZ1vg6toG0dsbZBYUXila+ KArXUS6y9mfgOsCUfEu2RotnjPUl2oTid0HeRP04tRFwUY923uu2zdoQ/1mQ9O6o3Y6I 9cB5LQmiycCST2L1BIN1Mp5phmdT7MTCUyKND6Rqh9RE//PU5muUGV/TDj9nkb1HNLvC a5Ew==
X-Gm-Message-State: APjAAAVwI94xOqO0IenEiJvLtDoniS6+2BXUk9KECNEJ0J5j8E/yDM4m 2RW1GR52inz52yDSWnwxez02OA==
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/mmusic/6GaXvde248iRlw_DPXsDWiWNPn8>
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: Mon, 11 Nov 2019 09:04:01 -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?

v2.23.0 | Report a Bug | By Email