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

Martin Thomson <martin.thomson@gmail.com> Tue, 23 May 2017 10:26 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 5A42C126E64 for <mmusic@ietfa.amsl.com>; Tue, 23 May 2017 03:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] 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 E_TP8VKS5_qx for <mmusic@ietfa.amsl.com>; Tue, 23 May 2017 03:26:00 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 A3B64124C27 for <mmusic@ietf.org>; Tue, 23 May 2017 03:25:59 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id a5so32067929lfh.2 for <mmusic@ietf.org>; Tue, 23 May 2017 03:25:59 -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=gRQIBtEsN6WnVEWP6eHS0zvntXyHVGf9k7ugEtRjw5g=; b=bTkEPXM4NFEQv+0tY0mZ4qHdgaDyrwaAIzi8EQkOCVLVzbHMyqGlnC0pqzGPoCzwSx iyWpArDnZswE4NWRTfRlKlI/3povLNXn+R+uOGYmH1oz/A94qkr/irNt+pTlBz+WkZeL 0qXwCFCACdmrCKFUo5wA1uv+x1Z/hAeRe8YQ69cR6RrxTLeO18YULq63H4Usbh6WpHVH mytHZDml3gWIWiOOgWpD+wC//IfRObsbsvXjMqocfgzDhQrk5B/jNuElX1TcCopWNVH5 FMDhhTZTKu4o4NFuV9RwlVE0c0fguc/A7ZuhMy6y6Y/fJR0O3LPS3NmEtTQm0ItrCayk bmHA==
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=gRQIBtEsN6WnVEWP6eHS0zvntXyHVGf9k7ugEtRjw5g=; b=ma37jQ5oH+ScAmAWae1ugdBdLqnyeB7IaOk9goB89F5YeVZ1mpaEfF49k5AjSv9V8B 9ccHvrvPi9Q91xCr8RCjm2TkSMk+uLsAiWYUXZp3AOjdvBN/wv0VBM3kP/xl53GnHVzW jcj9A/LWE0FVVX8zmSdyk7YRgCmgSWqxAEy9MeeTxbSnk4Qv1vf7KbCSv1mXumAIXpm4 Mmx+H9tHFuJurEJRP5eLsX9ivyI2YJkPEJWay6UwlYRySnCsooeooH8mDut5GZQs0uTJ NPMSYjvK4BhmAKDx+2q9hiHRMC9W1gpI1Z5xG//zA/qefZSC7ZVPZGFASqQA8/f4CAcG X0iQ==
X-Gm-Message-State: AODbwcBezMPQJYpIFOwiMMzxEq0UFRW+f8OlSdFdwGx3gLWlYTDhLiDi HXa2OX6CrxM9qbEKdXV4XW6SubAlNpE3M7I=
X-Received: by 10.46.69.130 with SMTP id s124mr7458255lja.44.1495535157865; Tue, 23 May 2017 03:25:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.22.73 with HTTP; Tue, 23 May 2017 03:25:57 -0700 (PDT)
In-Reply-To: <D549E62B.1D0A3%christer.holmberg@ericsson.com>
References: <D5407B8A.1C98B%christer.holmberg@ericsson.com> <CABcZeBN+91+kf8j599CpdiHu62QoOu4Xbkb5xhEEwSQp_LGxFw@mail.gmail.com> <CAD5OKxsFwbQPK2jz-BnS3Re6df2tU1RzuFgWx1f8xKio6NdJTQ@mail.gmail.com> <CABcZeBNoOaZaotNjz35CT=9Vb8ktHysnp9hZZu4=yK3oz5=2Fw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> <D5487BC2.1CF8E%christer.holmberg@ericsson.com> <CABkgnnXzzKMWrPaGq6mho=Dmq7Hjbi_G4Ng1O6LBCTL-1Pt-hA@mail.gmail.com> <D549E2A8.1D08C%christer.holmberg@ericsson.com> <CABkgnnXY+uwW=iPjT3O=TmnYj4CD-PYRYkSMTWc5QiFEVBsNiA@mail.gmail.com> <D549E62B.1D0A3%christer.holmberg@ericsson.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 23 May 2017 20:25:57 +1000
Message-ID: <CABkgnnWSm0T3n0Lrqx3WCqDmPutLDXtkfwK8Pc+0fYdJa+q=hw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/FMUkcOZLidT-SOfQgp1ppg8HM_c>
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 10:26:01 -0000

On 23 May 2017 at 20:15, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> But, what about data received before the completion is received?

Well, I'd prefer to drop that, because buffering is tricky, but as I
said, holding it without even decrypting it could work.

Note that many DTLS-SRTP implementations won't even allow you to call
the exporter until the handshake is complete.  In order to even get
the data to arrive you have to do some inadvisable things to the
stack, such as accepting the peer's certificate, then you have to kill
the connection when the a=fingerprint arrives and doesn't match.  It's
much easier to validate inline.

> Also, if I understand the FEDEX use-case, not only would you have to be
> able to receive media - if you are e.g., going to provide DTMFs you could
> also have to SEND data? Or?

Yeah, sending DTMF to who-knows isn't a good idea.  I'm not clear on
whether sending DTMF is part of the arrangement.  Sounds like a great
way to avoid tarriffs altogether; I'm surprised that service providers
would even allow that.

This is why I think that this "unverified media" is the wrong solution
here.  It's not impossible to have an authenticated session and
accomplish these goals.