Re: [MMUSIC] Unknown key shares in MMUSIC

[Roman Shpount <[e-mail]>]

On Thu, Mar 16, 2017 at 9:40 PM, Martin Thomson <[e-mail]>
wrote:

> On 17 March 2017 at 03:14, Roman Shpount <[e-mail]> 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