IETF Logo Mail Archive

Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?

Cullen Jennings <fluffy@iii.ca> Tue, 23 May 2017 02:39 UTC

Return-Path: <fluffy@iii.ca>
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 D20A8126DED for <mmusic@ietfa.amsl.com>; Mon, 22 May 2017 19:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xjQA0rcteTgE for <mmusic@ietfa.amsl.com>; Mon, 22 May 2017 19:39:42 -0700 (PDT)
Received: from smtp90.ord1d.emailsrvr.com (smtp90.ord1d.emailsrvr.com [184.106.54.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54F0126557 for <mmusic@ietf.org>; Mon, 22 May 2017 19:39:42 -0700 (PDT)
Received: from smtp4.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id E67274005A; Mon, 22 May 2017 22:39:41 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp4.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7C30740059; Mon, 22 May 2017 22:39:41 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 22 May 2017 22:39:41 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <D5407B8A.1C98B%christer.holmberg@ericsson.com>
Date: Mon, 22 May 2017 20:39:40 -0600
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <178E77C7-CB9B-4D5D-A0F9-627153C03FEE@iii.ca>
References: <D5407B8A.1C98B%christer.holmberg@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/XwM3GZiuMHJTrRa76NDxHJn95hc>
Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer?
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: Tue, 23 May 2017 02:39:44 -0000

> On May 16, 2017, at 12:43 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> The pull request based on the WGLC comments from Roman S and Martin T,
> suggests text saying that if an offerer receives ClientHello it must not
> send ServerHello until it has received the answer (that carries the
> fingerprint associated with the DTLS association).

I strongly disagree with adding this at this level. Consider for example an endpoint that does not do ICE. Will you also wait until the identity checks are complete to check that the fingerprint is valid and not inserted by a MITM? That might make sense for WebRTC but it is something specified at a much higher system level than here. This should just be a building block that allows systems to use dtls-sdp as they see fit instead of trying to mandate how it will be used at a higher level.

v2.23.0 | Report a Bug | By Email