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

I submitted an update in response to Ben's comments -
https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08

With regard to Ben's comment on the relaxing of the authentication
requirement then this is consistent with the Opportunistic Security
RFC 7435 and I added a reference to this as clarification.

Hopefully we can get this to RFC status now.

Regards
Andy

On Mon, 25 Mar 2019 at 22:26, Andy Hutton <andyhutton.ietf@gmail.com> wrote:
>
> 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