Subject: Re: [siprec] Ben Campbell's Discuss on draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jul 2015 16:23:17 -0700

On Jun 23, 2015, at 11:00 AM, Paul Kyzivat <[email-masked]> wrote:

> On 6/22/15 7:36 PM, Ben Campbell wrote:
> 
>>> A recording-aware UA MUST provide a recording indication to the end user
>>> through an appropriate user interface, indicating whether recording is
>>> on, off, or paused for each medium. Appropriate user interfaces may
>>> include real-time notification or previously established agreements that
>>> use of the device is subject to recording.  Some user agents that are
>>> automatons (e.g., IVR, media server, PSTN gateway) may not have a user
>>> interface to render recording indication.  When such a user agent
>>> indicates recording awareness, the UA SHOULD render recording indication
>>> through other means, such as passing an in-band tone on the PSTN
>>> gateway, putting the recording indication in a log file, or raising an
>>> application event in a VoiceXML dialog.  These user agents MAY also
>>> choose not to indicate recording awareness, thereby relying on whatever
>>> mechanism an SRC chooses to indicate recording, such as playing a tone
>>> in-band.
>> 
>> I don't think that addresses my concern. There's a fundamental
>> difference between an indication that this call is being recorded, and
>> an agreement that all calls might be recorded. (Unless that agreement
>> says all calls _will_ be recorded). The language here seems to conflate
>> the two.
>> 
>> I realize that the following is mostly in the domain of lawyers and not
>> engineers--but what happens when my mobile operator puts a "may record"
>> clause in my user agreement. That seems to qualify under the language
>> used here.
> 
> I appreciate your concern. I would be *very* unhappy if a carrier put such language in my contract. I can imagine that this could be presented as a non-negotiable condition of service, though I consider that to be entirely unreasonable. (However, whether the language is there or not, in practice that is what the current situation is in the US with CALEA.)

The clause may make you unhappy, but at least in the way I was reading the text in the draft, that is sort of beside the point. If you are told that your calls may be recorded, then you can conservatively assume that they all will be. In this sense it doesn’t really matter how the recording indication is provided to you. Whether you receive a real-time notification or the recording indication specified in this draft or a written agreement, there is no protocol mechanism that allows you to verify that the call is _actually_ being recorded. The point is that you should assume you’re being recorded and then decide what to do from there.

So I don’t think the existing language in the draft can really be improved.

Alissa

> 
> OTOH, there are situations where this is entirely appropriate - the call center case, or for stock brokers - there there are requirements to record. Certainly in the call center case it would be a problem to include an indication of recording in the audio stream to the agent. Potentially a call center agent work station could have other means to indicate recording. But that would exclude some common existing equipment. Also, in the call center case, if there is an indication, then there would probably be a preference by management to always indicate that calls are being recorded, even if they might not be, so that the agent wouldn't know when he was being recorded. Also, this overlaps with active listening (by conferencing in a supervisor) that is technically (and legally?) distinct from recording and yet has similar concerns.
> 
> It is unclear here how to balance the concerns. I'm certainly open to suggestions about how best to do this.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 2 Jul 2015 18:26:55 +0000

On 6/22/15, 7:36 PM, "Ben Campbell" <[email-masked]> wrote:

