Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Christer Holmberg <> Fri, 03 May 2013 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AA4621F96E9 for <>; Fri, 3 May 2013 10:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TrIJg11RTHN7 for <>; Fri, 3 May 2013 10:42:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA70A21F9798 for <>; Fri, 3 May 2013 10:37:50 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-30-5183f5edf15a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 0B.A0.32006.DE5F3815; Fri, 3 May 2013 19:37:49 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 3 May 2013 19:37:49 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Date: Fri, 03 May 2013 17:37:48 +0000
Message-ID: <>
References: <> <> <> <> <> <>, <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvre7br82BBteXGFvMbG1lsfjT+ovR YuryxywWKzYcYHVg8Wh9tpfV4+/7D0weO2fdZfdYsuQnUwBLFLdNUmJJWXBmep6+XQJ3xufJ s9gKvglWvL+6gbWB8QNvFyMHh4SAicS2h5ZdjJxAppjEhXvr2boYuTiEBA4zSux8fY0RwlnM KHF24xNWkAY2AQuJ7n/aIKaIgIbEpK1qICXMArMYJaaf3MwIMkhYwE5ixvwOJhBbRMBe4mzH IjYIu0xi3qGpzCC9LAIqEqumx4KEeQV8JTatfQu16i2LxKXee2C9nAI6Elu29oLZjEDHfT+1 BsxmFhCXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSrQ/bWCEqNeRWLD7ExuErS2xbOFrZojF ghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HKjTYzAWDq45bfqDsY750QOMUpz sCiJ8yZzNQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjEsM4m71W5va3dF/djbvUifP n3mbgqUqJ6w+/Ezxo45me6951es9wbaxax2umD2bpnjdr0nC19aFz9FiZwRnT2/wY4nqq/pK nduemP3gOy9+avn7qwld8xaffNA5b++q9x+Vp7T/3blXRLUiobXUzfyth9ctO6HPr8teRPdk v1FYwhIXVWwQpcRSnJFoqMVcVJwIAFBMSA14AgAA
Cc: Alan Johnston <>, "" <>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 May 2013 17:42:58 -0000


>After rereading this and checking 4583, I realize my comment was based
>on a misunderstanding of what BFCP was doing. I thought you were saying
>that BFCP didn't use a=setup, and that the active party for the TCP/TLS
>connection was always the offerer. I see that was wrong - that it uses
>a=setup for that and says that the answer is the TLS server.

Correct. BFCP does use a=setup for the TCP connection establishment. Sorry if I was unclear.



BFCP seems to have arranged its authentication so either end is capable
of being the TLS server, and it is only necessary to have *some*
mechanism for deciding which one will be. As long as that is the case, I
don't have a particular problem with it.


On 5/3/13 2:58 AM, Christer Holmberg wrote:
> Hi Paul,
>>> RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572.
>>> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good.
>> I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction?
> Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll find an answer there :)
>> And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one?
> I would need some more time to think about that, but a few questions that came to my mind:
> 1) If the TLS connection already exists, is there a reason to reestablish it to begin with?
> 2) Would you need an o/a to reestablish the TLS connection to begin with? Once the roles have been determined (in the initial o/a), can't everything be handled on the TLS layer?
> 3) If the TLS connection already exists, is there a reason to renegotiate the TLS roles?
> 4) If a subsequent o/a is needed in order to reestablish the connection, and/or renegotiate the TLS roles, could the TLS connection first be terminated on the TLS layer, before the subsequent of/a is sent?
> Regards,
> Christer