Subject: [rtcweb] Unsolicited DTLS Handshake

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Dec 2014 17:42:57 -0500

Should browsers support new DTLS handshake without it being triggered by
offer/answer?

I think new DTLS handshake can be triggered at any time by ClientHello or
HelloRequest DTLS message. At this point, unless I am missing something, it
looks like neither Chrome no Firefox update SRTP keys unless transport
parameters or fingerprint is changed due to offer/answer. On the other
hand, DTLS end-point can initiate a handshake at any time, for instance to
do the DTLS-SRTP rekey. Is this a missing feature or is this some new
behavior that needs to be defined?

Regards.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 2 Dec 2014 00:19:29 +0100

> Should browsers support new DTLS handshake without it being triggered by

IMHO yes as that is part of DTLS itself and DTLS does not need a SDP
O/A in order to renegotiate (assuming same fingerprint is used, of
course).

> parameters or fingerprint is changed due to offer/answer.

Are you sure of that? AFAIR last time I inspected Chrome DTLS stack
(the one based on BoringSSL/OpenSSL) it did include code for DTLS
renegotiation and SRTP re-key stuff. I may be wrong.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 15:36:08 -1000

> O/A in order to renegotiate (assuming same fingerprint is used, of

Depends on whether you are talking about renegotiation or a whole new
handshake.  The former should be OK.  I'm fairly certain that the
latter fails on Firefox.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Dec 2014 21:29:40 -0500

> handshake.  The former should be OK.  I'm fairly certain that the

I am talking about renegotiation, such as in
https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially a new
handshake.

The other reason I am asking is the following language:
https://tools.ietf.org/html/rfc5763#section-6.6: "The peers can reuse the
existing associations if they are compatible (i.e., they have the same key
fingerprints and transport parameters), or establish a new one following
the same rules are for initial exchanges, tearing down the existing
association as soon as the offer/answer exchange is completed.  Note that
if the active/passive status of the endpoints changes, a new connection
MUST be established."

Since, based on this paragraph one side can decide that it can reuse and
the other side decides to re-establish new DTLS connection, you will end up
with an unsolicited handshake on one side.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 21:28:02 -1000

> https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially a new

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

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.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 09:10:47 +0000

Hi,

Related to this, session resumption is another feature not commonly supported, afaik.

(Of course, when using BUNDLE you don't need it.)

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 2. joulukuuta 2014 9:28
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

On 1 December 2014 at 16:29, Roman Shpount <[email-masked]> wrote:
> https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially 
> a new handshake.

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

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.

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 2 Dec 2014 09:46:51 +0000

Hello Christer,

fail to see any tight coupling between bundling and (D)TLS session resumption. Both are orthogonal capabilities.
You could execute a (D)TLS session resumption procedure for an established/active (D)TLS session (under the condition of a resumable session) which is shared by a bundled media group.
Why not?

Regards,
Albrecht

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Dienstag, 2. Dezember 2014 10:11
To: Martin Thomson; Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Dec 2014 07:54:43 -0500

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

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Dec 2014 13:06:48 +0000

Hi,

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Dec 2014 08:45:54 -0500

On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg <
[email-masked]> wrote:

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 3 Dec 2014 11:01:56 +0000

On 02/12/14 14:46, Roman Shpount wrote:
> On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     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?
>
>
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Dec 2014 12:09:44 +0000

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: [email-masked]
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

On 02/12/14 14:46, Roman Shpount wrote:
> I do not think this was ever consider an optional feature and because 
> of this there is no option to negotiate it.
>
> 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 

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.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Dec 2014 09:43:08 -0500

On Wed, Dec 3, 2014 at 7:09 AM, Christer Holmberg <
[email-masked]> wrote:

> First, we need to agree on whether support of rekeying and renegotiation
> is mandatory, optional or not supported in general.
>
> - 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)?
>
>
There is actually one more point to the second issue: If the transport
parameter have NOT changed, can the fingerprint be changed? Does this cause
the new DTLS connection to be created and if it does, how do you de-mux
packets for the old and new connection (both DTLS data and SRTP)?
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Dec 2014 15:58:53 +0100

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

WebRTC uses DTLS. DTLS allows that, so it must be supported. This is,
any WebRTC device/endpoint/thing should be able to perform a DTLS
renegotiation (regardless who sent the first ClientHello), and that
could involve SRTP re-keyring. This is 100% transparent so no need at
all for SDP O/A stuff.

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

Each SDP O/A party is supposed to mean an independent round-trip, so
the same mechanism used for the original SDP O/A should be used. Said
that:

What would happen in a SDP O/A renegotiation if "transport parameters"
do not change but the a=setup attribute does change? Well, the world
end. We are trying to signal everything in SDP but at the same time we
use protocols that are self-sufficient, so yes, we get unnecessary
conflicts.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Dec 2014 16:01:22 +0100

2014-12-03 15:43 GMT+01:00 Roman Shpount <[email-masked]>:
> If the transport parameter have NOT changed, can the fingerprint be changed?

Correct me if I'm wrong, but during a DTLS/TLS session certificates
are sent just once, at the beginning. Changing the a=fingerprint
attribute in a new SDP O/A round-trip without forcing a new DTLS
session should just be considered an error.

Again: we are trying to signal too much in the SDP.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Dec 2014 10:30:27 -0500

> Again: we are trying to signal too much in the SDP.
This is not exactly the SDP issue. This is an issue of being able to stop
DTLS session and start a new one on the same transport connection while
being able to de-mux packets for both sessions. It is a valid operation for
DTLS-SRTP, but it does complicate the implementation. I am sure there are
some media proxy scenarios where fingerprint and setup role changes would
be required, but this is definitely not required for normal webrtc use
cases. I do not think it would be a great loss if changing fingerprint and
setup role would not be allowed, but that would need to be defined
somewhere. For instance JSEP can specify the offers or answers which change
setup role or fingerprint should be treated as malformed or that these
updates must be ignored.

Re-key, on the other hand, must be supported, since support for it cannot
be negotiated and it does provide valuable functionality.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 04:41:27 +0000

Hi Inaki,

My intention is not to be able to do everything with O/A.

I am trying to figure out what can be done with O/A, and how/if O/A affects existing DTLS connections.

If something can NOT be done, I think it would be good to document somewhere.

I am willing to start drafting a "TLS with SDP O/A" draft, if people think such would be useful.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Iñaki Baz Castillo<mailto:[email-masked]>
Sent: ‎03/‎12/‎2014 17:01
To: Roman Shpount<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Dec 2014 21:47:01 -0800

That sounds like a 5763-bis.

On Wed, Dec 3, 2014 at 8:41 PM, Christer Holmberg <
[email-masked]> wrote:

>  ------------------------------
> From: Iñaki Baz Castillo <[email-masked]>
> To: Roman Shpount <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>; [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 06:28:18 +0000

5763 is specific to SRTP, but there are also other protocols using DTLS.

The Offer/Answer considerations should be the same for all of them – otherwise we will have problems e.g. in BUNDLE, if different protocols within a BUNDLE group use different rules for negotiating TLS roles etc…

Regards,

Christer

From: Justin Uberti [mailto:[email-masked]]
Sent: 4. joulukuuta 2014 7:47
To: Christer Holmberg
Cc: Iñaki Baz Castillo; Roman Shpount; [email-masked]
Subject: Re: [rtcweb] Unsolicited DTLS Handshake

On Wed, Dec 3, 2014 at 8:41 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Inaki,

Regards,

Christer

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb