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

[Stephen Farrell <[e-mail]>]

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.

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

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
>>>>>>
>>>>>
>>>>
>>
>