Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK)

Brian Rosen <br@brianrosen.net> Wed, 10 April 2019 14:31 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9317B1202E7 for <rum@ietfa.amsl.com>; Wed, 10 Apr 2019 07:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPrKEmOGPZKz for <rum@ietfa.amsl.com>; Wed, 10 Apr 2019 07:31:06 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776B0120021 for <rum@ietf.org>; Wed, 10 Apr 2019 07:31:06 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id n68so1348529qka.1 for <rum@ietf.org>; Wed, 10 Apr 2019 07:31:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7wEdfyZgkz+RAvRPgY50g2joWMkImoBlha7p3lSDDM=; b=GaYs9P8l6mbO8pAZSZKPRn6vB/v6Ktx5Fj4xQs5i9YN153cHAY3hh8cPhrAmPwuaXc JCbkiJWIBCxNocRoCr3feMBZME/mVYlX9VEmdd5+RtE3+VYSUOUmy6+M73CPbwq6/h/z Ky3qDFd267fg+32qX4NvOJG+Wk5UigrNKUjKks1dexKkl3bAlR9M5nnX8lPCmhxDl0vu iHDapLLSWNXacHFO7E8O1sFkw38mxMJ41Sgzp1jLYH8SYt0roR3631Rw8WistgH2CANd ntVKUm2qEa4mSVB+EJ8PFS4hlmR48vlvF4SJdNwBrQtNFQRg2Csz2K1RziyCZqPwcQbU 9H+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7wEdfyZgkz+RAvRPgY50g2joWMkImoBlha7p3lSDDM=; b=HtBz1IKJ8cUquDn9DIn/ybfjB+co80H7FRMcJm0jMC3A+u0lH1DXCHPb3Il2Orw4vg ofw/Abt/zDqfKHo498KYrh9KdEzC/ql5KeqW1ezFHiWgGq/KR+chuEwMZccIaMNTMB7O ogP47J2oNsDZN2KXl6i2aptpjY3eBab7YfBAIMxNgq8oJ6qw1vDzKDhUdPIu7HQO5Vrx O/YpQKJfZyl9+ElEg0KXtOeYXWDmwReTia6dUg34tpNFSu8qOcIQcsP5V4FcuxJwJopQ AVIfIg4MCRVekVCHZ00SNp7J6XOPYagK4aM0nyXhGO30pcoFAhyFo2q5VfKFF2lBknfZ h5NA==
X-Gm-Message-State: APjAAAWnnU6tWpRSQ0iAfp85TpXbFhWh9uvle9Qfask4OvUBuNApcJZK 2CU3KJQFXO/DVlmVWO+YF1lxrd3gkjo=
X-Google-Smtp-Source: APXvYqzIpUVPEHNzwtdkx8499ggtd7+uB/g3ZMUnY+LP34aEmUG6gshOvWj3aEJAuN9JTBY/vmkJ4A==
X-Received: by 2002:a37:9d06:: with SMTP id g6mr33980701qke.25.1554906665354; Wed, 10 Apr 2019 07:31:05 -0700 (PDT)
Received: from brians-mbp-4.lan ([24.129.255.66]) by smtp.gmail.com with ESMTPSA id m18sm22183384qki.64.2019.04.10.07.31.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 07:31:04 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com>
Date: Wed, 10 Apr 2019 10:31:02 -0400
Cc: The IESG <iesg@ietf.org>, rum-chairs@ietf.org, rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA3E3783-314B-4CCF-B920-3C70C2C9BDBC@brianrosen.net>
References: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/2IkCukA7qtUyyL921nRbzI4C90k>
Subject: Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK)
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 14:31:08 -0000

The profile will most certainly include all the best practice security mechanisms for SIP.  The charter discusses using the most up to date media plane recommendations, which are the WebRTC recommendations, including DTLS-SRTP, and we will require TLS in the signaling plane.   As these are UAs, and not proxy servers, the usual security mechanisms for registration will be required.  We certainly don’t plan to innovate other than exploring the issues raised of explicit man-in-the-middle, but we will require all implementations to maintain current best practice on security mechanisms.  We’ll craft some language to include in the charter.  

Maybe: The profile will specify current best practice security mechanisms for SIP based end devices as mandatory to implement



> On Apr 10, 2019, at 9:39 AM, Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> 
> Magnus Westerlund has entered the following ballot position for
> charter-ietf-rum-00-02: Block
> 
> 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.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-rum/
> 
> 
> 
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
> 
> Why are the no discussion of security mechanism being part of the profile?
> Considering that the profile includes the media plane, I assume at least
> mandatory to implement media protection security mechansism and what ciphers
> should be defined. Then is the of the key-management and its tie into the
> establishment signalling. I understand that one want to establisha  a border
> for what is in scope and out of scope. But as I read the charter now it is
> completely missing.
> 
> All that I find are this part:
> The working group will consider issues related to authentication of the
> parties involved in the video relay call. No protocol changes are anticipated
> by this work.
> 
> This sounds like actually discusssing the security model. It is possible to be
> more explicit of how one handle the fact that one have three parties, where
> only one part talks to both.
> 
> 
> 
>