Re: [rtcweb] Unsolicited DTLS Handshake

[Roman Shpount <[e-mail]>]

On Tue, Dec 2, 2014 at 2:28 AM, Martin Thomson <[e-mail]>
wrote:

> 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