Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments

["Ben Campbell" <[e-mail]>]

On 14 Mar 2017, at 3:59, Christer Holmberg wrote:

> Hi Ben,
>
> Thanks for your review! Please see inline.
>
>
>> This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like 
>> to
>> resolve my substantive comments and questions prior to IETF last 
>> call.
>>
>> Thanks!
>>
>> Ben.
>>
>> ---------------------
>>
>> Substantive Comments:
>>
>> - section 4: "If an offer or answer does not
>>    contain a ¹dtls-id¹ attribute (this could happen if the offerer
>> or
>>    answerer represents an existing implementation that has not been
>>    updated to support the ¹dtls-id¹ attribute), the offer or answer
>> MUST
>>    be treated as if no ¹dtls-id¹ attribute is included. "
>>
>> That seems to say that if dtls-id is not included, the offer or 
>> answer
>> must be treated as if it's not included. Since that's tautologically
>> true, I suspect you meant to say something more?
>
> This is related to the first sentence, saying that there is no default
> value defined for the attribute.
>
> I could say ³Hence, if an offer or answer does not containŠ², if it 
> makes
> the text more clear.

You would still get a sentence of the form "If not foo, then not foo." 
Perhaps the predicate clause could be recast as the consequences or 
(high level) receiver behavior when dtls-id not being present? Does the 
absence mean that the session is not setup? That the receiver assumes 
the sender is a legacy implementation?


>
> ----
>
>> -8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision 
>> a
>> scenario where it would make sense to not follow them?
>
>
> I can¹t think of any scenario, so I am happy to use MUST.

Okay

>
> ----
>
>> -9.2, new text for section 5, 5th paragraph:
>> Since we are touching this section, shouldn't we update the 4474
>> reference to 4474bis, and update the language about what gets signed 
>> in
>> 4474bis? And can we take this opportunity for a MUST level 
>> requirement
>> for some kind of integrity protection of fingerprints, even if not
>> 4474/4474bis? (At least when not considering opportunistic crypto
>> cases.)
>
> See my reply to your comment on section 10.

Seeing :-)

>
> ----
>
>> -- 4th paragraph from end of new text:
>> should "the certificate fingerprint" say "a certificate fingerprint"?
>> (Since you can have multiple fingerprints now...)
>
> Yes. I will fix that.

Okay

>
> ----
>
>> -10:
>>
>> If you accept my suggestion to move from 4474 to 4474bis in the 
>> updated
>> text for 5763, that will create changes that should probably be
>> mentioned here. For example, 4474bis signatures cover fewer things 
>> than
>> do 4474 signatures. The hope that 4474bis may be more deployable than
>> 4474, and therefore really used, may also be worth a mention here.
>
> RFC 5763 contains 20+ references to RFC 4474, in a number of different
> sections.
>
> We would have to update all of those sections (at least the reference,
> possibly also normative text), because I don¹t think we should mix 
> 4474
> and 4474bis. In my opinion, that should be done as a separate task.

I scanned 5763 for the references to see if we could reasonably say that 
all references should be updated. But there's some text on the 
limitations of identity for phone numbers that might become obsolete if 
we did that.
SO I can be convinced to leave that out of scope for this update. But 
it's still a bit unfortunate :-)


Would it make sense for this document to contain a paragraph somewhere 
mentioning that, since the publication of 5763, RFC4474 is being updated 
to address some of those issues, and that implementors should at least 
consider moving to it? The reason I push on this is that I have hopes 
that 4474bis can enable the dtls-srtp framework to be used in a more 
secure fashion that typical for now, since we have such limited 
deployment of 4474.

>
>
> (I will reply to your editorial comments in a separate e-mail)
>
> Regards,
>
> Christer