Re: [MMUSIC] 10 BUNDLE questions: Questions on the SDP restrictions

Martin Thomson <martin.thomson@gmail.com> Sat, 27 April 2013 21:56 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 26FA621F983A for <mmusic@ietfa.amsl.com>; Sat, 27 Apr 2013 14:56:52 -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=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrFwm8Q3ZPGd for <mmusic@ietfa.amsl.com>; Sat, 27 Apr 2013 14:56:51 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18421F9839 for <mmusic@ietf.org>; Sat, 27 Apr 2013 14:56:51 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id h11so1672395wiv.14 for <mmusic@ietf.org>; Sat, 27 Apr 2013 14:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6cHeI0hKt7yPAh6nZ0vBGBJi8DSI/upFNgzC3imoDyw=; b=nNgq1Er9Mz/w7SLH7PeNMLxuNRWzf69Z3vF3/zSDLeME+BcbDc5fFA2WZJfoxvgV7+ FyebV1+3v+Oev57IBYqpfwsSvV72uiSxV8xowtmC5NacQwgFR/Aci/75Oq02gUvSHCCg ISv9HDwoSkrrFw2bCpM7n9gN24yNikZyyhRIXpRYQFjYE/Y3z0oWlIdwZuInoUTJpbnN En8rPW7N0j0TsvHUyC14KPqrDVNO0d6WgRvZXTq/af9LImjKK4mngv6IyCoXY+mZLFXB lRfgUAtAQBK3WH9qda2CsbJZBP+jHCGmigj+RcBcVuVA0h+U1Jzrkrc3qGLWLu9mZ2AB wEBg==
MIME-Version: 1.0
X-Received: by 10.194.236.169 with SMTP id uv9mr7822695wjc.42.1367099810604; Sat, 27 Apr 2013 14:56:50 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Sat, 27 Apr 2013 14:56:50 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C35F453@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C35F453@ESESSMB209.ericsson.se>
Date: Sat, 27 Apr 2013 14:56:50 -0700
Message-ID: <CABkgnnW9ULKcJewviFDG0WfGqQUso4J9=k6Lu9PJEaW0rpc0yw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 10 BUNDLE questions: Questions on the SDP restrictions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 27 Apr 2013 21:56:52 -0000

I finally found something in all the noise.

On 25 April 2013 07:03, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
>>5. From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session?
>
> As people have indicated, it prevents a two-time pad attack, and that is also the only reason I can think of. My suggestion is to keep the restriction in list 1 and 2. But, if someone OBJECTS to this, please indicate so.

The two-time pad thing is bogus, unless you are using shim (so that
you can reuse SSRCs).

I think that I would like to OBJECT to this.  It is possible to
perform decrypt after demux, and there are no inherent problems.

I initially wasn't that concerned with people taking this position,
because I figured that it would be better to allow for some
flexibility in the order of operations.  However, it makes
multiplexing translators harder to build.

It's not a strong objection. After all, we are all in the business of
accelerating the heat death of the universe.

>> 6. If you start with a m= line with one SDES config (e.g. 32-bit MAC), and then BUNDLE with another SDES line with a different (non overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume fail)
>
> People have indicated that this would be a failure, and I have seen no one indicate otherwise. But, if someone OBJECTS to this, please indicate so.

See above.