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

Roman Shpount <roman@telurix.com> Tue, 16 May 2017 14:29 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 3889A12EAB6 for <mmusic@ietfa.amsl.com>; Tue, 16 May 2017 07:29:18 -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 iOJG_umpPB_U for <mmusic@ietfa.amsl.com>; Tue, 16 May 2017 07:29:16 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 31BEF12EBE0 for <mmusic@ietf.org>; Tue, 16 May 2017 07:24:57 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id u28so77284877pgn.1 for <mmusic@ietf.org>; Tue, 16 May 2017 07:24:57 -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=7E+T9Rnr6Zn/OqYPhS1phTWP05rYql+xWVQmYr8klC4=; b=owONb/M6QERUQ53f6qogwKD/bwQudWRJ73BlgHGJttt+yFKFLaJYv6yaHrUVqW3s6x Dro5TgvX0tCJCtWolXhllUtcMs3wyCWRC5iyxRrv066uYBdkiZ7Fo1Kt7TtdETCblizp DrvH0siyiOZuV2YTYec4Wr7SnmDsbVxJOYHsH7AMkZ/2tX8zyVZs/gBWG8DJ5fRR8Wi2 sr+t5VPdvGi38rB44+A2fUmKr7O0eaEvx70XWJsr2VYW/+hZNl14/bifeU5ovZIPnURf 4aqCN1EjLaWzEIO3YMV+TMdvxvaQoUYiwq0u6dn4KabDsNvRqgDLSAOnZ8HpLF1Loe5x jvTQ==
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=7E+T9Rnr6Zn/OqYPhS1phTWP05rYql+xWVQmYr8klC4=; b=PLjq86XwFvbtWrPRQxmJqtgeCdALeUVsv0D+8vKUhVm0Oo4sYrFfREVP51UTsOibMR LAmlEfz/fw51+FfKuhVWCZXiChuvx7/o8rwabIxNrWqSl0mP/8vPng41fB6m+vAJ30uW qLfSTl0T425WSxi2R36lLVz8P4PO5SGuRTlmiHkj2gBjUqAtUpiw+uoy2kbvyJP6Yg5n 5Ui0B9dix9Fo6K0LbW4tAEQQQ8WpfY1hWYwWN3m1yM1i9JpxT7R2ZDfYukef4aj7Vy82 P32xCNOMkerGJrynZSoJ/dvsKDlBFzwnO8CLKyQfMLLqEh+XxUDlbNf0j7QI1Z5NeXu+ p+Uw==
X-Gm-Message-State: AODbwcADbgAOIwys/vLLkgP8ftHpbisyBMAAafzJOIcKKhxUGK6xUORH iZ4M7FVxZZgFVENh
X-Received: by 10.84.128.33 with SMTP id 30mr16044607pla.111.1494944695102; Tue, 16 May 2017 07:24:55 -0700 (PDT)
Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com. [74.125.83.50]) by smtp.gmail.com with ESMTPSA id f24sm24950726pfk.66.2017.05.16.07.24.53 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 07:24:54 -0700 (PDT)
Received: by mail-pg0-f50.google.com with SMTP id x64so57828835pgd.3 for <mmusic@ietf.org>; Tue, 16 May 2017 07:24:53 -0700 (PDT)
X-Received: by 10.99.163.67 with SMTP id v3mr12773369pgn.210.1494944693070; Tue, 16 May 2017 07:24:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.150 with HTTP; Tue, 16 May 2017 07:24:52 -0700 (PDT)
In-Reply-To: <CABcZeBN+91+kf8j599CpdiHu62QoOu4Xbkb5xhEEwSQp_LGxFw@mail.gmail.com>
References: <D5407B8A.1C98B%christer.holmberg@ericsson.com> <CABcZeBN+91+kf8j599CpdiHu62QoOu4Xbkb5xhEEwSQp_LGxFw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 16 May 2017 10:24:52 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsFwbQPK2jz-BnS3Re6df2tU1RzuFgWx1f8xKio6NdJTQ@mail.gmail.com>
Message-ID: <CAD5OKxsFwbQPK2jz-BnS3Re6df2tU1RzuFgWx1f8xKio6NdJTQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="f4030436399c63bb31054fa4efd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/y-UxOZuFEWP0eNqSUeojtzWR0YI>
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, 16 May 2017 14:29:18 -0000

On Tue, May 16, 2017 at 9:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Mon, May 15, 2017 at 11:43 PM, 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 may have missed their comments, but I don't understand why you would
> make that
> rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint
> at this
> point anyway, because you don't have the cert.
>
> It's one thing not to determine that the handshake is complete until you
> receive
> the answer, but that's different from not sending the SH. That seems
> silly. [0]
>
>
First of all, draft-thomson-mmusic-sdp-uks puts tls-id from the answer in
ClientHello. This tls-id can be used to identify that received ClientHello
is related to the current signaling exchange and refuse other ClientHello
messages.

Second, not sending ServerAnswer until signaling answer is received,
prevents unverified media and removes significant number of execution paths
that would need to be defined both in the dtls-id specification and then
tested during development and interop of compliant solutions. I do not want
to spend time defining this unless it is absolutely necessary.

As a small historic reference, all that previous versions of specifications
said is that ClientHello can be received by the offering party before the
answer is received. It did not specify how such ClientHello should be
processed. Webrtc group in W3C asked how unverified media should be
handled. We have determined that this should not occur with WebRTC end
points, but this does point out that handling of unverified media is indeed
undefined. I think dtls-id is the right place to specify this and the
simplest thing I can see is to prohibit it.

Regards,
_____________
Roman Shpount