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

[Paul Kyzivat <[e-mail]>]

On 2/24/16 4:04 AM, Christer Holmberg wrote:
> Hi Paul,
>
> Once again, thank you for a good review. See inline.
>
>> I went through the full draft (-08) again, not just the diffs. I found a few things:
>>
>> * Intro:
>>
>> Reading the intro I would jump to the conclusion that the primary reason for this draft is to define the way for
>> explicitly signaling a new association. While this is important, I don't think it is *the* reason.
>> Rather, IIUC, the reason is to centralize DTLS negotiation procedures for many protocols that require it.
>
> We tried to cover that in the first paragraph of the Introduction, but I guess some additional text could be added. E.g.:
>
>     "[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS.  [RFC7345]
>     defines SDP Offer/Answer procedures for UDPTL-DTLS. This specification
>     defines general Offer/Answer procedures for DTLS. Other specifications,
>     defining specific DTLS usages, can then reference this specification, in order
>     to ensure that the DTLS aspects are common among all usages. Having
>     common procedures is essential when multiple usages share the same
>     DTLS association [referene-to-BUNDLE]."

WFM

> --------------------
>
>> * Section 3.1:
>>
>> The third bullet is:
>>
>>     o  The establishment of a new DTLS association is explicitly
>>        signaled;
>>
>> ISTM that this isn't quite right. I think it should say:
>>
>>     o  The desire/intent to establish of a new DTLS association is
>>        explicitly signaled;
>
> I'll look into that, but your suggestion seems ok.
>
> --------------------
>
>> * Section 4:
>>
>>     A 'dtls-connection' attribute value of 'new' indicates that a new
>>     DTLS association MUST be established.  A 'dtls-connection' attribute
>>     value of 'existing' indicates that a new DTLS association MUST NOT be
>>     established.
>>
>> The 2nd sentence above isn't entirely true. It is contradicted by section 5.3:
>>
>>     ... or if the answerer receives
>>     an offer that contains an 'dtls-connection' attribute with an
>>     'existing' value and the answerer determines (based on the criteria
>>     for establishing a new DTLS association) that a new DTLS association
>>     is to be established, the answerer MUST insert a 'new' value in the
>>     associated answer.
>>
>> IMO 5.3 must prevail here, because the answerer may not agree that there is an existing connection to reuse. So the working in section 4 should change. How about:
>>
>>     ... A 'dtls-connection' attribute
>>     value of 'existing' indicates a preference to reuse an existing
>>     association.
>
> I'll look into that, but your suggestion seems ok.
>
> --------------------
>
>> * 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.

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?

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

>> What should be done if the offer doesn't contain a setup attribute?
>
> We assume the default value, which is "active" (RFC 4145).
>
> The text says that the setup value is included "according to the procedures in [RFC4145]", but we could always include a note saying what the default value is.

OK. I didn't check 4145.

> --------------------
>
>> * Section 9.2 (NEW TEXT)
>>
>>     The far endpoint (answerer) may now establish a DTLS association with
>>     the offerer.  Alternately, it can indicate in its answer that the
>>     offerer is to initiate the TLS association.  ...
>>
>> Why does this first say DTLS and then use TLS? IIUC they should both be DTLS.
>
> Correct.
>
> --------------------
>
> 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.

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

And then it is rather last in the process to be making this change.

I guess I'm neutral on this.

	Thanks,
	Paul