Re: Unknown key shares in MMUSIC
Cullen Jennings <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <[email protected]> |
One ID for both TLS and DTLS make sense to me. 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. This is probably crazy, but, I wonder if it would make sense to just use the SNI. > On Mar 13, 2017, at 5:48 PM, Martin Thomson <[email protected]> wrote: > > After completely failing to remember and take into account feedback > during the avtcore meeting last time (thanks for the reminder > Jonathan), I would like to draw the attention of this group to this > draft: > > https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ > > The latest version builds on the a=dtls-id work in this group. > However, Jonathan's reminder highlighted a critical shortcoming of > that: it only works for DTLS. We still have uses of TLS-over-TCP that > would not be addressed by the current iteration of the draft (though > they would have for the previous version). > > One relatively simple solution is to define dtls-id as tls-id instead, > but that's disruptive. > > I'd like to discuss this issue with an eye to resolving it before or > at Chicago; I realize that there is a probably a tight agenda, but the > outcome of that discussion might affect a very-far-advanced > draft-ietf-mmusic-dtls-sdp-21. > > _______________________________________________ > mmusic mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mmusic