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

[Stephen Farrell <[e-mail]>]

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