> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric > Rescorla > > First, you claim "SRTP-DTLS requires RFC 4474 (for full function)". > That's not quite correct, and I think it's worth walking through > the security analysis.
Agreed, but I don't think he's claiming his sentence as a fully qualified truism, but rather as a short-hand for: "We need one or both of RFC 4474/4916 to be used in common practice, and to sign the SDP, because without one or both of those mechanisms being used it allows a MitM to be a DTLS-SRTP middle-man." > 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 don't think Dean is claiming a MitM attack is possible when 4474/4916 *is* used. At least not in the definition of "MitM attack" where one side *thinks* it's secure but it's not. Clearly a form of MitM attack can be trivially performed whereby neither side get signed requests, but still get fingerprints, but that's not a MitM attack in my book as much as it is a downgrade attack. And that form of attack can be done on your example above, very easily, but then both Alice and Bob should know their media plane isn't secure. And similar to TLS, Alice has to take care not to speak her PIN over the media plane to Bob, etc. But I think Dean's point is: if we can't get a 4474/4916 model to be useful in practice, then *neither* side will be using it in practice. We want it to be used in practice, as much as possible. But he should chime in with what he meant. :) Also, I'm not sure 4916 gives that "other direction" behavior. It signs an upstream request, from the original UAS to the UAC. It does not sign an SDP offer/answer from the UAS in the initial INVITE response, and thus does not sign the fingerprint, at least initially. And even if 4916 is subsequently used, I think (though I'm not sure), that the UAS could well send the 4916 signature in an upstream request with no SDP, thus again not be signing the fingerprint. (Although the correct thing to do may well be spelled out in Jason's draft, so maybe that's a nit) And clearly that's not a fault of DTLS-SRTP fingerprint but rather of 4474 not providing a way for responses to be signed, and is a separate topic. -hadriel _______________________________________________ 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
