Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

Roman Shpount <roman@telurix.com> Thu, 28 May 2015 23:05 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394C51ACDDF for <mmusic@ietfa.amsl.com>; Thu, 28 May 2015 16:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 xXFyO8MZRGl3 for <mmusic@ietfa.amsl.com>; Thu, 28 May 2015 16:05:39 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 6429F1ACDE6 for <mmusic@ietf.org>; Thu, 28 May 2015 16:05:39 -0700 (PDT)
Received: by qkx62 with SMTP id 62so35380602qkx.3 for <mmusic@ietf.org>; Thu, 28 May 2015 16:05:38 -0700 (PDT)
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:content-type; bh=gQQDXafE9wSBraMxjs3pqRmhfVAmE1et3hhmwY7jOFA=; b=JAJzG/10eOleAVbDp9DhWILDdNEU1L/yNysCPQhQ6GRupIlNx06Q3gmpKIL86T+asF uvGJnkLo7G4hXWdWBuX4ehjIbIKANM/kiPTdFmnKJL28V2zKHD8Z0jqNK4SMc70NH1+E Rd+5l+uGYamfyNZqcj5A61f+j+nfEQoOAvC291Y+MrY+Dz87zqeiq1gJNoeyhzdQQqk1 AsUo0NdiCD/HXRGfKn8whPysxiKAwFVzAOfYd303R9LWncmKk5zsaAtl/7kMIYpLwTXf 6cn8zEzyr93hstQCiJqO3ktZr2FQ9HPJhx8l7H2HGkQpVvGXpWSYTrU9MCe0eFybZgIm 88Pg==
X-Gm-Message-State: ALoCoQmPAr4dUzgBhInGuqvxg4OgHfx4+0dglxlxjzMFREGgQvnkkORSPFI6FwVo0ORVYJkmkAPy
X-Received: by 10.140.231.80 with SMTP id b77mr6679115qhc.82.1432854338603; Thu, 28 May 2015 16:05:38 -0700 (PDT)
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com. [209.85.220.169]) by mx.google.com with ESMTPSA id h60sm1775467qgh.18.2015.05.28.16.05.37 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 16:05:37 -0700 (PDT)
Received: by qkoo18 with SMTP id o18so35522252qko.1 for <mmusic@ietf.org>; Thu, 28 May 2015 16:05:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.16.67 with SMTP id a64mr10452342qkh.31.1432854336682; Thu, 28 May 2015 16:05:36 -0700 (PDT)
Received: by 10.96.130.162 with HTTP; Thu, 28 May 2015 16:05:36 -0700 (PDT)
In-Reply-To: <CAD5OKxsu=uYqpFQ2Rko9gViCxRdiOudF6wbd618jy6CEFnjV_w@mail.gmail.com>
References: <7594FB04B1934943A5C02806D1A2204B1D852384@ESESSMB209.ericsson.se> <55634C34.4080304@alum.mit.edu> <5565838D.2020005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D866141@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E7D3EEB@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAD5OKxuEpmMVfScf62bs=y+9PyYbejfa2OmsHYq=dStTZmjdVg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D8689E9@ESESSMB209.ericsson.se> <55665BFA.4020600@nteczone.com> <CAD5OKxsukfKG=bW-5QWu35AQQX_Eve8YM0cQ=xc=B=obnzKQdQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D86C915@ESESSMB209.ericsson.se> <547EE95EB794FD4DB8062F7A4C86D0BC4A36371A@FR712WXCHMBA13.zeu.alcatel-lucent.com> <CAD5OKxsu=uYqpFQ2Rko9gViCxRdiOudF6wbd618jy6CEFnjV_w@mail.gmail.com>
Date: Thu, 28 May 2015 19:05:36 -0400
Message-ID: <CAD5OKxu2TzURek3TqdjCq=EU4C4NoYKidFJM6wgqptUpz52GJQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "GUBALLA, JENS (JENS)" <jens.guballa@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=001a1146f2c2c0c36405172c65a2
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/JLW5as0bnE5gP1XmlLSSKXtzd5g>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 28 May 2015 23:05:43 -0000

P.S. I forgot to include, as a reason to always mandate "use_srtp"
extension, that ability to add extensions on the fly can be removed in TLS
1.3.

_____________
Roman Shpount

On Thu, May 28, 2015 at 7:01 PM, Roman Shpount <roman@telurix.com> wrote:

