Subject: [MMUSIC] Symmetry breaking for DTLS-SRTP

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2007 09:59:08 -0700

TLS (and by extension) DTLS-SRTP requires unambiguity about which side
is to be the client and which is the server. This isn't an issue of
credentials--DTLS-SRTP assumes that each side can take either
role--it's just that TLS requires that one side initiate the
handshake. My original intention had been to make this conditional on
which side was the offerer and which was the answerer, but JDR pointed
out in ORD that there are cases involving 3PCC where it's not
unambiguous which is which.

Here's the paradigmatic case, transcribed from a phone call with
JDR (so any errors are my fault):

Alice                        Controller                        Bob
------------------------------------------------------------------
INVITE + Offer ->
                              INVITE ->
                                                     <- OK + Offer
                      <- OK + Answer                              
                              ACK + Answer ->
ACK ->

Because the controller sends an INVITE with no offer, Bob is the
offererer, and of course Alice is. So, you can't use offerer
or answerer to break symmetry. 

This same problem occurs with ICE, which uses a random tiebreaker
value in the ICE messages to determine which side should take
which role (controlling vs. controlled). This works because
in ICE both sides are trying to transmit so they quickly 
detect conflicts. Unfortunately, in DTLS-SRTP, the server just
waits so if the rule we adopt allows both sides to think they
are the server then we get deadlock. The above exchange 
shows how both sides can be offerer so clearly we can't have
offerer=server, but it seems that we could make a new exchange
where both sides are answerer in which case we can't have
offerer=client. JDR tells me that we don't have an actual
use case like this yet but I would not want to count on that
unless we're very sure.

