Re: [MMUSIC] Unknown key shares in MMUSIC

Roman Shpount <> Fri, 17 March 2017 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFB861294DC for <>; Fri, 17 Mar 2017 09:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LLZjPVJ-CLrt for <>; Fri, 17 Mar 2017 09:24:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB45B1294D7 for <>; Fri, 17 Mar 2017 09:24:14 -0700 (PDT)
Received: by with SMTP id g2so44733496pge.3 for <>; Fri, 17 Mar 2017 09:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=982cjjBfXBleP+Tzhid969Oe5NgLTlDCQ69pC78Cdkc=; b=gSotg+0vtNeQewb0jEUiOyTxB0FaMGWaFC6LIU26S8A30Y9n7BJ87nKXmfNIOHsmG+ MyUr7bOUr/OcrM4SsXtafxG75ibDwy05shJd9h2M39RgAcS6rjaiGkpH28QTT5a9UT1H jSL9Df8gcQ6TUEP69UcEUbJ1TASaEAY6VN88FHtqcaUrpr8QnAMoQugczZN+SxzbwMR4 T6KILMwB3ih8UNQHDxxT+Gk2fdsZARaqvHCJd9aV0mRwidVLUbQYTG5sBODxzdbvK4TB BFqn6/Yy7vulvc5MM2eVkb0izK2OYIXXPKGPIOaZIJznrm69WGBktthwp5ADTxzTFvJ7 SVzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=982cjjBfXBleP+Tzhid969Oe5NgLTlDCQ69pC78Cdkc=; b=BDBf0jdUVY8xU+cpng0zr+fptZInECex9HymgAnbqut2OUipyTHl0c0bQxWw72WZNC vZKNnPJfIczOIKb+TMCu5+CF2MzrGysBv4ZO5T3iC98zNIhEFC22EMp9hNOHdTVPJliM bqnmW0K9KOoeRrUOWVby/kS89D0qBZaIzf9/pV5zaBMh+yV8uYYyNzixudk9HvZaZ+NA Jo1F4pVpueayDA3Ehlk55OTtQHN8seu3KzrEyW23KwST4RWx5ZaLhMwU0qhd0f02DViy OhmQBnZAL7tsDuC7s2Z/CrWaOLdSaSJ/IlZFWBowSinBDH5dbgfCUvaPwPp3PYEhF2EA +gbg==
X-Gm-Message-State: AFeK/H3Mqo4AY6ivYS937Rl0cT77/tmdMYpCoi0yZ5PxkpEwQwRmwR1EuzKieSaCNcyjYw==
X-Received: by with SMTP id z73mr17113133pgz.137.1489767854345; Fri, 17 Mar 2017 09:24:14 -0700 (PDT)
Received: from ( []) by with ESMTPSA id y6sm17933301pgc.1.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 09:24:13 -0700 (PDT)
Received: by with SMTP id n190so44965378pga.0 for <>; Fri, 17 Mar 2017 09:24:13 -0700 (PDT)
X-Received: by with SMTP id z5mr16819141pgh.145.1489767853205; Fri, 17 Mar 2017 09:24:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Mar 2017 09:24:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Roman Shpount <>
Date: Fri, 17 Mar 2017 12:24:12 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a114e93a4b03a8c054aef9b0f"
Archived-At: <>
Subject: Re: [MMUSIC] Unknown key shares in MMUSIC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Mar 2017 16:24:17 -0000

On Thu, Mar 16, 2017 at 9:40 PM, Martin Thomson <>

> On 17 March 2017 at 03:14, Roman Shpount <> wrote:
> > Alternatively we can keep dtls-id the way it is currently defined and
> define
> > tls-id to be used for TLS-over-TCP  in the new draft.
> I could accept tls-id.  But if tls-id and dtls-id are the same and
> have similar semantics, then one attribute makes more sense.  Using a
> "tls"-named attribute in DTLS isn't going to cause any real problems.

The reason I am thinking different names can make sense is interaction of
dtls-id/tls-id with new connection establishment. The change in dtls-id
values is used to signal new DTLS association establishment. In case of
TLS-over-TCP, new connection establishment is signaled using
a=connection:new/existing SDP attribute. Do you want tls-id overwrite
connection attribute? Only allow to change tls-id when  a=connection:new is
present? I understand that tls-id and dtls-id carry similar meaning in your
newly proposed extension. Are they going to carry the same meaning in new
connection negotiation?

> I would also prefer a more generic name for the TLS extension itself. It
> > does not have to be related to SDP, so some sort of endpoint_id would
> work
> > better then sdp_dtls_id.
> The point is to explicitly tie the TLS negotiation to the SDP.  I was
> operating on the basis that SDP has a somewhat unique authentication
> arrangement and that there weren't many other examples like it.
> If you think that this could be made more general and applied to
> protocols that don't use SDP, that's probably true.  But I can't think
> of a protocol that uses the same basic mechanisms for authentication.
> I'd be open to a change if you could name an example.  I don't like
> building a general purpose mechanism with exactly one user; an example
> would help in choosing the right semantics.

One thing I can think of is ORTC. No SDP there, but the same issue that you
described is present there. Alternatively connection can be negotiated
using jingle. I do not think the issue you raised is specific to SDP, as a
format used to encode media stream description. This issue is specific to
identifying certificates by fingerprint, no matter how this fingerprint is

Roman Shpount