Re: [rtcweb] Unsolicited DTLS Handshake

[Christer Holmberg <[e-mail]>]

Hi,

>>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?

Well, we have mechanisms to indicate support of something. In SDP we can define an attribute, in SIP we can define a media feature tag/option tag. I assume there are ways on the DTLS level to indicate support also?

> 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.

If no endpoint supports renegotiation, I guess they won't decide not to like the connection (or, if they do, perhaps they will terminate the whole call).

> 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?

Again, I don't think this belong to JSEP. It is a generic SDP Offer/Answer issue.

Regards

Christer