IETF Logo Mail Archive

Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 04 September 2017 14:37 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 156241321AF for <mmusic@ietfa.amsl.com>; Mon, 4 Sep 2017 07:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 1p6-yTY92gML for <mmusic@ietfa.amsl.com>; Mon, 4 Sep 2017 07:37:25 -0700 (PDT)
Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFEE11321A6 for <mmusic@ietf.org>; Mon, 4 Sep 2017 07:37:23 -0700 (PDT)
X-AuditID: 12074414-0d3ff70000006ddf-ae-59ad65228983
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CF.53.28127.2256DA95; Mon, 4 Sep 2017 10:37:22 -0400 (EDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v84EbKRd009801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Mon, 4 Sep 2017 10:37:22 -0400
To: mmusic@ietf.org
References: <f353ad39-4ee5-4661-8e99-7fab6e394e91@nostrum.com> <CAOW+2dtv8r7qTyNxWY8NacfEh+Ojk5ObVAXEur3D4GyMw89YaQ@mail.gmail.com> <CABcZeBOJgyva5e-ykH-RkKN=BJPrXVYLu8vZbbNBv0xscv6bOA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <CABcZeBNv4fdFTJ+tXeBkMDqbMCEw916Txt8owFY-X7ijX0-FcA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <CABcZeBNh9ep+tq4_wWHT6uqXZz=OS8VngrmtspPz5nJ=pZS0ow@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> <CABcZeBPj6e=rtYHr4nyqeaB58TDBEjyB0xYeJJ+P63rO0DSw+A@mail.gmail.com> <D5D30222.20F35%christer.holmberg@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <b5a72f26-8bae-7eb8-4d54-93dc38b0f16a@alum.mit.edu>
Date: Mon, 04 Sep 2017 10:37:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <D5D30222.20F35%christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqKuUujbSoKPdymLq8scsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLBhNmPBevaKk8e4Gxi/sXYxcnJICJhILN1ykLGLkYtDSGAH k8SlQ7tYIZxvTBJn1ixk6mLk4BAWMJQ4cYYFpEFEQFhixtu/bBA181klPj4/yQySYBPQkphz 6D9YEa+AvcSrj0/B4iwCKhIv1q0Cs0UF0iT+7T7LCFEjKHFy5hOwek4BG4kFnyeyg9jMAmYS 8zY/ZIawxSVuPZnPBGHLSzRvnc08gZF/FpL2WUhaZiFpmYWkZQEjyypGucSc0lzd3MTMnOLU ZN3i5MS8vNQiXQu93MwSvdSU0k2MkKAU2cF45KTcIUYBDkYlHt6I0LWRQqyJZcWVuYcYJTmY lER5j4YAhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwPksEyvGmJFZWpRblw6SkOViUxHm/LVb3 ExJITyxJzU5NLUgtgsnKcHAoSfD+TgZqFCxKTU+tSMvMKUFIM3FwggznARquD1LDW1yQmFuc mQ6RP8VozNH0YcsXJo5fM7d+YRJiycvPS5US5+UCKRUAKc0ozYObBkssrxjFgZ4T5n0AUsUD TEpw814BrWICWlX1cg3IqpJEhJRUA2Om0MdJOxS0G2/e23K2e/3v9/x5Yh1nW079kzaoOO7w N3baxIkWTUvnzSlgYNCxlM5InXRis8+flsLqY0snHLFl5A2ykre4eUNilnhd6cljPrNm2/pm bLZ4svyBo2yhuoZsxYEwPiuNtkcK0Z4ZbCLsmScONyfmZRdw6z6TXJVgYpoYWnH/qhJLcUai oRZzUXEiABNi3CQHAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/eZAHUs5zU9f43Wc9_eJ-T9A_tHs>
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
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: Mon, 04 Sep 2017 14:37:27 -0000

On 9/4/17 6:14 AM, Christer Holmberg wrote:

>>> Now, based on your suggestion, if the offerer doesn¹t know whether the
>>> answerer supports tls-id, does that mean that the only way
>>> for the offerer to ensure that the re-offer will trigger a new DTLS
>>> association is by modifying the fingerprint set in the offer?
>>
>> That's true in any case, because we have implementations which behave
>> that way and we can't change them.
> 
> On GitHub you also suggested
> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer,
> even if it supports tls-id, shall not be able to trigger a new DTLS
> association (read: change the tls-id value). I assume that means the
> answerer would not be able to change its fingerprint set either, or do
> anything else that would trigger a new DTLS association?

Why would you want to *prevent* the answerer from triggering a new DTLS 
association???

	Thanks,
	Paul

v2.23.0 | Report a Bug | By Email