Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-11

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Mar 2016 14:46:46 +0000

Hi,

We've submitted a new version (-11) of draft-ietf-mmusic-dtls-sdp.

The draft now defines an SDP 'dtls-association-id' attribute, replacing the previous 'dtls-connection' attribute.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Mar 2016 13:02:56 -0400

On 3/21/16 10:46 AM, Christer Holmberg wrote:
> Hi,
>
> We’ve submitted a new version (-11) of draft-ietf-mmusic-dtls-sdp.
>
> The draft now defines an SDP ‘dtls-association-id’ attribute, replacing
> the previous ‘dtls-connection’ attribute.

* Section 5.1

    SDP offerers and answerers might reuse certificates across multiple
    DTLS associations, and provide identical fingerprint values for each
    DTLS association.  It MUST be ensured that the combination of the
    fingerprint values and the SDP 'dtls-association-id' attribute value
    is unique across all DTLS associations.

    If an SDP offerer or answerer generates a new temporary self-signed
    certificate for each new DTLS association, they can omit the SDP
    'dtls-association-id' attribute.

Is the last paragraph above just stating a degenerate case of the prior 
paragraph? IOW, if the certificate is new, then the fingerprint will 
also be new, and so the combination of the fingerprint with the (empty) 
dtls-association-id will be unique?

It might be clearer to reframe the rules and matching process throughout 
the draft as matching 'dtls-association-id'||'fingerprint', where 
'dtls-association-id' is "" if not specified.

* Section 5.2

This says that one or more fingerprints must be included in the initial 
offer. But fingerprints will only be available if the offerer is 
intending to supply a certificate. That implies either that the offerer 
will be the DTLS server, or else that client authentication is to be 
done. AFAIK neither of these is necessarily true. In this usage is there 
any value to client authentication?

So I think more needs to be said about this.

What if the offer includes 'a=setup:actpass'? Must the offerer include 
the fingerprint for the cert it will use *if* it becomes server?

* Section 5.3:

A couple of places talk about "a 'dtls-association-id' attribute with a 
previously assigned value".

I think that needs to say "a 'dtls-association-id' attribute with *the* 
previously assigned value". Otherwise it might match a value used 
earlier, but not most recently.

(This issue may exist in other sections too.)

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Mar 2016 13:51:57 -0400

On Mon, Mar 21, 2016 at 1:02 PM, Paul Kyzivat <[email-masked]> wrote:

> paragraph? IOW, if the certificate is new, then the fingerprint will also
> be new, and so the combination of the fingerprint with the (empty)

Yes, this is as you described a degenerative case of the above.

> 'dtls-association-id' is "" if not specified.

Agreed

* Section 5.2
> offer. But fingerprints will only be available if the offerer is intending
> to supply a certificate. That implies either that the offerer will be the
> DTLS server, or else that client authentication is to be done. AFAIK
> neither of these is necessarily true. In this usage is there any value to
> client authentication?
>
> What if the offer includes 'a=setup:actpass'? Must the offerer include the
> fingerprint for the cert it will use *if* it becomes server?
>

I think we need to spell out that when DTLS SDP is used both parties are
authenticated and server and client certificates are always provided. If
client or server does not provide the certificate, connection must be torn
down. Because of this fingerprint attributes MUST always be provided. This
might be something that belongs in RFC4572bis, if it is not already in
RFC4572.

> previously assigned value". Otherwise it might match a value used earlier,
> but not most recently.
>

Thank you for catching this. We will review the text for this issue.

______________
Roman Shpount