Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07

[Ben Campbell <[e-mail]>]

Hi,

To be clear, progress of this draft is currently blocked on a response to my “Please resolve…” comment below. Please respond as soon as possible,

Thanks!

Ben.

> On Feb 14, 2019, at 2:46 PM, Ben Campbell <[e-mail]> wrote:
> 
> Signed PGP part
> Hi,
> 
> This is my AD Evaluation of draft-ietf-sipbrandy-osrtp-07.
> 
> Thank you for a readable and easy to understand document.There is one comment I would like to resolve prior to IETF LC. The others can be resolved along with any last call feedback.
> 
> *** Please resolve prior to IETF LC ***
> 
> §4: The relaxation of authentication requirements for DTLS-SRTP and SDES could use some elaboration on why this acceptable. I _think_ the answer is that, since OSRTP doesn’t guaranty authentication, there’s no need for such a guaranty from the signaling channel. Is that correct?
> 
> OTOH, §1 says "third mode for security between "cleartext” and "comprehensive protection" that allows encryption and authentication to be used if supported…”. That suggests that that authentication is sometimes provided. Is there a distinction between the authenticated case and unauthenticated case that should be mentioned somewhere? (For example, is there a need to indicate the distinction to the user?)
> 
> *** Other Substantive Comments ***
> 
> §2: Please use the new boilerplate from RFC 8174.
> 
> §3.1: Please clarify that that the offer can contain more than one key management attribute. This is mentioned in §3.1, but not actually in the section on generating the offer.
> 
> *** Editorial Comments ***
> 
> §3: "As discussed in [RFC7435], this is
> the "comprehensive protection" for media mode.”
> s/this/that
> 
> §3.4: "meaning that the decision to
> create an OSRTP type offer or something else should not be influenced”
> That’s referring to the decision to create a _new_ offer, right? Not the original offer?
> 
> 
>