Re: [MMUSIC] Unknown key shares in MMUSIC

Cullen Jennings <> Fri, 17 March 2017 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C68F01294D1 for <>; Fri, 17 Mar 2017 09:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pFeJSHhTC6GG for <>; Fri, 17 Mar 2017 09:11:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17D661294CD for <>; Fri, 17 Mar 2017 09:11:04 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id 6F436A0342; Fri, 17 Mar 2017 12:11:03 -0400 (EDT)
Received: by (Authenticated sender: with ESMTPSA id 24C81A0377; Fri, 17 Mar 2017 12:11:03 -0400 (EDT)
Received: from [] ([UNAVAILABLE]. []) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by (trex/5.7.12); Fri, 17 Mar 2017 12:11:03 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Fri, 17 Mar 2017 10:11:00 -0600
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [MMUSIC] Unknown key shares in MMUSIC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Mar 2017 16:11:06 -0000

> On Mar 16, 2017, at 9:38 PM, Martin Thomson <> wrote:
> On 17 March 2017 at 14:24, Cullen Jennings <> wrote:
>> The one thing that is key for perc, is that in the Client Hello, this need to not be encrypted so that the MDD can use it to recognize which KDD is meant to be routed to. Effectively you can think as the MDD as a load balancers for all the KDDs that act as the TLS server and it is using this field much like a normal load balancer might use SNI. So I want to make sure we preserver this property.
> Yes, the design keeps the value in the clear (in the ClientHello at
> least).  That's the easiest possible design.  The client can't start
> encrypting until it has talked to the server.  We could add extra
> messages to carry this in an encrypted form, but as you say that would
> screw with routing and there is no major value in providing
> confidentiality for this value.


>> This is probably crazy, but, I wonder if it would make sense to just use the SNI.
> It's not crazy, though it might be suboptimal for a few reasons.
> The design I chose has both peers include the extension as well as
> independently checking the value they receive.  Servers don't
> typically send SNI so SNI wouldn't be symmetrical in this fashion.
> Servers are permitted to send SNI, but I don't know any that do (and
> would be worried that this is wrong).  A different a=dtls-id value is
> required from both offerer and answerer, so you would have to
> concatenate the two in some unambiguous form to have it work as
> intended.
> Then the value we use probably needs to look like a domain name.
> Despite being ostensibly extensible, SNI effectively means domain name
> [1].
> The biggest concern for me is that you don't get redundant checks with
> SNI.  The client has to trust that the server is checking and gets no
> positive indication that the server even supports the feature.
> The benefit of pretending that it is SNI is that you can feed it
> through existing APIs and hook into existing load balancer code paths.
> On balance, I'd prefer to keep this as a custom extension.

That's very convincing - sounds good to me. 

> [1]
> _______________________________________________
> mmusic mailing list