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

[Gonzalo Camarillo <[e-mail]>]

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
>