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

From: Alissa Cooper <[email-masked]>
Date: Fri, 11 Sep 2015 16:10:39 -0700

Stephen, thoughts on this?

Thanks,
Alissa

> On Jul 23, 2015, at 7:19 AM, Charles Eckel (eckelcu) <[email-masked]> 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)" <[email-masked]> 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"
>> <[email-masked] on behalf of [email-masked]> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/siprec
>> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 12 Sep 2015 00:58:19 +0100

Hiya,

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 12 Sep 2015 00:34:41 +0000

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" <[email-masked]> wrote:

>>>>> Please refer to
>>>>>https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 25 Sep 2015 11:00:07 -0700

Stephen, does this work for you?

Thanks,
Alissa

> On Sep 11, 2015, at 5:34 PM, Charles Eckel (eckelcu) <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Sep 2015 19:59:46 +0100

Hiya,

> Stephen, does this work for you?

Sorry for the slow response.

>> audit or compliance purposes), EKT is likely not an appropriate

Yes, that addresses the issue, thanks.

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

Cheers,
S.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 25 Sep 2015 20:36:53 +0000

>Yes, that addresses the issue, thanks.

Great.

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

Ok.

Cheers,
Charles

>>>>>>> in the CS to send traffic that appears to be from other
>>>>>>>participants
>>>>>>> and