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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 13 Jul 2015 16:36:56 -0700

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.

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 15 Jul 2015 20:12:30 +0000

Hi Stephen,

Please see in the proposed change (inline) would address your remaining
concern.

>https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/

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.

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.

Cheers,
Charles
 
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 23 Jul 2015 14:19:29 +0000

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:

>   without needing to re-encrypt the media.

How about if I add the following text to the next version of the draft?

>likely not an appropriate choice.

Would that address your remaining concern?

Cheers,
Charles