Re: [sipcore] How to signal that a conversation is being recorded

Brian Rosen <br@brianrosen.net> Tue, 07 March 2023 13:31 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B563FC14CEE4 for <sipcore@ietfa.amsl.com>; Tue, 7 Mar 2023 05:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=brianrosen.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QymP7Cvt7hcY for <sipcore@ietfa.amsl.com>; Tue, 7 Mar 2023 05:31:36 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7808EC14EB18 for <sipcore@ietf.org>; Tue, 7 Mar 2023 05:31:36 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id v10so5400904iox.8 for <sipcore@ietf.org>; Tue, 07 Mar 2023 05:31:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen.net; s=google; t=1678195895; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FN+pbO7Z/eU0GbD62158rjbFq91Q2Wzo0vfNTS7Q85k=; b=Y1GxMFH+4QKHtM28HK01EgIeAqWwztsmDjs6YrA6cuEhllFKklBKw/OXAo8kh7eOSo dJRXJFBNHkYUiaIYtzWmlJD++eSkjxQidDeIwbG8V9S3sdXlQGGJZuKyAJapIK2axA56 r4/XWMbVsJ1lUeqfD+9EtDkvYaeNpuvoxzfsc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678195895; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FN+pbO7Z/eU0GbD62158rjbFq91Q2Wzo0vfNTS7Q85k=; b=OtPxma3ZWdWMG9ogpSpWe8TGcOyxA0VxsOZDUs20SzYmCgZHJ0JCkY8TqAazKd0gDi LSRJ+7xUJbflC8063QFSxTW0XTbsz5LoL8LrB74CJAXqMiTNAf3epf1ntpcSOI//oT28 sUfFagwSu72ly2VOsN9XfYFaD/r6J/XF5V7wM9hsylkMtS/nVoxf4gSPsSdnv5gLrBi/ ZBLSbhsZgw+mCT2fe4H7zgBYATdrJgIySl8IjRgVSAQHYicEGDXcfhdfZl02i9ZL08cK 3ZiFm8cPlCgLw1rNfAVyoH5aQqpDlpqlBaySfzxPAnFHnpjP4eWUSIn1FXMXMtIgMwpi tXFg==
X-Gm-Message-State: AO0yUKXoVg019oJCUbXxki6nzvu2R2PI0frKTDefNSVLhYm32XSk/RCt /t6UzucaCpd5YswHVX5OmJQRy7M7zfu1XEN27f4=
X-Google-Smtp-Source: AK7set/tIQk5XIjUk0ayrBiN7Zanda9UuFy646POqVL5+zOa3SwtCVVhPIY2uoeVvPiR888UBTxZZw==
X-Received: by 2002:a05:6602:2b81:b0:740:7d21:d96f with SMTP id r1-20020a0566022b8100b007407d21d96fmr9240075iov.1.1678195895376; Tue, 07 Mar 2023 05:31:35 -0800 (PST)
Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id c9-20020a5d9a89000000b0073fd8ca79c6sm4163386iom.9.2023.03.07.05.31.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2023 05:31:34 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <25cd2876-3536-c494-f1fd-152ed0013751@comcast.net>
Date: Tue, 07 Mar 2023 08:31:23 -0500
Cc: sipcore@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F8CADCA-CC0B-49E8-9970-97667266CA7F@brianrosen.net>
References: <082A7485-5C3C-4356-88A8-6A333A07D60D@brianrosen.net> <25cd2876-3536-c494-f1fd-152ed0013751@comcast.net>
To: Paul Kyzivat <paul.kyzivat@comcast.net>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/8fJrSE8sRqX61srQmJjrCavBU1M>
Subject: Re: [sipcore] How to signal that a conversation is being recorded
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2023 13:31:40 -0000

The only legal constraints I know (and IANAL) is the requirement to tell the other party that you are recording.

I do understand the issue of a malicious actor in the middle of the path.  My use case wouldn’t have that problem, but the general case would.  I suspect that we would note that in the security considerations and suggest that the recording entity insert the indications in the media if they are worried about that threat.  Real fixes would be messy: round-trip with some material only known to the endpoint?  Something like a digital signature with a cert known by the originator as the identity of the recipient?

Brian

> On Mar 6, 2023, at 10:05 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
> 
> Brian,
> 
> Are there legal constraints here?
> 
> I presume that the party doing the recording has a legal obligation to ensure an indication makes it to the other participants that are being recorded. OTOH there may be others in the call that might wish to suppress the indication, to one or more of the participants.
> 
> If the indication is in the signaling, then everybody in the signaling path has an opportunity to meddle with the indication.
> 
> That is potentially also true if the indication is in the media. But it may at least be a lot harder to do.
> 
> I have no recommendation yet, just exploring.
> 
> 	Thanks,
> 	Paul
> 
> On 3/6/23 5:51 PM, Brian Rosen wrote:
>> Many are familiar with a requirement to insert an audible indication of a voice call being recorded, and in some circumstances, visible indication of a video recording.   SIPREC provides the recording mechanism, and it’s possible for the SIPREC client to insert the indications.  This doesn’t work very well in applications like emergency services, where recording often happens in multiple places.  We don’t want multiple media insertions.  The usual SIP way to do things like this is to pass the indication as data in signaling, and render the audio/video/whatever locally.
>> Suppose we wanted to do that: we would need to pass to all endpoints (think conference) the information that the session was being recorded.
>> Does that make sense?
>> What would you suggest we use to carry that indication?
>> Brian
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore