Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03

"Martin Thomson" <> Mon, 06 May 2019 04:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 331C21200A3; Sun, 5 May 2019 21:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=q833qCmi; dkim=pass (2048-bit key) header.b=1InmzXmZ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mAx6yeXc8S8Y; Sun, 5 May 2019 21:53:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C59CD1200A2; Sun, 5 May 2019 21:53:32 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id D4D9B2214E; Mon, 6 May 2019 00:53:31 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Mon, 06 May 2019 00:53:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=vgXFvDO2WgGnzX6Yr5Kg/1Ndxl64 5G/esmiJB2ZjVVc=; b=q833qCmisg7S/sSsB5zsUvBorfkNuaEz9zI4GhOKpeMc Fo8KB7clbJNOPIlkKZeP1WatrEKvI24D9kc0/61/hhg3l4Cv02ns65hXzyt5UTb8 17sGWtC9eIbbP5H/qqcUgY2srskdzhw8Cp6cG/fa9EEJ3pH+eBHGdiqJoRWQNkUY YUoPJfkWvrrfXy2srMa705uGgvE01MMzCBU6yy0JCofMiCC7fXDa4pPDZK/auKsp L83oILIhggm0/Qam7SjxcSNSduVymlzjBC7bCDBXNYKrp+NGDyGvDtqbh7+O5ThJ YKDVo050L/XSQP24/ZaZtWP20SW+iF54wJ3X3TyUbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=vgXFvD O2WgGnzX6Yr5Kg/1Ndxl645G/esmiJB2ZjVVc=; b=1InmzXmZ0KqRQP8baXIM0l C90xXGBeaccVIjm+xl9SKmi/up1f91zO8vDMaNnWTHxw/kcSxnT/XmybKxDIqlOz M9tnTgIJTNU3rOVawqUxnb3F3wAp9tbvWlnsN6NLhxFoXfA2zm8/ja2in9NHvghp y4tCo+wo5yBmMQX5FjCyYIYmsejVmP3zRNFUrmBlh6FVOfeF5rQ2qZOmiTfsKwdp Z5t5h3NmASeh8PZqeHpFh97+C9sNGCWABK92K4GHGvS+SsTcse2PYz5041Njk+Fq eD3rZLKPM1NKe5MMKk1J1NaTQyVJAg4EIjDZtEUSlP/5gqgIZG0iQC5cRuca+rcQ ==
X-ME-Sender: <xms:yr3PXNXsHy9EFB6MZ5zt3c1KwN_VFU-09Eh6o_ivIEmFjqQg19SJug>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucffoh hmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhho figvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:yr3PXJQEXtbRzaG2XfNTKsuAuQvjHljqo7awG99uV4D1foL81056TA> <xmx:yr3PXEFE3epURCgpl9WBFS4UjGbgsRZG37ErM9ZkJ56cyNoG0MpEvQ> <xmx:yr3PXBS9nuPCfPPw99AfUcdDNY-8_UEC7_qDFV00YEDIaG4MZ1zffg> <xmx:y73PXHxFySEUt9DGJ71aEzWWFi3vffbSI2DbX4MK201nCwN8okZQNg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78A057C6D9; Mon, 6 May 2019 00:53:30 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 06 May 2019 00:53:30 -0400
From: "Martin Thomson" <>
To: "Flemming Andreasen" <>, "Bo Burman" <>, mmusic <>, "Jon Peterson" <>, "Cullen Jennings" <>, "'Eric Rescorla'" <>
Cc: "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 May 2019 04:53:35 -0000

(I apologize for errors in adjusting quoting, our MTAs seem incompatible somehow.)

On Sat, May 4, 2019, at 07:28, Flemming Andreasen wrote:
> >   Or 3PCC can be used without SIP identity (maybe the WebRTC identity 
> > is used) and the attack would be relevant. 
> Can WebRTC identity be used with regular SIP ?
> That's not the impression I got from 
> (where 
> WebRTC identity is defined), nor do I think it should be since that 
> would:
>  a) Be redundant with the SIP Identiy information defined in RFC 8224 
> and hence require further treatment in terms of how you deal with 
> discrepancies between the two. 
>  b) Conflate session signaling (SIP) with media signaling (SDP). 

These are reasons for not using WebRTC Identity in regular SIP, but I don't believe the two to be *fundamentally* incompatible.  The latter is perhaps a good argument against the use of WebRTC Identity at all, but the split between media and session signaling and the relationship of each with the security properties of the system is probably a topic of discussion for another draft.  We're just trying to work out how to proceed with this little piece.

>  In any case, this is probably something that should be clarified in 
> draft-ietf-rtcweb-security-arch-18 (might as well do that now, since 
> you will ultimately get an SDP designated expert review from me on that 
> one that will ask the same). 

I'm sure that there's something worth saying there.  Not sure what other think, but I wouldn't expressly prohibit the use of the two in combination.  I would reduce this to pointing out that there is a potential for disagreement between the two that would be bad.

> > It might be good to categorically say that 3PCC - as described in RFC 3725 - is incompatible with RFC 8224.  Would that help clarify this bit?
>  I believe so. 

I've updated the PR with the following text (being the entire section on 3PCC):

Third-party call control (3PCC) {{?RFC3725}} is a technique where a signaling
peer establishes a call that is terminated by a different entity.  This attack
is very similar to the 3PCC technique, except where the TLS peers are aware of
the use of 3PCC.

3PCC as described in RFC 3725 is incompatible with SIP identity {{?SIP-ID}} as
SIP Identity relies on creating a binding between SIP requests and SDP.  The
controller is the only entity that generates SIP requests in RFC 3725.
Therefore, in a 3PCC context, only the use of the `fingerprint` attribute
without additional bindings or WebRTC identity {{?WEBRTC-SEC}} is possible.

For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of the
signaling so that they can correctly generate and check the TLS extensions.  For
a connection to be successfully established, a 3PCC controller needs to either
forward SDP without modification, or to avoid modifications to `fingerprint`,
`tls-id`, and `identity` attributes.  A controller that follows the best
practices in RFC 3725 is expected to forward SDP without modification, thus
ensuring the integrity of these attributes.

It is understood that this technique will prevent the use of 3PCC if peers have
different views of the involved identities, or the value of SDP `tls-id`

How does that work for you?