We could use exactly the trick that ICE uses but that requires
modifying DTLS to make the server send messages unprompted.
I don't think that's necessary here because we can break
the tie in the SDP where we announce the DTLS-SRTP capability
(however that's done).

The basic principle is this:
1. Each side generates a random tiebreaker value T.
2. In the SDP offer/answer, he indicates whether he wishes
   to be the TLS client or server (if you're the offerer
   you SHOULD ask to be the server since that's faster, 
   and vice versa).
3. If each side sees a consistent view (one client, one 
   server) then that is what is used.
4. If the views are inconsistent, then the side with the
   higher T is be the client.

This is basically the same algorithm as used with ICE, just
moving the tiebreaker into the SDP.

Does anyone see a problem with this?

-Ekr

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Oct 2007 20:16:37 +0100

Ekr,

I don't have a problem with the solution, but I am doubtful whether it
is a problem we need to solve. The case illustrated is based on the
assumption that offer and answer are symmetrical, in the sense that an
offer can be reused as an answer (and vice versa). In this case the
offer from A becomes an answer to B and vice versa. There are two
extensions to SDP that I am aware of that break this, and therefore any
controller that misuses SDP in this way will screw things up. One
example is the key management extension when used to carry MIKEY,
because a MIKEY request (which always goes in the offer) is very
different in syntax and semantics from a MIKEY response (which always
goes in the answer). Of course, this will not apply when using DTLS-SRTP
as the means of key management. The second example is the SDP capability
negotiation draft, which certainly will be applicable with DTLS-SRTP.

I am not aware of how the particular flow shown would arise. It is not
documented in RFC 3725 (3PCC). It has similarities to flow II in RFC
3725, which the RFC does not recommend. The other 3PCC flows in RFC 3725
do not mix up offers and answers in this way.

I also questioned the need for the solution in ICE, but as it came
virtually for free, it was not worth arguing about.

If we continue this discussion, I would suggest we stick to the MMUSIC
list rather than AVT.

John

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: 24 October 2007 17:59
> To: [email-masked]; [email-masked]
> Subject: [MMUSIC] Symmetry breaking for DTLS-SRTP
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2007 12:36:31 -0700

At Wed, 24 Oct 2007 20:16:37 +0100,
> virtually for free, it was not worth arguing about.

For the record, I'm certainly happy not to have to solve this problem,
and I don't understand the use cases well enough to understand whether
it is something we need to solve. I'm basing this solely on the
discussion in ORD and a conversation with JDR. If the MMUSIC WG
feels this is a non-issue that's totally fine with me.

> If we continue this discussion, I would suggest we stick to the MMUSIC

Done.

-Ekr

---

From: "Robert R. Gilman" <[email-masked]>
Date: Fri, 26 Oct 2007 14:22:35 -0600

John-
I think such flows can arise from a case in which one party, rather than
the controller, intiates the call.  But, as you point out, the controller
cannot blindly pass one offer through to serve as an answer; it must
modify the SDP in some cases.  For DTLS, in accord with the rules in
section 4.1 of RFC 4145, the offeror, assuming it can act as either a
server or a client, should use
	a=setup-attr: actpass
and should be prepared to receive a client_hello before it receives the
answer.  In the two-party case, the answer would normally include
	a=setup: active
and the answerer would go ahead and send the client_hello in the media
path.  This permits the controller (indeed, it requires the controller)
to break the symmetry by modifying the SDP, hence we don't need any
random numbers (which remind me too much of the H.245 master/slave
resolution scheme).  If, for some reason, an endpoint can only act as
a server, say, then in must send passive, and the controller can adjust
which end it selects to be active - or it can refuse the call (or
terminate the media on a media server) if both endpoints insist on the
same role.  I believe this scheme is compatible with Dan Wing's draft:
draft-wing-sip-identity-media-00.

The exchange might look something like this:

Alice                        Controller                        Bob
------------------------------------------------------------------
INVITE + Offer(actpass) ->
                                     INVITE ->
                                              <- OK + Offer(actpass)
           <- OK + Answer(active)    ACK + Answer(passive) ->
       <- - - - - - - - - - - client_hello - - - - - - - - - -
ACK ->
                               ....
Does this make sense?
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Oct 2007 10:32:50 +0000

OK, but to take my example of SDP capability negotiation, the controller
would have to resolve it somehow, i.e., for each leg, select a
configuration that is compatible with one of the proposed configurations
from Alice and with one of the proposed configurations from Bob, and
include this in the answers to Alice and Bob respectively. Ugly.

John

> From: Robert R. Gilman [mailto:[email-masked]] 
> Sent: 26 October 2007 21:23
> To: Elwell, John; Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Symmetry breaking for DTLS-SRTP
> 
> John-

---

From: "Robert R. Gilman" <[email-masked]>
Date: Mon, 29 Oct 2007 09:25:31 -0600

My example shows the same thing: the Controller has to (at least) turn
"a=setup: actpass" into "a=setup: active" in one direction and "a=setup:
passive" in the other.  It could also "harmonize" codec parameters, etc.,
(possibly the reason the Controller bothered to intervene in the first
place.)  I don't think anyone would call it "pretty", but I can't say
someone won't find a good use for it.  The "solution" costs us almost
nothing if the Controller is absent: the endpoint always responds to an
offer with "a=setup:active" unless it has a good reason not to  The
typical endpoint will know how to act as either a client and a server,
and those that can't (e.g., an answer-only endpoint that demands to
be "active") must say so in their offers.  As you point out, it's
the job of the Controller to make sense of what it's created (if it
can.)
-Bob
----------------------------------------------------
Bob Gilman       [email-masked]      +1 303 538 3868

Elwell, John wrote:
>>>I don't have a problem with the solution, but I am doubtful 
>>
>>whether it
>>
>>>assumption that offer and answer are symmetrical, in the 
>>
>>sense that an
>>
>>>extensions to SDP that I am aware of that break this, and 
>>
>>therefore any
>>
>>>different in syntax and semantics from a MIKEY response 
>>
>>(which always
>>
>>>goes in the answer). Of course, this will not apply when 
>>
>>using DTLS-SRTP
>>
>>>as the means of key management. The second example is the 
>>
>>SDP capability
>>
>>>negotiation draft, which certainly will be applicable with 
>>
>>DTLS-SRTP.
>>
>>>I am not aware of how the particular flow shown would 
>>
>>arise. It is not
>>
>>>3725, which the RFC does not recommend. The other 3PCC 
>>
>>flows in RFC 3725
>>
>>>If we continue this discussion, I would suggest we stick to 
>>
>>the MMUSIC
>>
>>>list rather than AVT.
>>>
>>>John
>>>
>>>
>>>
>>>>TLS (and by extension) DTLS-SRTP requires unambiguity about 
>>
>>which side
>>
>>>>handshake. My original intention had been to make this 
>>
>>conditional on
>>
>>>>which side was the offerer and which was the answerer, but 
>>
>>JDR pointed
>>