IETF Logo Mail Archive

Re: [MMUSIC] Unknown key shares in MMUSIC

Martin Thomson <martin.thomson@gmail.com> Sun, 19 March 2017 23:11 UTC

Return-Path: <martin.thomson@gmail.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 9408C120025 for <mmusic@ietfa.amsl.com>; Sun, 19 Mar 2017 16:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bJzIqWVRAGO5 for <mmusic@ietfa.amsl.com>; Sun, 19 Mar 2017 16:11:49 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 E18BC126B7F for <mmusic@ietf.org>; Sun, 19 Mar 2017 16:11:48 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id 1so98481790qkl.3 for <mmusic@ietf.org>; Sun, 19 Mar 2017 16:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fCbjPXbMOLZlItvznu573DPpcfVxtRDCrUBEnpp2MGw=; b=HpY2AYzK0147utMATOH+/F3XI9LI/U01icfe0WssOM0OvUW2IcDwo9mM16EH5FKlyY yDWY9mJ6r1AMUuSUiJdc9yaBtNReTiSbhNn0IRmvT1aHzufECHc/JH2dTAN0fRU8w7ng NrsS0dyLuXLLoDNWPZqStAiDC4UrzxWPXejmYhTtk9coVbV6mti54XzZ5wowKCu/VxVV sXMnNpkqMXbapEp7YswTIIRvah2IJ2XEPzeUiuDC360pckhmjHdKXi8aiOsiHkRi50Vv 9DX8eYy+j7awnG/0UfqWG82uQ4ygotJscBg6dS8rpcP+RaNQ0bdwQof6si0g9qj8YP6D nhcA==
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=fCbjPXbMOLZlItvznu573DPpcfVxtRDCrUBEnpp2MGw=; b=bbl7pnaXAcoSvPCts+miZpumfU6r2QqR60PWJKCspDQgHboVd2qIwa7QUq0qJHG/ql mp/cTXoPVxX/U2UaB7Bgdggws90ggdV1nXnjLZr83rmmgYESsNsBXJh5l7IrPe94T8Sv Rkly8Kl7JJfe4Eb6YMODx6CMEQ2xB3/E2uWkjQZCk0rIDzmLBq4sprTgjWsvXlpPkaTp 1yakTXrt8xEXcS50vmdyDoho+4FEXiNgCYFaXd87pOeoVqQhNufL6y46aGie2Pgu5Kna Ipg4lDHRPvJXaD3OMXvthmqqkjnUg/B/JYextiAOTP3RQXFfzPA6p+0cjLiNpnZqPWMO /WBQ==
X-Gm-Message-State: AFeK/H1Qbr1xbMbRxf9IQhLSKQk01Gv5UaniN7jn5HDAeghso48eAUAOMdlGFMor4iJbFwWr6dxhZEMaPmwlSw==
X-Received: by 10.55.27.219 with SMTP id m88mr21627134qkh.147.1489965108052; Sun, 19 Mar 2017 16:11:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Sun, 19 Mar 2017 16:11:47 -0700 (PDT)
In-Reply-To: <CAD5OKxvhna1nVv11b0DCuGuUVgVBdHgN14dE6uzHADoYhP0CLA@mail.gmail.com>
References: <CABkgnnXJvyZxmhU94VZAHNjWeaVoeThVBQVTDv0x3rLBtRrn4Q@mail.gmail.com> <CAD5OKxtmz8cP+hmJF6bq7VTX5SOduS5=U-e17iCiAs12KOa5MQ@mail.gmail.com> <CABkgnnVrx8qfD0AfOVb7AfS_7+8tGyohc8cSZ79dkBaReC8R_Q@mail.gmail.com> <CAD5OKxvhna1nVv11b0DCuGuUVgVBdHgN14dE6uzHADoYhP0CLA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 20 Mar 2017 10:11:47 +1100
Message-ID: <CABkgnnWMSuqjLgrQ+fqx0CQgtMpG3ssYvZir78fQ9TfTjALT_A@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/f_88vZLGI7uHXhY-ymm6DqAj7qI>
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: Sun, 19 Mar 2017 23:11:51 -0000

On 18 March 2017 at 03:24, Roman Shpount <roman@telurix.com> wrote:
>> 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 was thinking that tls-id would apply in both situations, but only
carry the "new connection" semantics for DTLS.

v2.23.0 | Report a Bug | By Email