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

[Adrian Georgescu <[e-mail]>]

On 26 Sep 2014, at 13:54, Paul Kyzivat <[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