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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.