Re: [stir] RFC 4474bis Last Call - Fingerprint

[Chris Wendt <[e-mail]>]

I did get this comment from other folks as well and for mky, I will be updating in the next release of passport incorporating a MUST for ordering fingerprint values in lexicographic order to guarantee it validating in the case where fingerprint order is changed.

Hopefully this should solve your concerns.

Thanks.

> On Sep 2, 2016, at 4:12 PM, Peterson, Jon <[e-mail]> wrote:
> 
> 
> To recover these if they were removed requires the presence of "canon." That does not mean that "canon" is or should be required.
> 
> Again, the decision to make "canon" optional depends on how common we anticipate these removal cases will be, and how heavily we would weigh the cost of increasing the message size every time we use Identity. We've had this discussion a number of times now, including a consensus call at the last meeting, and consistently the conclusion has been to keep "canon" optional. This "mkey" one especially I do not anticipate will result in a common failure condition.
> 
> Jon Peterson
> Neustar, Inc.
> 
> From: Christer Holmberg <[e-mail] <mailto:[e-mail]>>
> Date: Friday, September 2, 2016 at 1:01 PM
> To: Jon Peterson <[e-mail] <mailto:[e-mail]>>, David Frankel <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [stir] RFC 4474bis Last Call - Fingerprint
> 
>> Hi,
>>  
>> >PASSporT is designed to allow media streams to be reordered (again, this is one of the >cases Jonathan Lennox raised that got us to change the original "mkey" syntax). Setting an >"m=" line to zero and removing the associated fingerprint will also be captured by "canon" >and should be recoverable - provided of course that the intermediaries are willing to let >"canon" through.
>>  
>> Doesn’t that require “canon”, and the claims, to be present in the request? In the latest version of 4474bis they are still optional…
>>  
>> Regards,
>>  
>> Christer
>>  
>>  
>>  
>> From: stir <[e-mail] <mailto:[e-mail]>> on behalf of Christer Holmberg <[e-mail] <mailto:[e-mail]>>
>> Date: Friday, September 2, 2016 at 12:02 PM
>> To: David Frankel <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint
>>  
>>> Hi,
>>>  
>>> In addition to the cases David presented, there can also be an intermediary disables media by setting the m= line port value to zero. In such cases the intermediary may also remove all fingerprint attributes associated with the m= line.
>>>  
>>> And, even if all fingerprints sent by the signer reach the verifier, there is no guarantee they will be in the same matter. Not sure whether it matters as far as calculating the signature is concerned, but just to keep in mind…
>>>  
>>> In general, assuming we are going to use (or at least allow) Appendix F, we cannot change any “MUST” to “MAY”, because we need to specify exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.
>>>  
>>> Regards,
>>>  
>>> Christer
>>>  
>>>  
>>>  
>>> From: stir [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of David Frankel
>>> Sent: 02 September 2016 21:04
>>> To: [e-mail] <mailto:[e-mail]>
>>> Subject: [stir] RFC 4474bis Last Call - Fingerprint
>>>  
>>> Greetings.
>>>  
>>> I find myself worried about the following text in the 4474bis draft at 4.1:
>>>  
>>> “Fourth, if the request contains an SDP message body, and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] Section 3.2.2.2.”
>>>  
>>> As I understand it, this is done to ensure that the fingerprint has not been altered (perhaps by a “man in the middle”) and give confidence that the media is encrypted end-to-end.
>>>  
>>> However, I fear that this may break STIR in some not-entirely-uncommon situations. Public network SIP calls are routinely re-originated (as we’ve discussed). Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream as well as the SIP messaging. For example, a transit operator might need to transcode the audio if the operators on either side don’t have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reality may be that anybody that can handle a-law can handle mu-law, so transcoding should “never” be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA) the interceptor would still be able to LISTEN without altering the fingerprint, so perhaps that wouldn’t break the STIR signature.
>>>  
>>> I raise the point for discussion. (The details here are a bit outside my expertise, and I probably missed some earlier discussion.) One possible suggestion is to change “MUST” to “MAY” in the text I quoted above. This gives the originator of the call the opportunity to decide whether they want downstream operators to have the flexibility to alter the fingerprint but still maintain the end-to-end identity assurance offered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this would let them do that (I think).
>>>  
>>> While protecting the fingerprint is a nice-to-have, I didn’t recall it in the STIR charter or problem statement.
>>>  
>>> David
>>>  
>>> David Frankel
>>> ZipDX® LLC
>>> Monte Sereno, CA USA
>>> Tel: 1-800-FRANKEL (1-800-372-6535)
>>> Watch Our Video! <http://www.zipdx.info/features/>
>>>  
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir