Re: [MMUSIC] Unknown key shares in MMUSIC

Roman Shpount <roman@telurix.com> Fri, 17 March 2017 16:24 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB861294DC for <mmusic@ietfa.amsl.com>; Fri, 17 Mar 2017 09:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.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 LLZjPVJ-CLrt for <mmusic@ietfa.amsl.com>; Fri, 17 Mar 2017 09:24:15 -0700 (PDT)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 EB45B1294D7 for <mmusic@ietf.org>; Fri, 17 Mar 2017 09:24:14 -0700 (PDT)
Received: by mail-pg0-x22c.google.com with SMTP id g2so44733496pge.3 for <mmusic@ietf.org>; Fri, 17 Mar 2017 09:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.99.51.76 with SMTP id z73mr17113133pgz.137.1489767854345; Fri, 17 Mar 2017 09:24:14 -0700 (PDT)
Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com. [74.125.83.45]) by smtp.gmail.com with ESMTPSA id y6sm17933301pgc.1.2017.03.17.09.24.13 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 09:24:13 -0700 (PDT)
Received: by mail-pg0-f45.google.com with SMTP id n190so44965378pga.0 for <mmusic@ietf.org>; Fri, 17 Mar 2017 09:24:13 -0700 (PDT)
X-Received: by 10.99.225.5 with SMTP id z5mr16819141pgh.145.1489767853205; Fri, 17 Mar 2017 09:24:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.162.5 with HTTP; Fri, 17 Mar 2017 09:24:12 -0700 (PDT)
In-Reply-To: <CABkgnnVrx8qfD0AfOVb7AfS_7+8tGyohc8cSZ79dkBaReC8R_Q@mail.gmail.com>
References: <CABkgnnXJvyZxmhU94VZAHNjWeaVoeThVBQVTDv0x3rLBtRrn4Q@mail.gmail.com> <CAD5OKxtmz8cP+hmJF6bq7VTX5SOduS5=U-e17iCiAs12KOa5MQ@mail.gmail.com> <CABkgnnVrx8qfD0AfOVb7AfS_7+8tGyohc8cSZ79dkBaReC8R_Q@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 17 Mar 2017 12:24:12 -0400
X-Gmail-Original-Message-ID: <CAD5OKxvhna1nVv11b0DCuGuUVgVBdHgN14dE6uzHADoYhP0CLA@mail.gmail.com>
Message-ID: <CAD5OKxvhna1nVv11b0DCuGuUVgVBdHgN14dE6uzHADoYhP0CLA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary=001a114e93a4b03a8c054aef9b0f
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/6EoJfppxNIPOMiwmpI3mu7Wl_Lo>
Subject: Re: [MMUSIC] Unknown key shares in MMUSIC
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 16:24:17 -0000

On Thu, Mar 16, 2017 at 9:40 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 17 March 2017 at 03:14, Roman Shpount <roman@telurix.com> 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
transmitted.

Regards,
_____________
Roman Shpount