At Mon, 14 Apr 2008 12:30:02 -0700, Dan Wing wrote: > > You write: > > > > We need to sign it, because SRTP-DTLS relies on the > > signature in order > > to protect the fingerprint of the media key from MITM attacks. > > > > This isn't quite correct. As long as one side verifies the other > > side's identity, than MITM attacks get blocked, because an MITM attack > > requires replacing keys in both directions with the attacker's > > key. Consider the following example, in which Alice is calling Bob, > > but for some reason her fingerprint isn't signed: > > > > > > Alice Attacker Bob > > ---------------------------------------------------------- > > Fingerprint=X (unsigned) -> > > Fingerprint=A (unsigned) -> > > > > <- Fingerprint=Z (signed, Bob) > > <- Fingerprint=Z (signed, Bob) > > > > So, Bob has no reliable way of knowing Alice's identity. However, > > that's not sufficient to mount an MITM attack, which required that the > > attacker to replace Bob's key Z with his own key A. But he can't do > > that without replacing Bob's fingerprint, which would require the > > ability to sign a message from Bob [0]. > > I think this analysis is optimistic regarding Alice's behavior. > > Taking a less optimistic approach: > > As shown in your diagram, Alice generates a message that is not > signed (due to misconfiguration or some other reason). Due to > Alice's already-defective configuration, Alice may not expect > Bob's message to be signed, and thus the attacker could > simply strip Bob's signature, replace Bob's a=fingerprint, and > successfully be a MitM. Furthermore, Alice cannot assume that > Bob implements Connected-Identity, so Alice can't really assume > that Bob *will* generate a signature at all. Or do we require > Connected-Identity in the DTLS framework, and require receipt > of that Connected-Identity-signed message before the call is > completed (using security-preconditions, perhaps)?
I think you're making life much more complicated than it needs to be for the attacker. The attacker can simply pretend to be Bob, not generate a signature, and pretend he is only willing to speak RTP. There are two issues that need to be disentangled here: - What you display on your UI - What causes your UA to terminate the connection Given that at the initial deployment of this system the vast majority of users will not have any cryptographic capability of any kind, I would expect that most UAs will be willing to place or accept phone calls with at least the following sets of people (people who won't do any crypto, people who do RFC 4474 but not DTLS-SRTP, people who will do DTLS-SRTP but without RFC 4474 signatures, people who will do DTLS-SRTP with RFC 4474 signatures). The best we can expect is that the UI will clearly differentiate these three cases so the user can do something meaningful if they care. The only case where I would expect the UA to automatically drop the call is if there were some clear cryptographic failure, e.g., the fingerprints didn't match. At some point in the future once there is reasonable deployment, then it may become reasonable for users to configure their endpoints to only place or accept phone calls from people who do some level of crypto. I can imagine a number of reasonable profiles, depending on what threats you were most concerned with. But this seems clearly up to the individual deployment. That said, it's clearly the case that if you want to be able to verify the identity of the person you called, you're going to need some RFC 4474-like thing from them, whether it's 4916, 4474 w/ outbound, S/MIME, or whatever. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
