Throughout the ongoing discussions, and in particular at today's meeting, I seem to encounter two separate, IMO flawed arguments.
Flawed argument 1: RFC 4474 is not just for securing the DTLS-SRTP certificate fingerprint, but also for securing any sort of SIP request, which might not even be session-related (e.g., MESSAGE, SUBSCRIBE). Therefore we can't change what is signed, because that would break these other usages, and even to some extent it would break its usage with requests that do contain SDP but do not involve DTLS-SRTP. This is flawed, because it does not accept the possibility of signing a different set of data when using DTLS-SRTP, whereby we ensure that important things like the certificate fingerprint and codecs get signed, but not things that might legitimately change en route, such as IP addresses and ports. In other words, SIP requests carrying DTLS-SRTP certificate fingerprints do not have the same requirements on integrity protection as other SIP requests. Flawed argument 2: The problem exists when we go through service providers. Service providers use only E.164-based SIP URIs. We can't do anything about E.164-based SIP URIs. Therefore we can't do anything to address the case where the request goes through service providers. Therefore there is nothing we can do. This is flawed because it doesn't recognise the possibility of sending both an email-style SIP URI and an E.164-based URI (SIP or tel), whereby the former is authenticated, along with integrity protection of appropriate parts of the message, and the latter is not (and hence can be changed by intermediate domains). For example, email-style in From and E.164-based in PAI. Comments? John _______________________________________________ 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
