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

Christer Holmberg <> Fri, 03 May 2013 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DABC21F8619 for <>; Thu, 2 May 2013 23:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SrxpKfirrY0y for <>; Thu, 2 May 2013 23:59:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B8CFC21F8675 for <>; Thu, 2 May 2013 23:59:00 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-8a-518360339320
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 98.B3.32006.33063815; Fri, 3 May 2013 08:58:59 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 3 May 2013 08:58:59 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Date: Fri, 03 May 2013 06:58:59 +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+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvra5xQnOgwd075hYzW1tZLP60/mK0 mLr8MYvFig0HWB1YPFqf7WX1+Pv+A5PHzll32T2WLPnJFMASxW2TlFhSFpyZnqdvl8Cdce/M fJaCDu6KZ//EGxgvcnQxcnJICJhIbJq8lRXCFpO4cG89WxcjF4eQwGFGiaN90xghnMWMEmdW TAPKcHCwCVhIdP/TBjFFBDQkJm1VAylhFpjFKDH95GZGkEHCAnYSM+Z3MIHYIgL2Emc7FrFB 2FkSK+b0gNksAioSm251sIPYvAK+EpMvdUMt7mSR+N47E+wiTgEdiU9LVoANYgS67vupNWA2 s4C4xK0n85kgrhaQWLLnPDOELSrx8vE/qG8UJa5OXw5VryOxYPcnNghbW2LZwtfMEIsFJU7O fMIygVFsFpKxs5C0zELSMgtJywJGllWM7LmJmTnp5UabGIHRdHDLb9UdjHfOiRxilOZgURLn TeZqDBQSSE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoYWeaJt/5UuBYsnPlrGouT7Oav36ZY 3MzeajA5QN4yIzhi5SpzJ/XoY+wyMa+UpjztP32i9GiX7CmfjCTFeKnvgk9WpViLrWCoemLc tOG87+q7RwJmM5+Zv0BfiyXn1QKv/ZG81rO2flh4ND6U7eNUtlesIdOFD6nteffv2FaHGw+l fk73aOfmUGIpzkg01GIuKk4EAIRymeJ5AgAA
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 06:59:08 -0000

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?