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

Roman Shpount <roman@telurix.com> Mon, 05 June 2017 16:58 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 37D63127866 for <mmusic@ietfa.amsl.com>; Mon, 5 Jun 2017 09:58:41 -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 mb-SuN8NJmwr for <mmusic@ietfa.amsl.com>; Mon, 5 Jun 2017 09:58:39 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 5FD8E1277BB for <mmusic@ietf.org>; Mon, 5 Jun 2017 09:58:39 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id v18so13249788pgb.1 for <mmusic@ietf.org>; Mon, 05 Jun 2017 09:58:39 -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=4v2PiPyZD8Z9er1e790oLZXT+TBRXQuc1+p9DwywSMo=; b=lioAs28sTLprYpC2KNqymO0SOY5DBidCH2Vmjjnj5bVJkFmCnN7bKOaR+PtsWb/6e3 4Q70/h433jauD+RAe1ktnSb9ZexOQTvns1rG9wUH5nu1RZrsPY/Rd9gg2apCmYV+MjKR 6k7yBN5WQdw5BZnhNpQ8LCEARM/SVnyY2TZokVIRldwkjHB3Z9nt17fQgKvnuyVpwGjx DLNBq4EfpGSA6r753jCATUtJpHE5X6d2DUYKn9Cm6BaCbGOKNdnK3M4DDRA2H8R9cIsZ qmKPr2FpKkU8XeTfsWT9yR9vve+ZyWPJNcxNIJ4q+6R0lyqxNRVbsxprEnVAjRcNKs1y f/qA==
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=4v2PiPyZD8Z9er1e790oLZXT+TBRXQuc1+p9DwywSMo=; b=bCTIf70/HxwDuGstYfm8wEOXnHTnANoTsj9PwyB4RBK23S2mlNXMSxH/tQ+1a9R+m8 9NHaIr0NVVG7EdofyryY6oTS3TjyecMY79tzMyqYlDtlTixP9jrIPATMXhHFuWbfi/bn fZV7YyYhDxH8sJRnb67lJOW2DTJyL8/4OWUBTAxgiDhQ+L53/AqwUUGyoMN3zf4bMbts ZtHG5u2Ev6VB5ZBxdN6ngeWZ1kxJuFXnCHRAR8qNXr9JBE6zvu4vRKAQO/4VTMD/gluu mA2Jvhjww0PJOZrstVtRLQFcnhC8FG1rqjYkLnD4OkOWF7PE2crWCnbDXahukjK/hzVF 6UVQ==
X-Gm-Message-State: AODbwcCmffmNp6u45MFBmIcImx4T2i3SRQFqLpSwWIs1R3OiZyOKkyoN xp06U9As5L3ysNkptc0=
X-Received: by 10.84.191.165 with SMTP id a34mr16131045pld.136.1496681919006; Mon, 05 Jun 2017 09:58:39 -0700 (PDT)
Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id q6sm1827410pfi.129.2017.06.05.09.58.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 09:58:38 -0700 (PDT)
Received: by mail-pf0-f179.google.com with SMTP id m17so85698487pfg.3; Mon, 05 Jun 2017 09:58:38 -0700 (PDT)
X-Received: by 10.84.217.154 with SMTP id p26mr16084976pli.295.1496681917806; Mon, 05 Jun 2017 09:58:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.169.66 with HTTP; Mon, 5 Jun 2017 09:58:37 -0700 (PDT)
In-Reply-To: <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca>
References: <D551D683.1D429%christer.holmberg@ericsson.com> <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> <CAD5OKxujAuzJt4QD6JXKHkVd4JB_nO5Th6KXjavMBww=W4644Q@mail.gmail.com> <6125EAB1-A827-4E0F-B756-78F85BB411CD@iii.ca>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 05 Jun 2017 12:58:37 -0400
X-Gmail-Original-Message-ID: <CAD5OKxutcpUzh1yLA2kukmYmiHQg3+6fuXbaD0w73gzsAHEXzg@mail.gmail.com>
Message-ID: <CAD5OKxutcpUzh1yLA2kukmYmiHQg3+6fuXbaD0w73gzsAHEXzg@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: Ben Campbell <ben@nostrum.com>, Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>, Christer Holmberg <christer.holmberg@ericsson.com>, mmusic-chairs@ietf.org, mmusic <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c5a0c0d81dc0551396ae8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/bJa-2yS7E7zYRZFGfkM1wZtqhzk>
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: Mon, 05 Jun 2017 16:58:41 -0000

On Mon, Jun 5, 2017 at 10:03 AM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> > On May 31, 2017, at 4:51 PM, Roman Shpount <roman@telurix.com> wrote:
> >
> > 1. Starting DTLS handshake until the corresponded answer is received is
> NOT RECOMMENDED since it can result in unauthenticated media. If
> unauthenticated media is played to the end user, in cases such as early
> media in SIP calls, this should be indicated to the end user.
>
> No. Doing the handshake as quickly as possible is recommend - it's what
> you do with the media before you know who you are talking to that is the
> issue you are concerned with. And knowing who you are talking often
> involves much more than checking the fingerprint. So I don't agree this is
> not recommended.
>

There are also implementation issues with getting media and not playing it.
End point will still need to either buffer or somehow process the received
packets so that playback can be started when the answer is received. If
handshake is delayed until answer is received, none of this is an issue, so
implementation is simpler.

More importantly, I do not think new systems should be built without ICE. I
understand there are legacy implementations which use symmetric UDP for
media. In such cases it is allowed to complete handshake. Such solutions
are legacy and building new systems like this are not recommended. It is
recommended that new systems should implement full ICE, consent to send,
and do not complete DTLS handshake before an answer SDP is received.

Regards,
_____________
Roman Shpount