Re: [rtcweb] Tunnelling DTLS in SDP

Roman Shpount <roman@telurix.com> Mon, 18 April 2016 15:00 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB012D8FA for <rtcweb@ietfa.amsl.com>; Mon, 18 Apr 2016 08:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 03xTJ0wbEfMP for <rtcweb@ietfa.amsl.com>; Mon, 18 Apr 2016 07:59:58 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 6367212D7DA for <rtcweb@ietf.org>; Mon, 18 Apr 2016 07:59:58 -0700 (PDT)
Received: by mail-ig0-x235.google.com with SMTP id f1so74928932igr.1 for <rtcweb@ietf.org>; Mon, 18 Apr 2016 07:59:58 -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:date:message-id:subject:from:to :cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=zxFIcrIyBwDTqUO8NSUocuMoS0Vf/IH3vUy6E/+ozeJ6MsxjK7t3PkyyKvvrjVZinC jE+pL97SnQ0fpGs46VMsSo5dQfPMeZvZUpeTqbNBZHvlnQWEHjJetLbOmXBSvQPZd9Wm MtC9hON9/IZgL22/ylvRX1/F3rmQMsiOU/FvFBxctbBKgyvOAuKb6TnSA4zaHSsU4K7p YZ7cNirOrsW9pqLUQkNpuDTT+0p37Z6fCWyukH9nKKKMTnOpMQFJL3mkBMLNehqDPQvw G54TYeYBCCymXIldPOWJvivHVZdw+tF+LS4Lm5to0E65MpL2qqjSL+wfqw1JCwF7qccG zAcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=jCydJNGt6rXKx+dZvEGym24Pi5pMlxeWaj9ucd2zs7+8rha7ftzmubYXddpQChS5dr xmcsvMZH7c54n6SNiDmPI+dluY0gw1UpIgjOok3QiCTKbnnHoEfstb5kvlPy2qFF/MXa dW89Jo37rd1brMPFzlwGB40ryr0aYMsECas7eyPYJ2pq6kJ8cMTFL7BS2fVRdvunvc9F ml8MWK/YdnV63Hss6cI4B6HUTTTRx6PdyeajNiqsy+YMB2/a953U7Zz8wuQlLXKvTAck AaEcwPimnpcXhvpd00XU7Ueff3AoXDf7yyeaANN4Dpzl/YYF4yyT1i5yq4mVXgEXDQuT jK0w==
X-Gm-Message-State: AOPr4FXPE5agAFxtiiZ8OXDKQ1pNAc/5B79oooJ3A3uJSXWM64WKR/fbou6JMoT73FSKyw==
X-Received: by 10.50.118.225 with SMTP id kp1mr20644844igb.9.1460991597612; Mon, 18 Apr 2016 07:59:57 -0700 (PDT)
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id ke5sm3660185igb.17.2016.04.18.07.59.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
Received: by mail-io0-f169.google.com with SMTP id g185so197162200ioa.2; Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.160.141 with SMTP id j135mr42233717ioe.171.1460991596536; Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
Received: by 10.36.144.69 with HTTP; Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
In-Reply-To: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com>
References: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com>
Date: Mon, 18 Apr 2016 10:59:56 -0400
X-Gmail-Original-Message-ID: <CAD5OKxt2+YAJfR1q4qyhv_0D7AqMmrsTENTGNw-_vo9Dzr-ejA@mail.gmail.com>
Message-ID: <CAD5OKxt2+YAJfR1q4qyhv_0D7AqMmrsTENTGNw-_vo9Dzr-ejA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a1140a2b621b1a00530c39d18"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/jgRFByKoM12M6dcxOj5uk6SQzvk>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Subject: Re: [rtcweb] Tunnelling DTLS in SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2016 15:00:01 -0000

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> I wanted to call your attention to a draft I just published with a
> possibly stupid
> idea.
>
> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00
>
> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
> This document describes how to piggyback the first few handshake messages
> in the SDP offer/answer exchange, thus reducing latency.
>
> Comments welcome.
>
>
One other issue I thought off was that with DTLS SDP either offerer or
answerer can start a new DTLS association. When answerer starts a new
session it will have exactly the same problems as forking, since this will
create multiple DTLS sessions with the same client random. This can be
solved with some sort of fallback mechanism to either regular DTLS setup or
to sending a ClientHello in the answer.

Regards,
_____________
Roman Shpount