Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16

Gunnar Hellström <> Fri, 07 May 2021 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C39FE3A2703; Fri, 7 May 2021 08:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jpl004rh7ntQ; Fri, 7 May 2021 08:45:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 615C23A26FF; Fri, 7 May 2021 08:45:37 -0700 (PDT)
Received: from [] ( []) (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) (Authenticated sender: by (Postfix) with ESMTPSA id 2F951202E6; Fri, 7 May 2021 17:45:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1620402329; bh=aBAHJDy+SfWScR2XtSA1GJ6pB+95raK69GMCkTtfhsw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKM/TJTI+6DaWJQ5aa01JNOgl2OaHWNLzJGQ5ATHxwaTVYADubGr75moPTCrWd1yG bZ9L0LzvaCrqbFXOe59eSvMQGNQtNT4Qreazb8bWdoaiAOjvJ+XN8x03PXgsZBGzr2 SvSMIIJ6JzgcZ12sGojRuWJvZl5DJx8HHkckr2q0=
To: Rich Salz <>,
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Fri, 7 May 2021 17:45:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------CE9D9C7C43DF755520DB6DEC"
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 May 2021 15:45:44 -0000


Thanks for the review.

I am composing a new version because of the Gen-ART review, and want to 
propose changes to satisfy your comments.

You ask if it is common to have the mixers being trusted.

In the expected first implementation environments for this draft, it is. 
That is in emergency service networks. Also in personal communication 
services it is.

The first implementation environments are also expected to use the SIP 
centralized conference model (RFC 4353 etc.) where all media are 
expected to be mixed centrally. Thus the security aspects would be 
similar for audio, video and real-time text.

I have tried to elaborate a bit more on this in a modified security 
considerations section, currently looking like this and being ready for 
submission together with the changes because of the Gen-ART review. 
Would this satisfy your concerns?

--------Proposed security concerns--------------------

11.  Security Considerations

    The RTP-mixer model requires the mixer to be allowed to decrypt,
    pack, and encrypt secured text from the conference participants.
    Therefore the mixer needs to be trusted to achieve security in
    confidentiality and integrity.  This situation is similar to the
    situation for handling audio and video media in centralized mixers.

    The requirement to transfer information about the user in RTCP
    reports in SDES, CNAME, and NAME fields, and in conference
    notifications, for creation of labels may have privacy concerns as
    already stated in RFC 3550 [RFC3550], and may be restricted for
    privacy reasons.  The receiving user will then get a more symbolic
    label for the source.

    Participants with malicious intentions may appear and e.g., disturb
    the multiparty session by emitting a continuous flow of text.  They
    may also send text that appears to originate from other participants.
    Counteractions should be to require secure signaling, media and
    authentication, and to provide higher level conference functions
    e.g., for blocking, muting, and expelling participants.

    Further security considerations specific for this application are
    specified in Section 3.19.



Gunnar Hellström

Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:
> Reviewer: Rich Salz
> Review result: Ready
> This review is for the benefit of the Security AD's. Nobody else should read
> this. Or, if you read it, treat it as any other last call review :)
> I know very little about WebRTC, AVT, etc.
> I thought Section 1.2, summary of the alternatives, was great. I wish more
> documents did this kind of thing. And similar for all of section 2. The details
> in Section 3 about how to comply seem very clear. If I were implementing this,
> I could use easily use this as a checklist and test suite. Section 3.19 is the
> most important one for transport security. Not knowing the operating
> environments, it seems reasonable.
> The security considerations seems a little scant, given the opportunity for
> privacy concerns of participants and for intruders to disrupt calls. Is it
> common that the mixer is a trusted entity? A statement on that either way would
> be useful.
> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström