Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

[Christer Holmberg <[e-mail]>]

Hi,

...

 --------------------

>>> * Section 5.1:
>>>
>>>     The certificate received during the DTLS handshake MUST match the
>>>     fingerprint received in the SDP "fingerprint" attribute.  If the
>>>     fingerprint does not match the hashed certificate, then the endpoint
>>>     MUST tear down the media session immediately.  ...
>>>
>>> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case?
>>
>> We try to clarify that in section 3.4, which says:
>>
>>     "It is possible to associate multiple SDP fingerprint attribute values
>>     to an 'm-' line.  If any of the attribute values associated with an
>>     'm-' line are removed, or if any new attribute values are added, it
>>     is considered a fingerprint value change."
>
> Right. But AFAIK that is the only place it is mentioned. At the least, most places that reference "the fingerprint" 
> should acknowledge that there may be more than one.

I guess we could use "one or more SDP 'fingerprint' attributes" terminology instead of "an SDP 'fingerprint' attribute".

> And *someplace* needs to say what the semantics of use are when there is more than one. (Maybe it is defined in one 
> of the references?) Am I correct in assuming that providing multiple fingerprints is for the convenience of the
> recipient, who can then pick the one that it prefers to verify?

I don't think the semantics are defined anywhere, unless it is defined in some RTCWEB document... I remember that it was agreed at some point that multiple fingerprints were allowed, but I am not sure whether anything was written down in a specificaiton...

In my opinion, the semantics belong to RFC 4572.

--------------------

>>> * Section 5.3:
>>>
>>> If the offer specified 'existing' but the answerer changes to 'new', 
>>> should the setup attribute settings remain as they had been? (Which 
>>> then determines which end sends the ClientHello message.)
>>
>> Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed 
>> to re-negotiate the roles (read: change the value of the 'setup' attribute)?
>>
>> The problem is that the offerer specified "existing", and so followed the rules for doing that. So it had 
>> to use the last negotiated setup value. But the answerer has decided to switch to "new". At this point 
>> there are limits on what it can do - there can't be a full negotiation.
>
> If the offer contained "active" or "passive" then the answerer is stuck with what was previously negotiated. If the 
> offer contained "actpass" then maybe the answerer could choose either "active" or "passive" independent of what 
> was previously negotiated. I think this needs to be explained and clarified as to what is allowed.

Ok, now I understand.

The text does say that the 'setup' attribute must be set according to RFC 4572, so I think that covers what values are allowed.

But, perhaps we could add a note, saying that if the answerer is not able to able to select a 'setup' value that reflects it capabilities, it must reject the m- line. That of course also applies to the handling of the initial offer.

--------------------

NEW COMMMENT:

>> In addition, I noticed that the document uses "DTLS connection" terminology in a few places, while the 
>> intention is to use "DTLS association" (which is also used in the RFCs we update).
>>
>> The question is whether the name of the SDP attribute should still be "dtls-connection", or whether we 
>> should change it to "dtls-association". My personal preference would be to keep the "dtls-connection" name, but I can live with both.
>
> On one hand using dtls-connection draws parallels with 'connection', which might be good.

Yes - that is exactly the reason why my preference is 'dtls-connection' :)

> On the other hand the parallels aren't complete, so maybe changing it would emphasize that it *isn't* the same.

Well, 'DTLS connection' is used in some specifications...

> And then it is rather last in the process to be making this change.
>
> I guess I'm neutral on this.

So, unless someone objects, I'll keep it as it is.

Regards,

Christer