Subject: Re: [MMUSIC] DTLS-O/A: DTLS fingerprint and setup role MUST NOT change unless underlying transport also changes

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Feb 2015 09:09:58 -0500

First of all, Simon Perreault have corrected the double negative to more
grammatically correct:  "DTLS fingerprint and setup role MUST NOT change
unless underlying transport did change as well."

Second, we would also need to define what happens if an offer or an answer
with the changed DTLS fingerprint or setup role and the same transport
parameters is received. I assume generating and error and tearing down the
session are the best option.

On Wed, Feb 25, 2015 at 8:00 AM, "Makaraju, Maridi Raju (Raju)" <
[email-masked]> wrote:

Transport parameters could change in SDP answer (e.g. connecting to a
> conference bridge). To allow this any new offer should always send
> "actpass". The answerer should return the previously negotiated role.
>

I agree that in general case the setup role should be actpass when sending
an offer even in the existing session, since when an offer is sent it is
unknown if the answer with the new transport parameters is going to be
received. This, of cause, will not apply to anything that is using ICE,
such as any WebRTC implementation, since in case of ICE, you cannot change
transport parameters in the answer. Because of this, in case of ICE,
existing role can be sent with no issues.

Scenario1: If a DTLS association is aborted due to an error, is a new SDP
> offer/answer required to restart the association? I guess not. But I do not
> find any clarification on this, so implementations may depend on new SDP
> O/A. If a new SDP offer/answer is sent then it may negotiate the same
> fingerprint and transport params but in this case a new association must be
> established (even probably without role changes).
>
> To allow this change the text need to include allowing of re-establishment
> of a closed DTLS association (new text is marked between '**'):
>
> "DTLS fingerprint and setup role MUST NOT change unless underlying
> transport did change as well **or a new DTLS association needs to be
> established after losing previous one**."
>
>
Handling DTLS association failure is somewhat unrelated but also undefined
behavior issue. I think I would prefer separate text which describes what
happens if DTLS association fails. Resuming the session or reporting an
error to the higher level are both valid options. I think we also need to
make sure that both end points would always be in the same state, i.e. that
it is not possible that one side will consider DTLS association lost while
the other side will still consider it running. I think resuming the DTLS
session by the current active end point should be a safe recommended option
which would be handled similar to re-key.

> Scenario2: The following scenario which may be reestablishing a new DTLS
> association currently, but works, becomes an invalid SDP O/A and need to
> change its behavior:
>
> 1.       A (passive) to B (active) are in an active DTLS session directly.
>
> 2.       B has to send a new offer now for some service. B has to send
> 'actpass' as SDP answer may result in A talking to other than B (like a
> conf resource).
>
> 3.       If it turns out A gets the SDP offer and in SDP answer it may
> include 'active' (due to, for example being the answerer now), which now
> reverses the roles.
>
> So, after the above change, the expectation here is for A to return
> previously negotiated 'passive' role to avoid SDP O/A violation.
>

There is no harm in adding a text that in such scenario currently
negotiated role should be returned. This will mostly serve as clarification
and would help to avoid buggy implementations.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Feb 2015 14:19:07 +0000

Hi,

>First of all, Simon Perreault have corrected the double negative to more grammatically correct:  "DTLS fingerprint and setup role MUST NOT change unless underlying transport did change as well."

Correct. My mistake. I was going to copy Simon’s text.

>Second, we would also need to define what happens if an offer or an answer with the changed DTLS fingerprint or setup role and the same transport parameters is received. I assume generating and error and tearing down the session are the best option.

Another option would be to say “SHOULD NOT, unless there is a mechanism to handle packets associated with both the old and new DTLS associations”. That would allow usage of any future mechanism, without having to change the text.

Regards,

Christer

On Wed, Feb 25, 2015 at 8:00 AM, "Makaraju, Maridi Raju (Raju)" <[email-masked]<mailto:[email-masked]>> wrote:

Transport parameters could change in SDP answer (e.g. connecting to a conference bridge). To allow this any new offer should always send "actpass". The answerer should return the previously negotiated role.

I agree that in general case the setup role should be actpass when sending an offer even in the existing session, since when an offer is sent it is unknown if the answer with the new transport parameters is going to be received. This, of cause, will not apply to anything that is using ICE, such as any WebRTC implementation, since in case of ICE, you cannot change transport parameters in the answer. Because of this, in case of ICE, existing role can be sent with no issues.

