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

Stephen, thoughts on this?

Thanks,
Alissa

> On Jul 23, 2015, at 7:19 AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> 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)" <eckelcu@cisco.com> 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"
>> <siprec-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> 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
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>> 
> 