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

[Alissa Cooper <[e-mail]>]

Stephen, does this work for you?

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