Subject: [AVT] 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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

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
> 
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>