> Christer,
>
> Based on the currents TLS specifications you do *NOT* need to mandate
> inclusion of “use_srtp” until SRTP/SRTCP is actually used. If this
> extension is not specified you can renegotiate the session with the
> extension enabled. We should still recommend it, in order to avoid
>  a renegotiation for that purpose when SRTP/SRTCP is added. Also, all
> current implementation will not inter-operate unless “use_srtp” extension
> was included from the start, since they do not support renegotiation.
>
> I am not the member of TLS working group and TLS 1.3 is still fairly early
> to completely specify how it operates. In particular, it does not include
> any mechanism for key material update. I am not 100% sure what is going to
> be supported there and if extensions can be added and removed for an
> existing DTLS session.
>
> Given that:
> 1. existing implementations will not inter-operate with anything that does
> renegotiation (and, I have a strong suspicion anything that does not enable
> "use_srtp" extension)
> 2. renegotiation required to add "use_srtp" extension would add an extra
> round trip
> 3. overhead of always having "use_srtp" extensions is minimal
>
> I would suggest "use_srtp" extension must always be enabled for DTLS
> session used in bundle.
>
> _____________
> Roman Shpount
>
> On Thu, May 28, 2015 at 7:31 AM, GUBALLA, JENS (JENS) <
> jens.guballa@alcatel-lucent.com> wrote:
>
>> Hi Christer,
>>
>> > Hi Roman,
>> >
>> >
>> >
>> > So, if I understand you correctly, we do *NOT* need to mandate
>> inclusion of
>> > “use_srtp” until SRTP/SRTCP is actually used. However, we could still
>> > RECOMMEND it, in order to avoid a re-handshake for that purpose when
>> > SRTP/SRTCP is added.
>> [JG] You should take into account that renegotiation will be removed from
>> TLS1.3, refer to https://tools.ietf.org/html/draft-ietf-tls-tls13-05.
>>
>> BTW, I prefer the term "renegotiation" over "re-handshake" or
>> "re-keying", refer to
>> https://tools.ietf.org/html/draft-guballa-tls-terminology-01.
>>
>> Best regards,
>> Jens
>>
>> >
>> >
>> >
>> > Regards,
>> >
>> >
>> >
>> > Christer
>> >
>> >
>> >
>> > From: Roman Shpount [mailto:roman@telurix.com]
>> > Sent: 28 May 2015 05:20
>> > To: Christian Groves
>> > Cc: Christer Holmberg; Makaraju, Maridi Raju (Raju); mmusic@ietf.org;
>> > pkyzivat@alum.mit.edu
>> > Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
>> >
>> >
>> >
>> > If  "use_srtp" extension is specified, there is going to be SRTP/SRTCP
>> keying
>> > material present and associated with each DTLS cipher state. If DTLS re-
>> > handshake occurs within the same session, the new RTP/RTCP keying
>> material
>> > will be negotiated. Since no SRTP/SRTCP packets would be exchanged
>> before
>> > SRTP/SRTCP stream was added to the bundle, these packets would not
>> contribute
>> > to cipher state expiration. Cipher state can still expire due to the
>> number of
>> > data packets transmitted or time, which can still cause new SRTP/SRTCP
>> keying
>> > material to be negotiated.
>> >
>> > Technically speaking either DTLS client or server can initiate a
>> re-handshake
>> > at any time. It is an implementation detail on what would cause a re-
>> > handshake, and it can be done based on the number of packets sent or
>> received,
>> > or based on time. If re-handshake is done based on the number of
>> packets, both
>> > SRTP/SRTCP and data packets should have separate counters and cause a
>> re-
>> > handshake once a certain value is passed.
>> >
>> > As far as I know, DTLS re-handshake is not currently supported by either
>> > Chrome or Firefox, which means keying material for both data and
>> SRTP/SRTCP
>> > will stay the same for the duration of the session.
>> >
>> > _____________
>> > Roman Shpount
>> >
>> >
>> >
>> > On Wed, May 27, 2015 at 8:06 PM, Christian Groves
>> > <Christian.Groves@nteczone.com> wrote:
>> >
>> >       To be clear this means that the SRTP and SRTCP ( (because of the
>> > possibility of RTP/RTCP muxing) key negotiation occurs even before
>> RTP/STRP
>> > media is added to the BUNDLE, and the keying material for both are
>> maintained
>> > for the life of the BUNDLE? If the keys are unused they wouldn't expire
>> > because max lifetime is based on the number of protected packets.
>> >
>> >       Christian
>> >
>>
>>
>