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

[Roman Shpount <[e-mail]>]

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

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

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


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

Agreed

* 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?
>

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.



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

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

______________
Roman Shpount