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

Roman Shpount <roman@telurix.com> Thu, 28 May 2015 23:01 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 3F9C81ACD8E for <mmusic@ietfa.amsl.com>; Thu, 28 May 2015 16:01:36 -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 srvLX_naVMdw for <mmusic@ietfa.amsl.com>; Thu, 28 May 2015 16:01:33 -0700 (PDT)
Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) (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 C1F491ACD53 for <mmusic@ietf.org>; Thu, 28 May 2015 16:01:32 -0700 (PDT)
Received: by qkx62 with SMTP id 62so35333416qkx.3 for <mmusic@ietf.org>; Thu, 28 May 2015 16:01:32 -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=PONX2CKUxTBAq89X8owY1IX1wlKsQFivkSI5z1iBifM=; b=Sfw6UHNMcdXNDCaaEjjOUMIE3aJzf8gW5BqNc5GC0KaI87M/exLN8jiA3hSorLFQj7 1/l5R0QVBDG9iTOafQtHXM21EmYA3sgylIAUGz7KUtSLI7KbNu5N0pbE1VXSfoEILGGU Ffm6zgwFtGiiIRnqIX9A0tP3HP+YheaGtXWbCaSqMZk/Bj20Cq2rDgIDMoDCwu+O5e6m BdwwDTZHn+SYZM8WAErhFbsdINkvlu6142Cw0wqlVaH//EYjf+64zTp7hotSM+PSbMLQ 0I/VtMdMp9jB4lp32zWJItYf+b/3CVxHpP4AytW0+h1FroH6gzVZ48y2Afx6M4UyCdP3 tPww==
X-Gm-Message-State: ALoCoQms1+KhlbBQdhCTYvJa+v2/FupR6VEDH7rc4dt95dRFS3fxyV1Yc4OLnHRa9f4YWgVevprS
X-Received: by 10.229.184.2 with SMTP id ci2mr6656825qcb.2.1432854091949; Thu, 28 May 2015 16:01:31 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com. [209.85.216.177]) by mx.google.com with ESMTPSA id 17sm1751272qhd.45.2015.05.28.16.01.30 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 16:01:30 -0700 (PDT)
Received: by qcbhb1 with SMTP id hb1so20964818qcb.1 for <mmusic@ietf.org>; Thu, 28 May 2015 16:01:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.229.226.4 with SMTP id iu4mr6555639qcb.7.1432854089844; Thu, 28 May 2015 16:01:29 -0700 (PDT)
Received: by 10.96.130.162 with HTTP; Thu, 28 May 2015 16:01:29 -0700 (PDT)
In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A36371A@FR712WXCHMBA13.zeu.alcatel-lucent.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>
Date: Thu, 28 May 2015 19:01:29 -0400
Message-ID: <CAD5OKxsu=uYqpFQ2Rko9gViCxRdiOudF6wbd618jy6CEFnjV_w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "GUBALLA, JENS (JENS)" <jens.guballa@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=001a11348e2e0a4dda05172c57f2
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vtOiTC48s7Jgb8ZiZA0jUJHVqgI>
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:01:36 -0000

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
> >
>
>