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

Sean DuBois <> Tue, 12 November 2019 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 135DE12011D for <>; Tue, 12 Nov 2019 15:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HjEGep1ED_VB for <>; Tue, 12 Nov 2019 15:15:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A32F31200B7 for <>; Tue, 12 Nov 2019 15:15:08 -0800 (PST)
Received: by with SMTP id p24so189760pfn.4 for <>; Tue, 12 Nov 2019 15:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=cSSbcqR/x1O9zSMSCF6lQ5IdU+2A962Htrog4J/eaDM=; b=obaZvDTjRQIU6W+oSvzQkWml0OwfCneFIWcHXSnKkMyVZ3xKALLslnXe+Jj++tP9yM gpPEv4pLwR1r64w9beIALX+3bJLtmrsEUXj+sMR5VX9XVtE6Ykpqm4QeF+ke+DzkLigM jEP8GsfADhmww2yI6YkVHTVb6W6IqrC9HIswsd6Oo4/1trGbZTBNmqB+nkFwL/27yQWW EZQJM51zTct/1NrD/2zt+LstM9GJlWO3SP7z33F4kgLiWwtMsQR9uvaEcQCWenkz90BL O2fHPkNV6lw504EN3fFQF2lwuf4PpSA3zKikMpsMU1XHKBsiovA3YWas0V8EycU8PGqa 3A0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=cSSbcqR/x1O9zSMSCF6lQ5IdU+2A962Htrog4J/eaDM=; b=RFKpPUy2YQNZ3YSiBsFxir04kVfrCg4joqigjioikBuZxk+b2w0kAJJcPqihkpoC3g WExf55DhqC4eZejFj74KxQmVEMh1qocS9EEDyBLP9ZI0u9KHayyH9BTO6v9cY3vqp9Xp vs0wESvZARgv2wprUWiqH9fYjLR/Ch0iXcOjmAhp8TpDc/oOuJmPm+v5ePP7Wm61KCAN W9x52EFQC3P86k7DWhNHkC+T6TsUUNRsU4mJykFXVLwW7wpryk/WjW8dLcG7jMeAMzP3 +RYb25oyq1CBmO0UdXftK999AL7s3Ved8ku8dvXaxW6QxXEm3ncG5uxDGNyzCAnDV0a6 FlSA==
X-Gm-Message-State: APjAAAXz6qGCdoCwQyJEL9U1I4kEcaiBHpj3c8obSyPAkcXs+va1XFMa zSQkJMDSYccpZmBN8xtaGU00Lg==
X-Google-Smtp-Source: APXvYqyoBPNBn0rwAMEKPQOuFZ3drs2yBgQUP7sh0AnHm7XQACG+oohf+mWKoAq2TtXF+dTD1K/riw==
X-Received: by 2002:a62:1595:: with SMTP id 143mr468590pfv.67.1573600043372; Tue, 12 Nov 2019 15:07:23 -0800 (PST)
Received: from ( []) by with ESMTPSA id q185sm20500pfc.153.2019. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2019 15:07:22 -0800 (PST)
Date: Tue, 12 Nov 2019 15:07:22 -0800
From: Sean DuBois <>
To: =?utf-8?B?ScOxYWtp?= Baz Castillo <>
Cc: Qingsi Wang <>, Alex Drake <>, RTCWeb IETF <>,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: NeoMutt/20180716
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2019 23:15:10 -0000

On Tue, Nov 12, 2019 at 05:09:57PM +0100, Iñaki Baz Castillo wrote:
> On Mon, 11 Nov 2019 at 10:04, Sean DuBois <> wrote:
> > Have you thought about/explored encrypting the entire SessionDescription?
> We can already use TLS (HTTPS or WSS) to exchange SDPs (or
> "parameters" that the receiver will use to build a "remote SDP"). We
> don't need yet another encryption layer to transmit a "blob" /
> "string" between endpoints.
I want to also solve these issues.

* Creating a PeerConnection just so that it can fingerprint the user
* Having to trust the signaling server. It would be nice if I could use
  a 'unsecured' signaling server and not worry about a MITM. convinced me this matters.

> > 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
> We don't do it for fun.
> >    - Will push people to communicate API needs more, instead of more hacks
> Breaking the existing ability (even if hacky) to set stereo, inband
> FEC, DTX, etc. for OPUS transmission by making it impossible does not
> seem a good idea. Yes, a better and real API is needed, but that does
> not justify breaking the only way we have to do it nowadays.
I would love for these APIs to exist. I don't know how to make it happen

I believe the existence of SDP munging is causing these APIs to not
exist. There isn't enough pressure because these things can be
accomplished (and only if you know enough).

Currently The next generation of WebRTC developers is going to have to
re-discover all these hacks. Also since they aren't standardized they
could just go away, and no one is officially 'on the hook' to make sure
they exist.
> --
> Iñaki Baz Castillo
> <>