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 >> > >> >> >
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christer Holmberg
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Paul Kyzivat
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christian Groves
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christer Holmberg
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Makaraju, Maridi Raju (Raju)
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Roman Shpount
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christer Holmberg
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christian Groves
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Roman Shpount
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christer Holmberg
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… GUBALLA, JENS (JENS)
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Roman Shpount
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Roman Shpount
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Martin Thomson
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christer Holmberg
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Roman Shpount
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Christer Holmberg
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Paul Kyzivat
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… GUBALLA, JENS (JENS)
- Re: [MMUSIC] Bundling data channel and RTP? - Tex… Magnus Westerlund