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

[Gonzalo Camarillo <[e-mail]>]

Hi Ben,

could you please look into what Andy ways and confirm whether or not you
are happy with the current revision of the draft? Thanks!

Cheers,

Gonzalo

On 08-Apr-19 13:47, Andy Hutton wrote:
> I looked at this again and I am not convinced that any further changes
> to the draft are needed but if someone wants to suggest text then I
> can include it in the draft.
> 
> In the case of SDES the security considerations states that an
> encrypted signalling channel must still be used so this draft changes
> nothing with respect to intermediaries and the SDES (RFC 4568)
> security considerations still apply.
> 
> Regards
> Andy
> 
> On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo
> <[e-mail]> wrote:
>>
>> Hi Andy,
>>
>> Ben's response below indicates that his main substantive comment was not
>> addressed in the revision you submitted last week. Could you please look
>> into it and get back to Ben? Thanks!
>>
>>>> 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.
>>>
>>> If I recall correctly, RFC 7435 does not discuss scenarios with
>>> separate signaling and media channels, and how OS applies to each
>>> channel. I was looking more for something about the impacts of this
>>> “relaxation” specific to these sorts of scenarios with dtls-srtp and
>>> sdes, and resulting assurances.
>>>
>>> For example, dtls-srtp with no authentication does not give you
>>> assurances about who you are talking to, but it still allows
>>> encryption. SDES without encryption lets an eavesdropper potentially
>>> learn the encryption keys, etc. SDES with transport level protection
>>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxies
>>> and b2bua’s in the signaling path to learn the encryption keys.
>>
>>
>> Cheers,
>>
>> Gonzalo
>>
>> On 02-Apr-19 16:50, Andy Hutton wrote:
>>> I believe all Ben's points are addressed in the draft I submitted
>>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08
>>>
>>> Regards Andy
>>>
>>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo
>>> <[e-mail]> wrote:
>>>>
>>>> Hi Andy, authors,
>>>>
>>>> could you please let Alexey when he should expect a new revision of
>>>> this draft that addresses Ben's point below?
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>> On 26-Mar-19 18:10, Ben Campbell wrote:
>>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD)
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for the response. This does not quite address my main
>>>>> substantive comment. It does address everything else :-)
>>>>>
>>>>> Please see comment in line.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ben.
>>>>>
>>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton
>>>>>> <[e-mail]> wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> If I recall correctly, RFC 7435 does not discuss scenarios with
>>>>> separate signaling and media channels, and how OS applies to each
>>>>> channel. I was looking more for something about the impacts of
>>>>> this “relaxation” specific to these sorts of scenarios with
>>>>> dtls-srtp and sdes, and resulting assurances.
>>>>>
>>>>> For example, dtls-srtp with no authentication does not give you
>>>>> assurances about who you are talking to, but it still allows
>>>>> encryption. SDES without encryption lets an eavesdropper
>>>>> potentially learn the encryption keys, etc. SDES with transport
>>>>> level protection  (e.g. SIPS) protects from off-path
>>>>> eavesdroppers, but allows proxies and b2bua’s in the signaling
>>>>> path to learn the encryption keys.
>>>>>
>>>>>
>>>>>>
>>>>>> Hopefully we can get this to RFC status now.
>>>>>>
>>>>>> Regards Andy
>>>>>>
>>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton
>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>> Sorry about the delay.
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>> I will update the draft.
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo
>>>>>>> <[e-mail]> 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 [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy
>>>>>>>>>
>>>>>>>> _______________________________________________ Sipbrandy
>>>>>>>> mailing list [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy
>>>>>
>>>>
>>>
>>> _______________________________________________ Sipbrandy mailing
>>> list [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipbrandy
>>>
> 
> _______________________________________________
> Sipbrandy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipbrandy
>