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

Justin Uberti <juberti@google.com> Fri, 03 May 2013 18:15 UTC

Return-Path: <juberti@google.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 7823221F974A for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 11:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.377
X-Spam-Level:
X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 u+KjoioJypws for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 11:15:39 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0539E21F974E for <mmusic@ietf.org>; Fri, 3 May 2013 11:15:35 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id 10so2152668ied.33 for <mmusic@ietf.org>; Fri, 03 May 2013 11:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=yV857/XAkjdegv+P9+ema4j3qNvjJEpVrXWZOOtA5r8=; b=IqyK7smu4Umio05yi18ovyqXMdZ9dNXe3BHgAJ+PcM7EzzSMarml4eCLBJ3F6hPC7M Ku/igi1gktfqJ1nYyfu9m5Vb29qXXdp505AdD4joEVWHj5SLwz8KzMfB4xJFUnQtXWIP Q/qFzzP/WnLZHYxvUCziOIcn8pmyMooqSfmxJvafTBQj4hE+MJ0wWg/Ctc7LFF4V3Jur bptRNnv69/ok200UVdxc/vEUM4bJPW2A3BK+PLEt5IHRM14qSssnS3qEzjQgr6qgq5Ro P3rCAThq+L0dgQ3wZqC4/LYHvfihlvt37cmCFs9i90OBUfTRhzgyxZGx17wXYKNXQHfm RbDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=yV857/XAkjdegv+P9+ema4j3qNvjJEpVrXWZOOtA5r8=; b=IsgvUGGY3m9rzlSw82N1hpwi1BvvwTSWmO5U/begTs2MV9KSLn/1BniPwY84zS51JM /IIjIULofM4tWB5aKfmdX9HZu0tasAzcdkX5AoLF+H2nqxC63uChOD6L/m5udFN5jMpF uVOVjz37l9LPbuM5zcGXVkcgl9nuzHEfJc5e03I7rMp46Y3t/xLqkSl2JxTIPoK/mL0v qydUiW8hCZ7v4woPdoPDQHGZhWkA/9UjGihwy/OU0Hsbih3fmLaEHeLk9AU3wSx2p0QK CWFlo5QkstXBtr7MvXf4N/gre54yCeyshK/9VD21RdcKqPdDTROFrv8MJ7kgs3HZAIMQ D3TQ==
X-Received: by 10.50.32.4 with SMTP id e4mr16342718igi.95.1367604931735; Fri, 03 May 2013 11:15:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.193.201 with HTTP; Fri, 3 May 2013 11:15:11 -0700 (PDT)
In-Reply-To: <CABkgnnX_fy77UthxAJxen=Eoam0CABdAMvCiTZSt0NoG=s3M7Q@mail.gmail.com>
References: <E888F149-12FE-4F23-A270-F861123BAC7B@tokbox.com> <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <CAOJ7v-2XUzVr3kL=emR_7w49th3mowa_WQG4wVVmD7__uA8APw@mail.gmail.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> <CAKhHsXGEiNLod6fXbOSP3HvVYtFi4iBQEUBe2x-5YQdwz8LAOQ@mail.gmail.com> <F72A5B11-D5D4-41D1-8118-C5BCBBAAE567@tokbox.com> <CAOJ7v-1rt2RA17oC0kCxC2wD310ghp2pwLF1jit6ikLfCSCiQA@mail.gmail.com> <CABkgnnX_fy77UthxAJxen=Eoam0CABdAMvCiTZSt0NoG=s3M7Q@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 3 May 2013 11:15:11 -0700
Message-ID: <CAOJ7v-0bCeqXj7tMsZjFFSr6VvozdXtdxST2q5PS_wgtaZ+W8A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=e89a8f3ba56d26440104dbd456b0
X-Gm-Message-State: ALoCoQlEvzuCSvr0uVIr2ahwGdKplWGHNyoStSmGKgd13+JhWhvbmCVMBhK3fdBQR8yy5fHOwtqD9clBrmnvX3k5VOjAPyObDGrdTXVSCA+ZSUHKVzQsdx+5Sqg7xq8haWY/yIUF7m3muCtNjgoGCUfD4x0vVGWpa7tRdyDwpXuXN622BQiUZkoX+PB27W6biUg4t1tkr2RE
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, Alan Johnston <alan.b.johnston@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
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: Fri, 03 May 2013 18:15:40 -0000

On Fri, May 3, 2013 at 10:29 AM, Martin Thomson <martin.thomson@gmail.com>wrote;wrote:

> On 2 May 2013 22:53, Justin Uberti <juberti@google.com> wrote:
> > This is where the OP's question came from - the differing policy between
> > Chrome and Firefox. I (regarding Chrome) had figured that if ICE had
> made a
> > determination regarding which side was in charge, the other layers in the
> > stack should do the same, but it sounds like there are already
> established
> > rules on how to do this.
> >
> > From this thread, it sounds like the recommendation is to use
> > a=setup:actpass in the offer, and then the answerer can use
> a=setup:active
> > to choose the client role. In 3pcc cases, the B2BUA can select a=setup
> > appropriately to avoid any issue.
> >
> > Is that an accurate summary, and is there consensus on this?
>
> The answer should probably be a=setup:passive, so that you don't have
> any disconnect on what candidate pair is nominated.  And you don't pay
> an extra half-RTT.  But otherwise, yes.
>

http://tools.ietf.org/html/rfc5763 recommends a=setup:active for the
answerer, and Eric convinced me that any perf benefit from doing anything
different was nominal.

If the answerer's initial ICE checks reach the offerer, the client hello
can be sent by the answerer in 1.5 RTT, or the offerer in 2.0 RTT:
0.0: A: offer
0.5 B: answer
0.5 B: binding request
1.0 A: binding response
1.0 A: triggered binding request (USE-CANDIDATE)
1.5 B: DTLS client hello

If not, the client hello is sent by the answerer in 2.5 RTT, or the offerer
in 2.0 RTT:
0.0: A: offer
0.5 B: answer
0.5 B: binding request (dropped)
1.0 A: binding request (USE-CANDIDATE)
1.5 B: binding response
1.5 B: triggered binding request
2.0 A: binding response
2.5 B: DTLS client hello

So overall it's a bit of a wash, and therefore simpler to stick with 5763's
recommendation.