Subject: [MMUSIC] Unknown key shares in MMUSIC

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Mar 2017 10:48:43 +1100

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.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 16 Mar 2017 09:23:32 -0400

Folks

Please take a look at this and comment before the Chicago meeting.

Thanks

-- Flemming

On 3/13/17 7:48 PM, Martin Thomson wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Mar 2017 12:14:55 -0400

> draft-ietf-mmusic-dtls-sdp-21.

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 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.

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Mar 2017 12:40:54 +1100

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

> does not have to be related to SDP, so some sort of endpoint_id would work

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.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 Mar 2017 21:24:00 -0600

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-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Mar 2017 14:38:43 +1100

> 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…

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.

> 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.

[1] https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Mar 2017 10:11:00 -0600

> On Mar 16, 2017, at 9:38 PM, Martin Thomson <[email-masked]> wrote:
> 

perfect

> On balance, I'd prefer to keep this as a custom extension.

That's very convincing - sounds good to me.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 17 Mar 2017 16:21:53 +0000

> On Mar 16, 2017, at 9:40 PM, Martin Thomson <[email-masked]> wrote:
> 

The example that comes to mind is Jingle — XEP-0320 defines the use of DTLS-SRTP and Fingerprint with Jingle.

In general, anything that’s high-level semantically equivalent to SDP, but tries to be less awful in its syntax (low bar), will want to use this mechanism.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 17 Mar 2017 12:24:12 -0400

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

> define

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?

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Mar 2017 15:06:17 -0400

> In general, anything that’s high-level semantically equivalent to SDP, but tries to be less awful in its syntax (low bar), will want to use this mechanism.

Are you casting aspersions on the pristine syntax of SDP?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Mar 2017 10:11:47 +1100

> newly proposed extension. Are they going to carry the same meaning in new

I was thinking that tls-id would apply in both situations, but only
carry the "new connection" semantics for DTLS.