> > Strong identity makes it *harder* to build a phone-tapping > system. > > This > > hop-by-hop signing thing that you are describing above, and Jon > > described at > > the microphone, is transitive trust with extra CPU horsepower and > > something > > you could fight better in a lawsuit when you learned that a > service > > provider > > lied. I don't see a service provider getting very interested in the > > additional capex, opex, and business risk of doing such signing, > > especially > > compared to the three proposals on the table which require > the service > > provider do _no_ signing and no stronger attestation than today > > (same business > > risk as today). > > > You misunderstand the hop-by-hop signing approach I described. By > adding signatures, rather than replacing them, the original > media and > DTLS key identifier properties are preserved. The stack of > signatures > and new SDPs provide an audit chain for figuring out what > happened and > for a basis of transitive trust where end-to-end trust is not > existent, but do not impede the ability for end-to-end when the > endpoints have that capability.
You are right, I had misunderstood. Your proposal is different from the proposal that Jon described at the microphone. However, it would disclose the entire path which SP's appear reluctant to do -- else they would not remove Via headers (I understand most SPs, using SBCs, remove Via headers). -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
