I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.




http://www.ietf.org/id/draft-ietf-siprec-req-09.txt



The document is informational and describes use cases and requirements
for SIP-based Media Recording.
Overall I agree with the stated requirements in the document and
consider the Privacy and Security Considerations sufficient.

Privacy and Security sections could be enhanced by clarifying that the
integrity and correctness of the recorded data is not ensured by
(cryptographic) means to ensure that the CS has not been tampered with
(also see below). At least AFAIK. This would have to be done by
organizational and technical controls that prevent tampering with the
recording UA and the data stream between end point UA and SRC.

Best regards, Tobias



Ps.: On a personal note a small suggestion/idea for the authors:

- it seem the non-repudiation, authenticity and completeness (no dropped
packets) of recorded CS linked to individual participants is basically
unproven (if not impossible to prove in this setting?). I.e. an evil
recording entity might twist incoming streams from participants to
re-align given answers to different points in the stream or re-align its
own statements.
E.g. actual dialogue:
1. participant A "Do you want to buy this product?" 
2. participant B: "No."
3. participant A "Do you want to abort this operation?"
4. participant B: "Yes."

Could be twisted to:
1. participant A "Do you want to buy this product?" 
4. participant B: "Yes."
3. participant A "Do you want to abort this operation?"
2. participant B: "No."

or with only control of your own recorded data-stream:
3. participant A "Do you want to abort this operation?"
2. participant B: "No."
1. participant A "Do you want to buy this product?" 
4. participant B: "Yes."

I wonder whether authentication means (like signing) your session stream
with a personal key and chronology integrity ensuring mechanisms
(reliably linking messages to timestamps or previous messages from the
other party) would be worth consideration and could prevent such an attack.