Re: Unknown key shares in MMUSIC
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxvhna1nVv11b0DCuGuUVgVBdHgN14dE6uzHADoYhP0CLA@mail.gmail.com> |
On Thu, Mar 16, 2017 at 9:40 PM, Martin Thomson <[email protected]> wrote: > On 17 March 2017 at 03:14, Roman Shpount <[email protected]> wrote: > > Alternatively we can keep dtls-id the way it is currently defined and > define > > tls-id to be used for TLS-over-TCP in the new draft. > > I could accept tls-id. But if tls-id and dtls-id are the same and > have similar semantics, then one attribute makes more sense. Using a > "tls"-named attribute in DTLS isn't going to cause any real problems. > The reason I am thinking different names can make sense is interaction of dtls-id/tls-id with new connection establishment. The change in dtls-id values is used to signal new DTLS association establishment. In case of TLS-over-TCP, new connection establishment is signaled using a=connection:new/existing SDP attribute. Do you want tls-id overwrite connection attribute? Only allow to change tls-id when a=connection:new is present? I understand that tls-id and dtls-id carry similar meaning in your newly proposed extension. Are they going to carry the same meaning in new connection negotiation? > I would also prefer a more generic name for the TLS extension itself. It > > does not have to be related to SDP, so some sort of endpoint_id would > work > > better then sdp_dtls_id. > > The point is to explicitly tie the TLS negotiation to the SDP. I was > operating on the basis that SDP has a somewhat unique authentication > arrangement and that there weren't many other examples like it. > > If you think that this could be made more general and applied to > protocols that don't use SDP, that's probably true. But I can't think > of a protocol that uses the same basic mechanisms for authentication. > > I'd be open to a change if you could name an example. I don't like > building a general purpose mechanism with exactly one user; an example > would help in choosing the right semantics. > One thing I can think of is ORTC. No SDP there, but the same issue that you described is present there. Alternatively connection can be negotiated using jingle. I do not think the issue you raised is specific to SDP, as a format used to encode media stream description. This issue is specific to identifying certificates by fingerprint, no matter how this fingerprint is transmitted. Regards, _____________ Roman Shpount _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic