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

[Adrian Georgescu <[e-mail]>]

On 21 Sep 2014, at 13:21, Paul Kyzivat <[e-mail]> wrote:

> [resending, including Adrian since I don't think he is on the siprec list. Please reply to this one so he is included.]
> 
> Adrian,
> 
> Thanks for commenting. Responses inline.
> 
>> From:     Adrian Georgescu <[e-mail]>
> 
>> Hi Paul,
>> 
>> 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.

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

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


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

> 
> 	Thanks,
> 	Paul
> 
>> 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.
>> 
>> Adrian
>> 
>> On 02 Sep 2014, at 11:20, Paul Kyzivat <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> 
>>> Adrian,
>>> 
>>> I've been working on a draft for the siprec wg about the recording of
>>> msrp.
>>> 
>>> Ben Campbell suggested that I contact you because you have more
>>> real-life experience with msrp than most people.
>>> 
>>> I would appreciate any comments you have on this draft.
>>> 
>>> For context, if you haven't followed siprec, you may have to look at
>>> some of the previous siprec drafts to understand what it is about. And
>>> I'll be happy to answer any questions you might have.
>>> 
>>> Thanks,
>>> Paul
>>> 
>>> 
>>> -------- Original Message --------
>>> Subject: [siprec] New Version Notification for
>>> draft-yan-siprec-msrp-recording-02.txt
>>> Date: Wed, 27 Aug 2014 16:28:41 -0400
>>> From: Paul Kyzivat <[e-mail] <mailto:[e-mail]>>
>>> To: [e-mail] <mailto:[e-mail]> <[e-mail]
>>> <mailto:[e-mail]>>
>>> 
>>> I just submitted a revised version of the MSRP recording draft.
>>> 
>>> The following is a summary of what is different in this version. (It is
>>> in the draft too.)
>>> 
>>>  This version addresses comments received on the -01 version, both on
>>>  the mailing list and at IETF90.  The following is my list of things
>>>  to address:
>>> 
>>>  o  Define a new MIME type that is used to wrap the CS MSRP messages
>>>     that are being recorded.  This allows the original message to be
>>>     left as-is, so it is always clear what it was.  While CPIM could
>>>     be used for this, defining a new type will allow capturing other
>>>     necessary metadata.
>>> 
>>>  o  Need to further consider the need to track message timing.  Can
>>>     the timing of messages received by the SRS on the RS MSRP stream
>>>     be considered a sufficient proxy for the timing of messages in the
>>>     CS, or should we explicitly pass timestamps of messages as
>>>     received on the CS?  (The issue was raised but not decided.)
>>> 
>>>  o  We need to clarify that there is no guarantee that messages
>>>     received on the CS have been recorded.
>>> 
>>>  o  It was agreed that there is no need to record the MSRP URIs that
>>>     are used to establish the CS MSRP session.
>>> 
>>>  o  It is important that we maintain a 1:1 consistency between MSRP
>>>     MESSAGE-IDs used in recorded CS sessions and the MESSAGE-IDs used
>>>     in the RS.  But we should not violate MSRP by using the same
>>>     MESSAGE-IDs.  We came up with the idea of adding an SRC-specific
>>>     prefix to the CS message ids to create unique ones for the RS.
>>>     This should be done in a standard way so that the SRS can recover
>>>     the original CS message ids, in order to support correlation
>>>     across redundant SRCs.
>>> 
>>>  o  Will need to work out the details of what happens when a CS MSRP
>>>     session is terminated with an incomplete message.  It will be
>>>     necessary to send the incomplete message to the SRS, but must it
>>>     appear to be incomplete within the SRS MSRP session?
>>> 
>>>  o  There are a variety of reasons why the SRC may not want, or be
>>>     able to, record individual messages in the CS session.  (One
>>>     example is because the message size is greater than the maximum
>>>     indicated by the SRS.  Another is because the mime type of the
>>>     message is a type that the SRS did not indicate support for.)
>>>     There should be a type of placeholder message that can be sent to
>>>     the SRS to indicate a message has been dropped, why, and some key
>>>     attributes about the message.  The new SIPREC wrapper mime type
>>>     could be designed to serve this purpose.
>>> 
>>>  o  REPORT messages on the CS can't be sent directly on the RS.  The
>>>     new SIPREC wrapper mime type could also serve as a way to
>>>     encapsulate those.
>>> 
>>>  The primary change is to introduce a new wrapper MIME type
>>>  ("application/msrp-recording") that is used in RS MSRP sessions for
>>>  all CS MSRP messages that are to be recorded.  This is used with SEND
>>>  messages whether they have a CPIM wrapper or not.  It also allows
>>>  non-SEND messages from the CS to be sent intact in the RS for
>>>  recording.  And it provides a vehicle for carrying other data as
>>>  needed.
>>> 
>>>  Adding another layer of wrapper could substantially increase the
>>>  total amount of data send on the RS session, relative to what is
>>>  present on the CS.  I've tried to mitigate that via the details of
>>>  the design.  For SEND messages, only the body of the SEND message is
>>>  wrapped.  And From and To headers in this wrapper can be omitted in
>>>  cases where that information is redundant.  I've assumed that
>>>  messages other than SEND should in general be infrequent enough that
>>>  extra overhead when sending them isn't worth a lot of concern.
>>> 
>>>  This wrapper can carry a DateTime header.  This provides a mechanism
>>>  to address the timestamp issues.  I've left it as optional to use.
>>> 
>>>  I clarified the non-guarantee of recording in the architecture
>>>  section.
>>> 
>>>  I've provided a special header in the wrapper to carry the MESSAGE-ID
>>>  from SEND messages in the CS.  And SEND messages will get a separate
>>>  MESSAGE-ID on the RS MSRP session when sent to the SRS.  This
>>>  provides the SRS with enough information to solve the correlation
>>>  problem when a message is incomplete in one CS MSRP session and is
>>>  resumed on another.  (The problem of reassembly is left to the SRS.)
>>> 
>>>  The wrapper format includes a mechanism for the SRC to report dropped
>>>  messages to the SRS.
>>> 
>>>  The wrapper format also includes a mechanism for encapsulating CS
>>>  REPORT messages for sending to the SRS.
>>> 
>>>  I realized that this level of wrapping provides an opportunity to
>>>  multiplex unrelated CS MSRP sessions on a single RS MSRP session.  To
>>>  allow this I've provided a way to include the session-id from the
>>>  metadata, that identifies the particular CS MSRP session, as a value
>>>  in the wrapper of the message sent on the RS.  But I also made that
>>>  optional when it is redundant.  This gives a choice: multiplex but
>>>  make the messages bigger, or create a separate RS MSRP session for
>>>  each CS MSRP session and keep the messages smaller.  I've included
>>>  this as a trial balloon for discussion.  I'm undecided about it.
>>> 
>>>  The formatting of all of this could be better.  But for now I just
>>>  wanted to get the basic concepts down for review.  Once the approach
>>>  is reasonably well worked out I'll try to improve the formatting.
>>> 
>>>  There are many places here where I am uncertain what normative
>>>  strength to apply to individual requirements.  I've indicated this
>>>  inline for many of those.  Please comment on this.
>>> 
>>> I believe this is in line with what was discussed in Toronto.
>>> 
>>> I especially want to hear whether people find this an acceptable
>>> direction, as well as thoughts on the details. And anything I might have
>>> overlooked that still needs to be addressed.
>>> 
>>> Thanks,
>>> Paul
>>> 
>>> -------- Original Message --------
>>> Subject: New Version Notification for
>>> draft-yan-siprec-msrp-recording-02.txt
>>> Date: Wed, 27 Aug 2014 13:19:15 -0700
>>> From: [e-mail] <mailto:[e-mail]>
>>> To: Michael Yan <[e-mail]
>>> <mailto:[e-mail]>>,        "Paul H. Kyzivat"
>>> <[e-mail] <mailto:[e-mail]>>,
>>>       "Michael Yan" <[e-mail]
>>> <mailto:[e-mail]>>,
>>>      "Paul Kyzivat" <[e-mail]
>>> <mailto:[e-mail]>>
>>> 
>>> 
>>> A new version of I-D, draft-yan-siprec-msrp-recording-02.txt
>>> has been successfully submitted by Paul H. Kyzivat and posted to the
>>> IETF repository.
>>> 
>>> Name:draft-yan-siprec-msrp-recording
>>> Revision:02
>>> Title:Overview for MSRP Recording based on SIPREC
>>> Document date:2014-08-27
>>> Group:Individual Submission
>>> Pages:17
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-yan-siprec-msrp-recording-02.txt
>>> 
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-yan-siprec-msrp-recording/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-02
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-yan-siprec-msrp-recording-02
>>> 
>>> Abstract:
>>>  SIPREC is capable of recording interactive text media that is
>>>  transmitted via RTP.  However that format is not commonly used for
>>>  message or chat scenarios.  There is also a need for recording text
>>>  media carried via MSRP.  One case of note is exchange of text between
>>>  hearing-impaired users and emergence service bureaus.  Also,
>>>  recording support is needed for MSRP used in chat conferences and
>>>  multimedia conferences.
>>> 
>>>  This document describes how to achieve MSRP channel recording within
>>>  the mechanism of SIP Recording (SIPREC).
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> siprec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>> 
>>> 
>>> 
>> 
>> --
>> Adrian
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>> 
> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
> 

--
Adrian