Re: [rtcweb] Unsolicited DTLS Handshake

Roman Shpount <> Tue, 02 December 2014 12:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 977101A1B2E for <>; Tue, 2 Dec 2014 04:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3gg1S3GBwc35 for <>; Tue, 2 Dec 2014 04:54:46 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 989AC1A1B43 for <>; Tue, 2 Dec 2014 04:54:45 -0800 (PST)
Received: by with SMTP id n3so27919237wiv.11 for <>; Tue, 02 Dec 2014 04:54:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UbQTcGhWttvmIvO2iwrHp4oUCY2owdF5aD0DP7UB6vc=; b=gIFzKG1nsVjmqdxR4sNz4TWn4nFSmXm7yO/Yp9Vd8bTEdLsqQ+IujinDAJuYXnGOWf FAbsI0ZSg30i5waOiVqkczY6CjneofKhXH2NITfd1PG+YOIGylqh57kdaqvBQL0wn5N3 BYRaQExrnVll+PT8/D2KD2XoXAf2lSFBIf3Nn1bWbqfcSpsxYPFc4fI2qPQU4CW4ASNJ XzMe8o5dq1/Sph1OABMwDMfp44K0/NSbeAPHePgA96tW+9l+LU1QJTSJWMSnbfmaHwBH 1Zw8qDEMvvWdjGXWuBN/kCN18IHF9h1iagt5Ti44VML+RciAW3XVD5F89u1tlxFNzDdU HzUg==
X-Gm-Message-State: ALoCoQlUBsXD+ibnVU9PpqmBeSBi6HJ4QCs/P4s2hZt2JxzRVhOqVB0qAahgj8hGNWkp8S9dMFAo
X-Received: by with SMTP id m8mr103977191wjy.58.1417524884377; Tue, 02 Dec 2014 04:54:44 -0800 (PST)
Received: from ( []) by with ESMTPSA id eu15sm32653631wid.18.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 04:54:43 -0800 (PST)
Received: by with SMTP id l18so16996957wgh.12 for <>; Tue, 02 Dec 2014 04:54:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id dp10mr84384682wib.38.1417524883146; Tue, 02 Dec 2014 04:54:43 -0800 (PST)
Received: by with HTTP; Tue, 2 Dec 2014 04:54:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 2 Dec 2014 07:54:43 -0500
Message-ID: <>
From: Roman Shpount <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary=f46d0444806d1ece6c05093b3ba8
Cc: "" <>
Subject: Re: [rtcweb] Unsolicited DTLS Handshake
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Dec 2014 12:54:49 -0000

On Tue, Dec 2, 2014 at 2:28 AM, Martin Thomson <>

> ekr corrected me.  Firefox explicitly disables renegotiation.  We
> don't have the machinery in place to re-export SRTP keying material
> anyway (I suspect that it requires use of MKI).

Chrome on the other hand has renegotiation enabled but does not have the
code to detect it and to re-export SRTP keys. My question is, should
disabling renegotiation be codified somewhere (like JSEP) or is this
something that is going to be implemented? If renegotiation is somehow an
optional feature, how does one know that remote party supports it?

Also, what happens when transport parameters stay the same but the
fingerprint changes? This definitely requires a new DTLS connection, but
you will still need to de-mux SRTP packets belonging to the old and new
SRTP contexts somehow. This is not that different from rekey.

> As for the text in RFC 5763, I read that as : if you have a
> connection, use it; if you don't, or the existing one is "bad" for any
> reason, make a new one.  That is not renegotiation.

What happens if one side decides it does not like its connection and the
other side decides to keep it? In such case one side will start a new
handshake but the other side will not expect it. The specification needs to
define when new connection MUST be created and when new connection MUST not
be created to work consistently. Alternatively DTLS end point should be
prepared to handle ClientHello or HelloRequest at any time, as well as,
actively solicit the handshake when in passive mode by sending periodic
HelloRequests to make sure both sides participate.

Finally, JSEP should define what can be changed on the DTLS connection. I
think it was already agreed on the list that the setup roles should be
preserved (btw is this a SHOULD or a MUST?). What about the fingerprint? Is
it legal to change it without changing transport parameters?
Roman Shpount