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

[Paul Kyzivat <[e-mail]>]

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?
Does it use a new wrapper MIME type?
Is the key exchange done in SDP or in MSRP messages?

>> 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.

> 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.

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?

	Thanks,
	Paul