Re: [siprec] New Version Notification for draft-yan-siprec-msrp-recording-02.txt

[Paul Kyzivat <[e-mail]>]

Adrian,

Your responses lead me to have a number of other questions.
I'll deal with each in a separate reply, changing the subject to reflect 
the content.

	Thanks,
	Paul

On 9/27/14 7:39 AM, Adrian Georgescu wrote:
>
> On 26 Sep 2014, at 13:54, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> Adrian,
>>
>> Thanks for your input. Please find more comments inline.
>>
>> On 9/25/14 7:24 PM, Adrian Georgescu wrote:
>> [snip]
>>>>> I had a look at it. I am an engineer and look at practical maters.
>>>>> I use
>>>>> MSRP chat and file transfers almost every day with Blink and Blink uses
>>>>> OTR by default. That means that media is end-to end encrypted and this
>>>>> happens by default rather than users having to enable it. If someone
>>>>> tampers with the encryption, user is alerted and will he/she is likely
>>>>> to bail out of the conversation if is intercepted. Therefore scenario
>>>>> 3.2 where an MSRP relay is used for intercept purpose does not hold
>>>>> because of possible usage of end-to-end encryption in the clients.
>>>>> Unless you control at least one of the end-points, you cannot
>>>>> intercept.
>>>>> Mandating that MSRP relays support a feature it cannot enforce is kind
>>>>> of flaw. I would leave it out or explaining why it does not work.
>>>>
>>>> I'm not familiar with OTR other than what wikipedia tells me, and it
>>>> doesn't say how it works with MSRP.
>>>>
>>>> I'm guessing that it is just encrypting the body of messages? (So that
>>>> MSRP relays can still be used - but can't understand the content of
>>>> the body.)
>>>
>>> Correct. Same as RTP relays can store RTP with zRTP encrypted data where
>>> the encryption key is not known by the SIP server as the key is not
>>> exchanged in clear text inside signalling.
>>
>> How is OTR integrated into MSRP?
>> How is it negotiated?
>
> Inside the message chat stream, is just ascii like any normal message.
> Once the MSRP stream is up any party can start negotiating OTR at any
> point during the lifetime of the session.
>
>> Does it use a new wrapper MIME type?
>
> No
>
>> Is the key exchange done in SDP or in MSRP messages?
>
> Plain MSRP chat stream
>
>>
>>>> If so, then I don't think this changes much. A relay could still
>>>> record what it gets, even if the recorded content is unintelligible to
>>>> most.
>>>
>>> Yes, technically they could stored the encrypted data.
>>>
>>>>
>>>> Suppose that were the case. Would the recorded content be decodable by
>>>> full knowledge of the keys of sender and receiver?
>>>>
>>>
>>> Not always or not likely depending on implementation. Not when using a
>>> forward secrecy mechanism for example. One cannot decode future
>>> communication with an old key:
>>>
>>> https://en.wikipedia.org/wiki/Perfect_forward_secrecy
>>>
>>>
>>>> Also, we don't mandate which elements do recording. We only try to
>>>> describe possibilities.
>>>
>>> This is why possibilities likely to fail deterministically should be
>>> dismissed.
>>
>> Well, that judgement may be right in cases where OTR is in use. But I
>> don't think we can assume that it always is. The actual choice of if,
>> where and how to install SRCs in middleboxes will be made by
>> administrators who have some knowledge of how the system is being used.
>>
>> But based on this discussion I think we should probably add some text
>> noting that this case will not be useful if e2e encryption of messages
>> is being used.
>>
>>>> So perhaps in the your case useful recordings could only be done by
>>>> the endpoints. (That might be the desired effect for those using OTR.)
>>>>
>>>> If so, perhaps that deserves some consideration. As currently
>>>> described, the recording is applied to the MSRP messages, as seen by
>>>> *somebody* in the path those messages traverse. If those messages are
>>>> encrypted, then perhaps that is the wrong strategy. Perhaps in that
>>>> case it is the *unencrypted* messages that need to be recorded.
>>>> (Possibly encrypted again for the recorder.) That would require some
>>>> changes to the proposal.
>>>
>>> One relay can guess if OTR is negotiated as the data is cleartext inside
>>> the MSRP data but beyond this, if the relay tries to interfere with the
>>> initial OTR negotiation, both end-points will know.
>>
>> I must not have been clear enough. I was assuming that when OTR is in
>> use that recording could only be done by the endpoints (who have
>> access to the unencrypted form of the messages). The existing text
>> talks about recording of the body of the SEND messages. In the case of
>> encrypted messages, it would have to be the unencrypted form of the body.
>>
>> Also, the base siprec specs say that the protection of the RS must
>> always be at least as strong as that of the CS. When using OTR on the
>> CS, will that mean also using OTR on the RS?
>>
>>>>> The scenario where recording makes most sense is multi-party chat
>>>>> conversations. There you explicitly give up on privacy for the sake of
>>>>> sharing capabilities and recording is a useful feature. If an MSRP
>>>>> switch is used, than the relay is not mandatory so again scenario
>>>>> 3.2 is
>>>>> not realistic.  I would but scenario 3.3 in pole position in the
>>>>> document.
>>>>>
>>>>> Last, I would like to see a provision in the draft to make possible for
>>>>> an end-user to indicate that it does not want its message to be stored
>>>>> by the other side (the reverse feature of a party initiating
>>>>> interception and telling the other side about it).
>>>>
>>>> Are you familiar with the base siprec drafts? (Particularly
>>>> draft-ietf-siprec-protocol-14.) There is a mechanism (a=recordpref) to
>>>> indicate a preference for recording, or for *not* recording. It
>>>> applies to audio and video, and with the msrp-recording draft it will
>>>> apply also to that.
>>>
>>> This requires a re-INVITE, which may fail later in the middle of the
>>> session, or be out of sync with media plane, while the media continues
>>> to flow. It is a bad strategy as signalling and data are disconnected.
>>
>> Well, this is what was mandated for audio and video. For those, AFAIK
>> there is no way to carry the signaling for this in the media.
>
> MSRP is different as each message can carry by design any type of media
> described by its content-type inside the CPIM envelope.
>
>>
>>> So mandating to use SIP packet that may get lost to control MSRP chat
>>> messages in progress, is not gonna work properly. I want to know
>>> deterministically that my next MSRP message is not going to be stored
>>> (or fail to send at all), regardless of the SIP signalling or other
>>> middle box protocols that helped setup the MSRP media in the first place.
>>
>> With the current siprec mechanism, the do-not-record indication on the
>> CS is a *request* from a UA to the SRC. The SRC doesn't have to honor
>> it. However it is required to signal its actual
>> recording/not-recording state. So the requesting UA can decide not to
>> transmit sensitive information (or terminate the session) if it
>> doesn't get an indication that recording has stopped. And similarly if
>> the re-INVITE fails.
>
> For RTP sounds reasonable. For MSRP however is not ideal as it is much
> safer and reliable to send a MSRP message for which there is end-to-end
> integrity, sequencing and delivery reporting capability.
>
>>
>> We *could* define a different mechanism for use with with MSRP
>> recording. That would require defining an extension to MSRP for the
>> purpose. That is a possibility, though it raises the bar a bit.
>>
>>>>> We use this feature
>>>>> in Blink today and I find it useful as sometimes I want to write
>>>>> something that I know that the other party would not save in its
>>>>> history
>>>>> database like a password or other data that need to be consumed and not
>>>>> reused latter.
>>
>> So how do you do this? Have you defined an MSRP or CPIM extension? Or
>> have you defined a special MIME type for a body that communicates this?
>
> I just send a CPIM message like these:
>
> content_type='application/history-on'
>
> or
>
> content_type='application/history-off'
>
> The support for this feature is negotiated in the SDP of the MSRP media
> block, e.g.:
>
> Offer:
>
> o=- 3620806345 3620806345 IN IP4 192.168.8.3
> s=Blink 4.7.4 (MacOSX)
> m=message 2855 TCP/TLS/MSRP *
> c=IN IP4 192.168.8.3
> a=path:msrps://192.168.8.3:2855/d456be2d8daeff9a39f4;tcp
> a=accept-types:message/cpim text/* application/im-iscomposing+xml
> a=accept-wrapped-types:*
> a=setup:active
> a=features:history-control icon
>
> Answer:
>
> o=- 3620806346 3620806347 IN IP4 10.0.0.139
> s=SylkServer-2.6.0
> c=IN IP4 10.0.0.139
> m=message 51634 TCP/TLS/MSRP *
> a=path:msrps://81.23.228.139:51634/dffc7ea17130f811b6fc;tcp
> a=accept-types:message/cpim
> a=accept-wrapped-types:*
> a=setup:passive
> a=chatroom:nickname private-messages com.ag-projects.screen-sharing
>
>
> PS.
>
> OTR stands for "Off The Record" but I really mean the end-to-end
> encryption and verification part. Keeping records of the conversations
> is in my view a separate feature from the end user point of view which
> does not necessarily require OTR.
>
>>
>> Thanks,
>> Paul
>>
>
> --
> Adrian
>
>
>