Scenario1: If a DTLS association is aborted due to an error, is a new SDP offer/answer required to restart the association? I guess not. But I do not find any clarification on this, so implementations may depend on new SDP O/A. If a new SDP offer/answer is sent then it may negotiate the same fingerprint and transport params but in this case a new association must be established (even probably without role changes).

To allow this change the text need to include allowing of re-establishment of a closed DTLS association (new text is marked between '**'):

"DTLS fingerprint and setup role MUST NOT change unless underlying transport did change as well **or a new DTLS association needs to be established after losing previous one**."

Handling DTLS association failure is somewhat unrelated but also undefined behavior issue. I think I would prefer separate text which describes what happens if DTLS association fails. Resuming the session or reporting an error to the higher level are both valid options. I think we also need to make sure that both end points would always be in the same state, i.e. that it is not possible that one side will consider DTLS association lost while the other side will still consider it running. I think resuming the DTLS session by the current active end point should be a safe recommended option which would be handled similar to re-key.

Scenario2: The following scenario which may be reestablishing a new DTLS association currently, but works, becomes an invalid SDP O/A and need to change its behavior:

2.       B has to send a new offer now for some service. B has to send 'actpass' as SDP answer may result in A talking to other than B (like a conf resource).

3.       If it turns out A gets the SDP offer and in SDP answer it may include 'active' (due to, for example being the answerer now), which now reverses the roles.

So, after the above change, the expectation here is for A to return previously negotiated 'passive' role to avoid SDP O/A violation.

There is no harm in adding a text that in such scenario currently negotiated role should be returned. This will mostly serve as clarification and would help to avoid buggy implementations.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Feb 2015 10:51:22 -0500

On Wed, Feb 25, 2015 at 9:19 AM, Christer Holmberg <
[email-masked]> wrote:

>  >Second, we would also need to define what happens if an offer or an
> answer with the changed DTLS fingerprint or setup role and the same
> transport parameters is received. I assume generating and error and
> tearing down the session are the best option.
>
>
>
> Another option would be to say “SHOULD NOT, unless there is a mechanism to
> handle packets associated with both the old and new DTLS associations”.
> That would allow usage of any future mechanism, without having to change
> the text.
>
>
>
I would prefer not to say "SHOULD NOT" unless the mechanism is defined. If
the mechanism for demux is going to be created in the future, I think it
would need to update this draft anyway.
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 25 Feb 2015 18:30:29 +0000

I agree that in general case the setup role should be actpass when sending an offer even in the existing session, since when an offer is sent it is unknown if the answer with the new transport parameters is going to be received. This, of cause, will not apply to anything that is using ICE, such as any WebRTC implementation, since in case of ICE, you cannot change transport parameters in the answer. Because of this, in case of ICE, existing role can be sent with no issues.
<Raju>
I believe you are obviously NOT referring to ICE-restart case.
I agree that if ICE is not restarted then ICE clients can send previously negotiated role. But is there any issue in offerer sending ‘actpass’ even for ICE non-restart case? Per the new rule, the answerer has to answer with previous role anyway (unless ICE-restart changes transport). This keeps it simple and consistent for ICE (restart, non-restart) and non-ICE clients.
</Raju>

<Raju>
I agree to the point that both endpoints have to be in the same state. IMO, allowing a new SDP O/A in this case with same fingerprint and transport 5-tuple may serve this purpose in addition to re-establishing a failed DTLS association. I am ok if this is added as separate text and also making it optional to send new SDP O/A.
</Raju>

BR
Raju

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Feb 2015 15:18:05 -0500

On Wed, Feb 25, 2015 at 1:30 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>
> *I believe you are obviously NOT referring to ICE-restart case.*
>
> *I agree that if ICE is not restarted then ICE clients can send previously
> negotiated role. But is there any issue in offerer sending ‘actpass’ even
> for ICE non-restart case? Per the new rule, the answerer has to answer with
> previous role anyway (unless ICE-restart changes transport). This keeps it
> simple and consistent for ICE (restart, non-restart) and non-ICE clients.*
>
>
I was referring to ICE offer with the same transport parameters, which
includes the same ufrag and because of this not being an ICE re-start.
ICE-restart would be transport parameters change and will require a new
DTLS association to be setup. This being said, I have no issue with actpass
setup role being always sent in offer.

*I agree to the point that both endpoints have to be in the same state.
> IMO, allowing a new SDP O/A in this case with same fingerprint and
> transport 5-tuple may serve this purpose in addition to re-establishing a
> failed DTLS association. I am ok if this is added as separate text and also
> making it optional to send new SDP O/A.*
>
>
I am thinking that session resumption by the active end point is virtually
identical to re-key (please correct me that I am wrong). Because of this,
it can be used both to recover the session or to re-key the DTLS connection
without any interaction with offer/answer. I do not want to see the need
for the optional SDP O/A here since normally SDP O/A with the same
transport parameters does not mean DTLS re-negotiation. Unless we add
something special in the O/A, it will not help in synchronizing the end
point state.

