Re: [rtcweb] Unsolicited DTLS Handshake

[Christer Holmberg <[e-mail]>]

Hi,

There are a number of issues we need to solve, so I'll try to separate them.

First, we need to agree on whether support of rekeying and renegotiation is mandatory, optional or not supported in general.

Second, we need to agree on how/if an updated offer affects an existing DTLS connection.

- If the transport parameters have changed, a new DTLS connection is obviously needed. But, then, how are the roles determined? Using the SDP setup attribute, as in the initial offer? OR, do we use the roles determined in the initial offer?

- If the transport parameters have NOT changed, would an updated offer affect an existing DTLS connection? Could the roles be changed (based on the SDP setup attribute)?

Regards,

Christer






-----Original Message-----
From: Stefan Håkansson LK 
Sent: 3. joulukuuta 2014 13:02
To: Roman Shpount; Christer Holmberg
Cc: [e-mail]
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

On 02/12/14 14:46, Roman Shpount wrote:
> On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg 
> <[e-mail] 
> <mailto:[e-mail]>>
> wrote:
>
>     > 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?
>
>
> I do not think this was ever consider an optional feature and because 
> of this there is no option to negotiate it.
>
>     > 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.
>
> Supposedly, JSEP will already define that DTLS setup role cannot be 
> changed. Why is fingerprint any different?
>
> I think DTLS and DTLS-SRTP end-points must supports rekey and 
> renegotiation. I do not think DTLS or DTLS-SRTP is broken or unclear 
> (of cause, this can always be improved). It looks like the mandatory 
> DTLS capability is missing from the current browser implementations. 
> So, either the rtcweb browsers should implement  this or specification 
> should be created to explain how browsers will work without it.

I agree, we really need to decide on this (and other stuff) to enable independent implementations to interoperate.

Is there any reason for not implementing according to DTLS/DTLS-SRTP specs? If not, I think that is what we should mandate.

> If the
> second path is chosen, then this discussion should probably move to 
> other groups, such as MMUSIC. The less attractive option is to argue 
> that this is a rtcweb specific DTLS profile and keep it 
> non-inter-operable with regular DTLS/DTLS-SRTP.
> _____________
> Roman Shpount
>