>Hi, thanks for the response. Comments inline. (I removed things that
>don't seem to need discussion)
>
>Ben.
>
>On 18 Jun 2015, at 18:49, Charles Eckel (eckelcu) wrote:
>
>> Hi Ben,
>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I am concerned that this draft allows the recording session to
>>> downgrade
>>> security from the communication session. It says "SHOULD NOT", but
>>> then
>>> explicitly allows for the downgrade when the SRC and SRS are in the
>>> same
>>> administrative domain. This seems to create a whole new "last hop
>>> exception" for media, similar to the one for SIPS that we took so
>>> many
>>> years to deprecate. (Except it's worse because the potentially
>>> insecure
>>> hop goes to an endpoint not necessarily expected to be a party to the
>>> media.)
>>
>> Andy explained as follows:
>>
>> "I think the issue here is that the SRC and SRS will often be
>> co-located
>> in an environment where mutual authentication was just not necessary
>> and
>> therefore the WG did not want to mandate this in all cases.²
>>
>
>I think Andy's comments were to Stephen's discuss about mutual
>authentication in general. This is a somewhat different issue. I'm
>talking about when the participants of a call chosen to use certain
>security protections on the CS, and the SRC and SRS downgrade that for
>the RS.
>
>(and by the way, I wrote that it says "SHOULD NOT" in my discussion, but
>the text in 12 actually says "should not". That should probably be
>capitalized unless it's stated elsewhere in caps.)

Good point. I have changed to “SHOULD NOT”.

>
>>>
>>> Section 6.1.2 includes a "contract in place" as a form of recording
>>> indication. The other mechanisms seem to say that a given call is
>>> being
>>> recorded. A contract cannot do that, except in the degenerate case of
>>> "all calls are recorded." This doesn't seem to fit the spirit of the
>>> "MUST provide recording indication" language.
>>
>> I expanded section 6.3 in an attempt to address similar concerns:
>>

This point is being discussed in another thread.

>
>>
>>
>>
>>>
>>> Section 12, 2nd paragraph says the SRC and SRS "MUST support SIP with
>>> TLS
>>> and MAY support SIPS with
>>> TLS as per [RFC5630]". That actually downgrades the requirement for
>>> SIPS support from that in 3261/5630. (3261 says you MUST support SIPS
>>> if
>>> you support TLS.)
>>
>> As noted in RFC 5630, SIPS was underspecified in RFC 3261 and this was
>> a
>> source of confusion. RFC 5360 aimed to fix this, and states:
>>
>> Because a SIPS URI implies that requests sent to the resource
>> identified by it be sent over each SIP hop over TLS, SIPS URIs are
>> not suitable for "best-effort TLS": they are only suitable for "TLS-
>> only" requests.  This is recognized in Section 26.2.2 of [RFC3261]
>> <http://tools.ietf.org/html/rfc3261#section-26.2.2>.
>> Users that distribute a SIPS URI as an address-of-record may elect
>>    to operate devices that refuse requests over insecure transports.
>> If one wants to use "best-effort TLS" for SIP, one just needs to use
>> a SIP URI, and send the request over TLS.
>
>The quoted language is about when it might not be appropriate to _use_
>SIPS. It doesn't talk at all about _support_ requirements. In
>particular, it does not relax the 3261 requirement that says "Any
>implementation that supports TLS MUST support the SIPS URI scheme."

I see. I will change from “MAY support SIPS” to “MAY use SIPS” as I
believe that is what was actually intended here in the first place.

>
>>
>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>
>[...]
>
>>
>>>
>>> -- 5.2: UPDATE needs a citation to 3311. Also, 3311 "RECOMMENDS"
>>> reINVITEs over UPDATEs for confirmed dialogs. It would be helpful to
>>> add
>>> some motivation as to why this draft seems to prefer UPDATE.
>>
>> Added a citation. UPDATE is preferred, actually required, for the SRS
>> to
>> request to snapshot, but re-INVITE or UPDATE can be used by the SRC to
>> send metadata. I don¹t believe any preference was meant to be
>> implied.
>> UPDATE was chosen for the SRS to request metadata because it could be
>> sent
>> regardless of the state of the dialog. This was seen as better than
>> requiring support for both UPDATE and re-INVITE for this operation.
>
>It would be worth adding a sentence or two to that effect.

Ok. I added this.

>
>>
>>>
>>> -- 5.3: It seems odd to me that the SRC can ignore an explicit
>>> preference
>>> not to record. Wouldn't it be better just to refuse to
>>> complete/accept
>>> the call, if some policy overrides the end-user's preference?
>>
>> We decided to leave this choice to the user, who can drop the call if
>> the
>> recording state of the call is not acceptable to the user.
>
>That choice makes it considerably more likely for a user to accidentally
>allow themselves to be recorded when they intended not to.

Yes, that is the tradeoff. We call it a recording preference and treat it
as just that, a preference. Depending on how much the user wants to not be
recorded vs. how much they want to participate in the call, the user gets
to decide whether to drop or not.

>
>>
>>>
>>> -- Figure 3: If the UA prefers not to be recorded, shouldn't it
>>> express
>>> that at setup time, rather than wait for the SRC to indicate
>>> recording is
>>> happening? As shown, this almost guarantees a bit of media will be
>>> recorded. (Seems like there should be some guidance about this in the
>>> text.) The last paragraph of 6.1.2 seems to reinforce the problem by
>>> suggesting the participant might base the decision to express a
>>> preference on a tag that is optional for the SRC to send in the first
>>> place.
>>
>> Yes, but in this case the example read, "After the call is established
>> and
>> recording is in progress, UA (B) later decides to change the recording
>> preference to no recording². This real time interaction seemed useful
>> as a
>> example. More examples can be added if necessary.
>> Note that the use of the a=record attribute is REQUIRED when
>> recording. It
>> is not optional.
>
>Whether there are more examples or not, it would be useful to have a
>discussion of the implications of expressing a recording preference
>proactively vs reactively.

I add the following:

Note that UA (B) could have explicitly indicated a recording preference in
(2), the 200 OK for the original INVITE. Indicating a preference of no
recording in an initial INVITE or an initial response to an INVITE may
reduce the chance of a user being recorded in the first place.

>
>
>>
>>>
>>> -- 6.3, last paragraph: It seems odd that the requirement to render a
>>> recording indicator be lower for a media server than for other UAs.
>>> This
>>> seems to circumvent user notification in one of the most common uses
>>> of
>>> recording these days.
>>
>> This section was reworded, as quoted in my previous comment.
>
>The rewording still has the issue. a recording aware UA MUST provide a
>recording indication. UAs without appropriate user interfaces (like
>IVRs, media servers, etc) SHOULD indicate this some other way. SHOULD is
>a lower requirement than MUST.

It is a SHOULD because of the MAY at the end:

These user agents MAY also choose not to indicate recording awareness,
thereby relying on whatever mechanism an SRC chooses to indicate
recording, such as playing a tone in-band.

>
>>
>>>
>>> -- 9.1 : The last bullet seems to be a motivation to not send
>>> metadata at
>>> all, which is expressly forbidden in the first paragraph.
>>
>> This was meant to illustrate that the SRC may not record everything to
>> which it has access, with privacy concerns being one example. I
>> suppose
>> such filtering could be performed later on the recorded content, but
>> that
>> assumes a specific relationship the administrative domain of the SRC
>> and
>> that of the SRS.
>
>So does "not record everything" include the ability to send no metadata?

That is not recording, as opposed to recording and not sending any
metadata. There is some metadata that is always requires per the XML
schema.

> 
>Perhaps the first sentence in 9.1 that says "The SRC MUST send metadata"
>is overstated?
>
>>
>>>
>>> -- 9.2: The use of  the content-type value as the sole indicator that
>>> the
>>> an UPDATE request should be interpreted as an request for a metadata
>>> snapshot update is rather odd.  If you end up with new kinds of
>>> metadata
>>> requests in the future, does each one get it's own media-type?
>>
>> This is being sorted out in another thread. I agree, something needs
>> to
>> change here.
>
>Understood, I will watch that thread.
>
>>
>>>
>>> -- 12: If this doc is to depend on the security considerations in
>>> 6341,
>>> that needs to be a normative reference--which is a bit of a pain
>>> because
>>> I think it's an informational RFC.
>>
>> We tried to avoid this with the language "The use cases and
>> requirements
>> document [RFC6341] outlines the general security considerations, and
>> this
>> document describes specific security recommendations.²
>
>Could the reader fully understand the security considerations without
>reading 6341? If so, then informational is okay.

I believe so.

>
>>
>>>
>>> -- 12.1:
>>> "recording session uses TLS" -- I assume that's for SIP? Also It's
>>> worth
>>> discussing how mutual authentication applies if the SRC is in an
>>> end-user
>>> device. Is it expected to have a client cert? No option to use  SIP
>>> identity?
>>>
>>> Also, I'm a bit uncomfortable assuming devices in the same
>>> administrative
>>> domain automatically trust each other. It might be better to say "If
>>> they
>>> trust each other..."
>>
>> Using the word ³trust" is a slippery slope as well.
>
>The text already uses that word. It says that if the SRS and SRC are in
>the same domain, they have an inherent trust relationship. That's not
>always the case.

I changed to:

In deployments where the SRC and the SRS are in the same administrative
domain and have some other means of assuring authenticity, the SRC and SRS
may choose not to authenticate each other, or to have the SRC authenticate
the SRS only.

>
>> For a UA acting as a
>> SRC, the implied requirement is that it has a cert.
>
>Better to be explicit.

Ok. I added:

In deployments where a UA acts as its own SRC, this requires the UA have
its own certificate as needed for TLS mutual authentication.

>[...]

Cheers,
Charles

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 02 Jul 2015 17:04:55 -0500

Hi, comments inline (again with closed items removed.)

> Good point. I have changed to “SHOULD NOT”.

Thanks! But did you have any response to the previous paragraph?

[... deleting section marked as being discussed in another thread. ...]

[...]

> believe that is what was actually intended here in the first place.

That would resolve my concern, thanks!

[...]

> to decide whether to drop or not.

Okay. For the record, I don't like that trade-off. But I accept that the 
working group chose it, and will hold my nose and move on.

[...]

> recording, such as playing a tone in-band.

So do you really mean (SHOULD do A, but MAY do B) or (MUST do A or B, 
and SHOULD do A)? The first can be interpreted non-exhaustively. That 
is, SHOULD, unless you have a good reason otherwise and understand the 
implications, with the MAY part being an example.

But in any case, on re-reading this, I have a new point of confusion. If 
the UA in question doesn't indicate recording-awareness, it is 
effectively not recording aware. The logic seems to be of the form of "a 
recording aware UA MUST/SHOULD do this, or elect not to be 
recording-aware." That's really no different than saying "a 
recording-aware UA MUST do this"

(I realize I am being pedantic here--but given that mistakes in this 
area can result in users being recorded without their knowledge, I think 
it deserves as much precision as possible.)

[...]

[ deleted another section discussed in another thread.]

>> reading 6341? If so, then informational is okay.

Okay, I re-read both sections, and agree with you.

[...]

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 02 Jul 2015 17:11:37 -0500

On 1 Jul 2015, at 18:23, Alissa Cooper wrote:

> I appreciate your concern. I would be *very* unhappy if a carrier put 
> such language in my contract. I can imagine that this could be 
> presented as a non-negotiable condition of service, though I consider 
> that to be entirely unreasonable. (However, whether the language is 
> there or not, in practice that is what the current situation is in the 
> US with CALEA.)
>
>
> The clause may make you unhappy, but at least in the way I was reading 
> the text in the draft, that is sort of beside the point. If you are 
> told that your calls may be recorded, then you can conservatively 
> assume that they all will be. In this sense it doesn’t really matter 
> how the recording indication is provided to you. Whether you receive a 
> real-time notification or the recording indication specified in this 
> draft or a written agreement, there is no protocol mechanism that 
> allows you to verify that the call is _actually_ being recorded. The 
> point is that you should assume you’re being recorded and then 
> decide what to do from there.
>

Alissa's comment is compelling. I recognize that that nothing requires 
me to "like" such language, only to make certain privacy assumptions due 
to it. And I guess a carrier hiding such language deep in terms of 
service, or making it a requirement for service at all, is better dealt 
with by organizations who are not the IETF.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 6 Jul 2015 17:05:27 +0000

Hi Ben,

Glad we are trimming the list. Please see my thoughts on your remaining
items inline.

>Thanks! But did you have any response to the previous paragraph?

The draft currently reads as follows:

"The Recording Session SHOULD be at least
   as secure as the Communication Session, meaning using at least the
   same strength of cipher suite as the CS if the CS is secured.  For
   example, if the CS uses SIPS for signaling and RTP/SAVP for media,
   then the RS SHOULD NOT downgrade the level of security in the RS to
   SIP or plain RTP since doing so will mean an effective security
   downgrade for the CS.  In deployments where the SRC and the SRS are
   in the same administrative domain and the same physical switch that
   prevents outside user access, some SRCs may choose to lower the level
   of security when establishing a recording session.  While physically
   securing the SRC and SRS may prevent an outside attacker from
   accessing important call recordings, this still does not prevent an
   inside attacker from accessing the internal network to gain access to
   the call recordings.”

I’m not sure what more we can say. Is it worth adding more lipstick to the
pig? If so, let me know what you think would be helpful.

>it deserves as much precision as possible.)

The alternative is to specify that a recording-aware MUST indicate a
recording preference in all SDP offers/answers. In the case of having a no
preference, this would result in explicitly indicating “a=recordpref:
nopreference”. Keep in mind that the recording preference impacts the
current recording state of the call. It is not merely a future
recommendation of some sort. Furthermore, implementations already exist
that are recording aware and do not set this preference indication because
it was either not defined or not required by the version of the draft
against which they were implemented.

>Okay, I re-read both sections, and agree with you.

Great. And thanks again for all the thorough review and comments.

Cheers,
Charles