[AVT] Symmetry breaking for DTLS-SRTP

[Eric Rescorla <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt