- From: Iñaki Baz Castillo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 04 Jan 2016 09:32:02 +0000
- To: public-ortc@w3.org
ibc has just created a new issue for https://github.com/openpeer/ortc: == DTLS "auto" role and possible DTLS conflicts == According to the spec, if no remote DTLS parameters are yet given the browser assumes a DTLS role based on its ICE role. IMHO this can become a problem when in the following scenario: * Alice and Bob successfully negotiate and establish ICE (Alice becomes "ICE controlling" and Bob becomes "ICE controlled"). * For X reason, Bob is not yet provided with Alice's DTLS params, so based on its "ICE controlled" role it acts as DTLS client and sends a ClientHello request to Alice. * **CONCERN 1:** At this point Alice receives the DTLS ClientHello so, according to the spec, it becomes DTLS server. * Later, DTLS parameters are given to both endpoitnts: Alice is told that Bob is DTLS server and Bob is told that Alice is DTLS client. * Since DTLS was already started in opposite direction, both must reset their DTLS session. * **CONCERN 2:** If previous DTLS connection succeeded (all but the not yet given remote fringerprint) should both Alice and Bob send a DTLS alert when reseting their DTLS sides? And the **main concern** is that current Chrome version (I mean WebRTC 1.0 of course) fails in the above scenario in which it receives a DTLS ClientHello and later is told to become DTLS client (Chrome does not send a ClientHello after that). Please view or discuss this issue at https://github.com/openpeer/ortc/issues/318 using your GitHub account
Received on Monday, 4 January 2016 09:32:04 UTC