_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 26 Feb 2015 16:03:40 +0000

I am thinking that session resumption by the active end point is virtually identical to re-key (please correct me that I am wrong). Because of this, it can be used both to recover the session or to re-key the DTLS connection without any interaction with offer/answer. I do not want to see the need for the optional SDP O/A here since normally SDP O/A with the same transport parameters does not mean DTLS re-negotiation. Unless we add something special in the O/A, it will not help in synchronizing the end point state.
<Raju>
I am not sure what you meant by session resumption as it is ambiguous?! Is it the one specified in https://tools.ietf.org/html/rfc5764#appendix-B using “master context”? or https://tools.ietf.org/html/rfc4507 using SessionTicket? But neither seems to address the issue of reopening a closed DTLS association. Per my understanding, rekey of DTLS session happens within the context of an existing association (yes, with no new SDP O/A).

I understand that desire is to re-establish a failed DTLS without new SDP O/A. But I could not find any reference text which indicates a client should automatically attempt re-establish such a failed association (which may then use SessionTicket for resumption).
Either we need to add such text or allow a new optional SDP O/A. I also prefer the former approach.
</Raju>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Feb 2015 11:41:25 +0000

Hi,

Is there are definition of ”(D)TLS rekey” somewhere?

I find text talking about “re-doing the handshake”, but doesn’t that include re-sending the Client/ServerHello messages, which basically means re-establishing the (D)TLS connection?

Regards,

Christer

From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]]
Sent: 26. helmikuuta 2015 18:04
To: Roman Shpount
Cc: [email-masked]; Christer Holmberg; Simon Perreault
Subject: RE: DTLS-O/A: DTLS fingerprint and setup role MUST NOT change unless underlying transport also changes

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 27 Feb 2015 13:30:21 +0000

I find text talking about “re-doing the handshake”, but doesn’t that include re-sending the Client/ServerHello messages, which basically means re-establishing the (D)TLS connection?
<Raju>
I am afraid that there is no straightforward answer to this as I do not see these terms formally defined anywhere, but used everywhere inconsistently!
I think, the term rekey, rehandshake and renegotiation all mean same thing: a new Client/Server Hello exchange within the context of current association [1] and protected by  existing cipher suite[3].
TLS 1.5 RFC[1] used the term renegotiation only. DTLS RFC [2] used rehandshake terminology only! DTLS-SRTP[3] used all three terms: rekey, rehandshake, renegotiation. I think the use of “rekey” in this context is just to make it explicit to get new keys for SRTP use, but it is still “renegotiation”.

In conclusion, I think it is preferred to use ‘renegotiation’ for this procedure.
[1] TLS1.5 https://tools.ietf.org/html/rfc5246#section-7.4.1 and other sections as well:
7.4.1<https://tools.ietf.org/html/rfc5246#section-7.4.1>.  Hello Messages
   The hello phase messages are used to exchange security enhancement
   capabilities between the client and server.  When a new session
   begins, the record layer's connection state encryption, hash, and
   compression algorithms are initialized to null.  The current
   connection state is used for renegotiation messages.

      …

      This message MAY be ignored by

      the client if it does not wish to renegotiate a session, or the

      client may, if it wishes, respond with a no_renegotiation alert.

[2] DTLS https://tools.ietf.org/html/rfc6347#section-4.2.4

   When the server desires a rehandshake, it transitions from the

   FINISHED state to the PREPARING state to transmit the HelloRequest.

   When the client receives a HelloRequest, it transitions from FINISHED

   to PREPARING to transmit the ClientHello.

[3] DTLS-SRTP https://tools.ietf.org/html/rfc5764#section-5.2
5.2<https://tools.ietf.org/html/rfc5764#section-5.2>.  Rehandshake and Rekey

   Rekeying in DTLS is accomplished by performing a new handshake over

   the existing DTLS channel. That is, the handshake messages are

   protected by the existing DTLS cipher suite.

7.3.2<https://tools.ietf.org/html/rfc5764#section-7.3.2>.  Renegotiation

   Because the rehandshake transition algorithm specified in Section 5.2<https://tools.ietf.org/html/rfc5764#section-5.2>

   requires trying multiple sets of keys if no MKI is used, it slightly

   weakens the authentication.

</Raju>

BR
Raju