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

[Paul Kyzivat <[e-mail]>]

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