Re: [MMUSIC] Unknown key shares in MMUSIC

Martin Thomson <> Fri, 17 March 2017 03:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C110129BD4 for <>; Thu, 16 Mar 2017 20:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pg73kjWkXb6H for <>; Thu, 16 Mar 2017 20:38:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85434129BDA for <>; Thu, 16 Mar 2017 20:38:44 -0700 (PDT)
Received: by with SMTP id x35so53797151qtc.2 for <>; Thu, 16 Mar 2017 20:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=evnTSxqhAgql6n6hXgiD9fk4rYFMCfj+kNWsVKlRgE4=; b=hINB6cCaOB7gq8m904yn2EtWjd2QBqKjV47W9aCFMb86uyvnotNUjWhk5laogSUvLe BdOKVKe5U7F4F/sB7BKotdGcu1TdfSaIYzrvX8cqu03HXauxDJRAxnUx6H7nXjKWNDFe eWnij6bq64U7KhN2CW3fkgP1F2yMNrweqW7HPeXPVBCBBSHFkB6cNFY92kNxQkOQ9NQq 2aggbf50jsqBDPfHntCc/b2yhMECHkST5/eEIgyZTRaqvdjXhyKLVtsCp9tz1q0BfTJD wntT6HhBIiJxJxDjGsUoAxcKY9LbfmMmsy4cQ9Idbc/owBnlel1gVBMNV5ZpemGoJfT9 fr5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=evnTSxqhAgql6n6hXgiD9fk4rYFMCfj+kNWsVKlRgE4=; b=QpgWJg32RU1r4zuQosmcMbdHytGmITxblaoZLOfjMlqPXAYLzaBlOZ5FrDj/vZkp63 NhiJWMAf0A61YIQ9oiY9H0KMn8A4/nP9xerF4NRivsk7tA6D0gjsy9sO4CJcKCy7bnWz VVU3EZ4iwJNduUL8iWNeitzLjY0p94AMm3UM9or8a8C4dmmN+IcHzDz+3H8tYvXJ9JK8 OvW7QWapE1dyy1rqg9YM9YyTGV351pki66QZtogrYqiMufBJLX9SS4IrplnVtkYsTmpk LylHXq7zx5oB0u2Ltqlapo1bPR5nAc21OLfI2bl1UTi8GqouPC7odJjjqeQtWHEbmPtv Hvpg==
X-Gm-Message-State: AFeK/H0uHjFFWCzuIzXeDRfUJHBVerVvsY6jjt/wQPx4yNjm8Ag2Hk+XQqaTkI+isngs5w4zlc9jarkHFPvsOQ==
X-Received: by with SMTP id i16mr11718179qta.13.1489721923715; Thu, 16 Mar 2017 20:38:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Mar 2017 20:38:43 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Fri, 17 Mar 2017 14:38:43 +1100
Message-ID: <>
To: Cullen Jennings <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 03:38:46 -0000

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

Then the value we use probably needs to look like a domain name.
Despite being ostensibly extensible, SNI effectively means domain name

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.