Re: [MMUSIC] Unknown key shares in MMUSIC

[Martin Thomson <[e-mail]>]

On 17 March 2017 at 14:24, Cullen Jennings <[e-mail]> 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.

[1] https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc