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

[Gonzalo Camarillo <[e-mail]>]

Hi Ben,

when do you think you will be able to look into this? Thanks!

Cheers,

Gonzalo

On 08-Apr-19 13:49, Gonzalo Camarillo wrote:
> 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
>>
>