Re: Unknown key shares in MMUSIC

> On Mar 16, 2017, at 9:38 PM, Martin Thomson <[email protected]> wrote:
> 
> On 17 March 2017 at 14:24, Cullen Jennings <[email protected]> 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.
> 

perfect

>> 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] https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc
> 
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic