[AVT] RE: [MMUSIC] Symmetry breaking for DTLS-SRTP

["Elwell, John" <[e-mail]>]

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:[e-mail]] 
> Sent: 24 October 2007 17:59
> To: [e-mail]; [e-mail]
> Subject: [MMUSIC] Symmetry breaking for DTLS-SRTP
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

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