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

Sorry about the delay.

See below.

I will update the draft.

Andy

On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo
<gonzalo.camarillo@ericsson.com> wrote:
>
> Thanks for the quick review, Ben!
>
> Authors, please address Ben's comments below.
>
> Cheers,
>
> Gonzalo
>
> On 14-Feb-19 22:46, Ben Campbell wrote:
> > 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?)
> >

$1 should I think say "allows encryption and authenticated media" but
I cannot remember why we said the signalling authentication
requirements are relaxed this has been in the draft from day 1 and I
guess it is consistent with the best effort approach.

Anyone else want to comment?

> > *** Other Substantive Comments ***
> >
> > §2: Please use the new boilerplate from RFC 8174.

Will do.

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

Will do.

> >
> > *** Editorial Comments ***
> >
> > §3: "As discussed in [RFC7435], this is
> > the "comprehensive protection" for media mode.”
> > s/this/that

Thanks

> >
> > §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?

Correct.

> >
> >
> >
> > _______________________________________________
> > Sipbrandy mailing list
> > Sipbrandy@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipbrandy
> >
> _______________________________________________
> Sipbrandy mailing list
> Sipbrandy@ietf.org
> https://www.ietf.org/mailman/listinfo/sipbrandy