Re: [rtcweb] JSEP: Why always offer actpass?

Roman Shpount <roman@telurix.com> Fri, 28 November 2014 23:23 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898D1A1B87 for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 15:23:02 -0800 (PST)
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 4pp7nktMLz0a for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 15:23:00 -0800 (PST)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857C71A1B86 for <rtcweb@ietf.org>; Fri, 28 Nov 2014 15:22:59 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id l18so9887431wgh.12 for <rtcweb@ietf.org>; Fri, 28 Nov 2014 15:22:58 -0800 (PST)
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=wfitLjPDLWtPS6m0UopX/LCE0ueBX4NZdVq91QpKzjY=; b=P8zOJwu+OfeHKqI1APBzvLeushQRPhrW6HF/yB7+QQ2xBF00ohrIQMaFDQWigyuYMO RxrRK/ISL97GkM6zEswM1yZsgiltvs2lCEQkrZnk8CwuLVlkQQrg1qs/X5UVnft5WJgn gWXT/4S1txFcwRI6QlgSJk326iCXGz02/MKvCRYXRXa7WHaxNdptof0LI8QAzQj64aVR 8n2wOb/suCBYO4SpXQmSqOWCu0tXKZevJO64k3yDbiC9toWM2YoZZBV1o53D0pClbJl3 ZD6LfaRu7+Eg7y8tu/h8fQeEg5B5anIQwxdIus1xs/GXcJLPBoBcV4zw6Ikzzq/5Bx7i 5InA==
X-Gm-Message-State: ALoCoQmvbNBoyWhlkOwbM35myFTBR7ukQrehGXiUwnk7YRU0PrTu3Bg0U4LMR9d4ozLr2jDrtuVs
X-Received: by 10.180.198.52 with SMTP id iz20mr37873040wic.60.1417216978160; Fri, 28 Nov 2014 15:22:58 -0800 (PST)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com. [74.125.82.48]) by mx.google.com with ESMTPSA id k5sm9544859wjn.1.2014.11.28.15.22.57 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Nov 2014 15:22:57 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id y19so9827586wgg.7 for <rtcweb@ietf.org>; Fri, 28 Nov 2014 15:22:56 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.110.161 with SMTP id ib1mr75511571wjb.78.1417216976817; Fri, 28 Nov 2014 15:22:56 -0800 (PST)
Received: by 10.216.186.74 with HTTP; Fri, 28 Nov 2014 15:22:56 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se>
References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <CAOJ7v-1ztXies0-W3B2=zWaydeLTuR8tU7v15nqyTw+MwGE+rw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63C45B@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63C90D@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <CAD5OKxskhmnHO6rLB4t7vM6Y=fVf0PwYPXsfONJjM=wzx8vHoA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se>
Date: Fri, 28 Nov 2014 18:22:56 -0500
Message-ID: <CAD5OKxt+3Tn1SiHu7u_t7AixBVS1ev0Z=vdZg0mMwmm-Tg74yA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=089e0102fc527918ec0508f38af5
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9faEKXh-FRgQQMY1r7bKgH5i9rc
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 23:23:02 -0000

On Fri, Nov 28, 2014 at 10:00 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> RFC 7345 (UDPTL-DTLS) says the following:
>
>         "Once an offer/answer exchange has been completed, either endpoint
> MAY
>         send a new offer in order to modify the session.  The endpoints can
>         reuse the existing DTLS association if the key fingerprint values
> and
>         transport parameters indicated by each endpoint are unchanged.
>         Otherwise, following the rules for the initial offer/answer
> exchange,
>         the endpoints can negotiate and create a new DTLS association and,
>         once created, delete the previous DTLS association, following the
>         same rules for the initial offer/answer exchange.  Each endpoint
>         needs to be prepared to receive data on both the new and old DTLS
>         associations as long as both are alive."
>
> So, I guess that can be read in a way that the setup attribute as such
> does not impact previously negotiated TLS roles - unless the key
> fingerprint values and/or transport parameters are modified.
>
> The SCTP-SDP draft currently says that a subsequent offer must not change
> the previously negotiated roles. But, I guess we could say something
> similar as in RFC 7345.
>

I have struggled with this language quite a bit from the implementation
perspective. I think we need to explicitly state that endpoints MUST reuse
the existing association if the key fingerprint values and transport
parameters indicated by each endpoint are unchanged. The way this language
reads to me is that endpoints can reuse the existing association if they
want to, but they can create a new one if they don't. Also, when this new
association is created, it is unclear if old setup roles MUST be preserved
or if they MUST be selected based on the current offer/answer exchange. It
seems the current specification language is not strong or clear enough on
this topic.

Another implementation issue, unless I am greatly mistaken, is that the web
browsers will not currently handle creating a new DTLS association unless
they expect it to be created. I believe this to be a very critical issue
with DTLS implementations which will not only affect DTLS association
setup, but will also break re-key. I think, we should state that webrtc
end-point should expect new DTLS association with exiting setup roles and
key fingerprint to be created at any time.
_____________
Roman Shpount