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

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Mar 2017 08:59:26 +0000

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.

----

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

----

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

----

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

----

>-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 will reply to your editorial comments in a separate e-mail)

Regards,

Christer

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 14 Mar 2017 09:46:38 -0500

> I could say ³Hence, if an offer or answer does not containŠ², if it 

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?

> I can¹t think of any scenario, so I am happy to use MUST.

Okay

> See my reply to your comment on section 10.

Seeing :-)

>> (Since you can have multiple fingerprints now...)

Okay

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Mar 2017 20:07:57 +0000

Hi,

Substantive Comments:

>>>    contain a ¹dtls-id¹ attribute (this could happen if the offerer or
>>>    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?
>>
>> I could say "Hence, if an offer or answer does not contain", if it 
>> makes the text more clear.
>
> 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 

That the receiver assumes the sender is a legacy implementation.

Maybe something like:

   "No default value is defined for the SDP 'dtls-id' attribute.
   Implementations that wish to use the attribute MUST explicitly
   include it in SDP offers and answers.  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), unless there is
   another mechanism to explicitly indicate that a new DTLS association
   is to be established, a modification of one or more of the following
   characteristics MUST be treated as an indication that an endpoint
   wants to establish a new DTLS association:" 

...

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

"NOTE: Since the publication of RFC 5763, RFC 4474 has been obsoleted by draft-ietf-stir-4474bis. The updating of the references (and the
associated procedures) within RFC 5763 is outside the scope of this document. However, implementers of RFC 5763 applications are 
encouraged to implement draft-ietf-stir-4474bis instead of RFC 4474."

Feel free to modify, if you e.g., want to give more background etc about 4474bis.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 14 Mar 2017 15:12:24 -0500

Both work for me.

Thanks!
Ben.

> On Mar 14, 2017, at 3:07 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> Substantive Comments:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Mar 2017 21:38:53 +0000

Hi Ben,

I've created a pull request with all the changes based on your comments (substantive and editorial). Please take a look.

https://github.com/cdh4u/draft-dtls-sdp/pull/25

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 14 March 2017 22:12
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; mmusic <[email-masked]>
Subject: Re: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments

Both work for me.

Thanks!
Ben.

>>> This is related to the first sentence, saying that there is no 
>>> default value defined for the attribute.
>>> 
>> (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?
> 
>>>> 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
>> 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.
> 
> "NOTE: Since the publication of RFC 5763, RFC 4474 has been obsoleted 
> by draft-ietf-stir-4474bis. The updating of the references (and the 
> associated procedures) within RFC 5763 is outside the scope of this document. However, implementers of RFC 5763 applications are encouraged to implement draft-ietf-stir-4474bis instead of RFC 4474."
>