EKR wrote: > 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.
I agree with all those points. Thanks. -d _______________________________________________ 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
