Re: [siprec] Stephen Farrell's Discuss on draft-ietf-siprec-protocol-17: (with DISCUSS and COMMENT)

["Charles Eckel (eckelcu)" <[e-mail]>]

On 9/25/15, 11:59 AM, "Stephen Farrell" <[e-mail]> wrote:

>
>Hiya,
>
>On 25/09/15 19:00, Alissa Cooper wrote:
>> Stephen, does this work for you?
>
>Sorry for the slow response.
>
>> 
>> Thanks,
>> Alissa
>> 
>>> On Sep 11, 2015, at 5:34 PM, Charles Eckel (eckelcu)
>>><[e-mail]> wrote:
>>>
>>> I have added the following note to my working version of the draft,
>>>which
>>> will become draft-ietf-siprec-protocol-18:
>>>
>>> Note: When using EKT in this manner, it is possible for
>>> participants in the CS to send traffic that appears to be from
>>> other participants and have this forwarded by the SRC to the SRS
>>> within the RS. If this is a concern (e.g. the RS is intended for
>>> audit or compliance purposes), EKT is likely not an appropriate
>>> choice.
>
>Yes, that addresses the issue, thanks.

Great.

>
>I'd suggest s/likely not/not/ would be better.

Ok.

Cheers,
Charles

>
>Cheers,
>S.
>
>>>
>>>
>>> Cheers,
>>> Charles
>>>
>>>
>>>
>>>
>>> On 9/11/15, 4:58 PM, "Stephen Farrell" <[e-mail]>
>>>wrote:
>>>
>>>>
>>>> Hiya,
>>>>
>>>> On 12/09/15 00:10, Alissa Cooper wrote:
>>>>> Stephen, thoughts on this?
>>>>
>>>> Thought#1: I've lost context;-)
>>>>
>>>> Thought#2; I met with Charles in Prague after that was sent (I think)
>>>> and explained the kinds of change that could sort this out. Basically,
>>>> (iirc) either you explain that this scheme is only moderately secure
>>>> (so not e.g. suited for large financial transaction scenarios) or else
>>>> you change it to ensure that the call participants cannot fake the
>>>> recording even if they have access the the right/wrong bit of network.
>>>> But I may be mis-remembering.
>>>>
>>>> Anyway, having met with Charles I think he took an action to figure
>>>> out if the above kind of change worked in this case and I don't think
>>>> I've heard back since.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Alissa
>>>>>
>>>>>> On Jul 23, 2015, at 7:19 AM, Charles Eckel (eckelcu)
>>>>>> <[e-mail]> wrote:
>>>>>>
>>>>>> Hi Stephen,
>>>>>>
>>>>>> I was waiting for your answer to this and just now realized you
>>>>>>never
>>>>>> answered because I never asked anything. Seems my email suffered
>>>>>>from
>>>>>> being composed over two time periods and my brain lost the context
>>>>>>in
>>>>>> between. Please see below:
>>>>>>
>>>>>> On 7/15/15, 1:12 PM, "Charles Eckel (eckelcu)" <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Stephen,
>>>>>>>
>>>>>>> Please see in the proposed change (inline) would address your
>>>>>>> remaining
>>>>>>> concern.
>>>>>>>
>>>>>>> On 7/13/15, 4:36 PM, "siprec on behalf of Stephen Farrell"
>>>>>>> <[e-mail] on behalf of [e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Stephen Farrell has entered the following ballot position for
>>>>>>>> draft-ietf-siprec-protocol-17: Discuss
>>>>>>>>
>>>>>>>> When responding, please keep the subject line intact and reply to
>>>>>>>>all
>>>>>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>>>>>> this
>>>>>>>> introductory paragraph, however.)
>>>>>>>>
>>>>>>>>
>>>>>>>> Please refer to
>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>>>>
>>>>>>>>
>>>>>>>> The document, along with other ballot positions, can be found
>>>>>>>>here:
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>>-------------------------------------------------------------------
>>>>>>>>---
>>>>>>>> DISCUSS:
>>>>>>>>
>>>>>>>> 
>>>>>>>>-------------------------------------------------------------------
>>>>>>>>---
>>>>>>>>
>>>>>>>>
>>>>>>>> (1) cleared
>>>>>>>>
>>>>>>>> (2) 12.2: Thanks for fixing up the ekt reference. I still
>>>>>>>> would like to know how, in a case where the recording
>>>>>>>> is for audit/compliance purposes, one can ever allow
>>>>>>>> the RS to not be re-encrypted since that creates the
>>>>>>>> potential for the CS peers to fake the traffic to the RS.
>>>>>>>
>>>>>>> Section 12.2 currently reads as follows:
>>>>>>>
>>>>>>> At a minimum, the SRC and SRS MUST support the SDP
>>>>>>> Security Descriptions (SDES) key negotiation mechanism [RFC4568].
>>>>>>> For cases in which DTLS-SRTP is used to encrypt a CS media stream,
>>>>>>>an
>>>>>>> SRC may use SRTP Encrypted Key Transport (EKT)
>>>>>>> [I-D.ietf-avtcore-srtp-ekt] in order to use SRTP-SDES in the RS
>>>>>>> without needing to re-encrypt the media.
>>>>>>
>>>>>> How about if I add the following text to the next version of the
>>>>>>draft?
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note that when using EKT in this manner, it is possible for
>>>>>>> participants
>>>>>>> in the CS to send traffic that appears to be from other
>>>>>>>participants
>>>>>>> and
>>>>>>> have this forwarded by the SRC to the SRS within the RS. If this
>>>>>>>is a
>>>>>>> concern (e.g. the RS is intended for audit or compliance purposes),
>>>>>>> EKT is
>>>>>>> likely not an appropriate choice.
>>>>>>
>>>>>> Would that address your remaining concern?
>>>>>>
>>>>>> Cheers,
>>>>>> Charles
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Charles
>>>>>>>
>>>>>>>>
>>>>>>>> (3) cleared
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>>-------------------------------------------------------------------
>>>>>>>>---
>>>>>>>> COMMENT:
>>>>>>>>
>>>>>>>> 
>>>>>>>>-------------------------------------------------------------------
>>>>>>>>---
>>>>>>>>
>>>>>>>>
>>>>>>>> I had a discuss point that said: "5.3: How does a UA know if
>>>>>>>> it's preference to not be recorded has been ignored?"
>>>>>>>> Maybe there's a missing timer there.
>>>>>>>>
>>>>>>>> I also had a discuss point that said:
>>>>>>>> I'll clear once you answer: but wouldn't it be easier
>>>>>>>> all around to just mandate use of mutually authenticated
>>>>>>>> TLS between SRC and SRS in all cases?  (Even if some
>>>>>>>> hop-by-hop stuff is needed when there are proxies between
>>>>>>>> SRC and SRS.) Also - how is it ok to ever not re-encrypt
>>>>>>>> the media in the RS since if you do not, anyone from the
>>>>>>>> CS who has the right session key can send the SRS bogus
>>>>>>>> packets that it'll accept.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> siprec mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>
>>>>>>
>>>>>
>>>
>>