Hi,
Thanks for the comments, comments inline.
On Jun 24, 2013, at 4:37 PM, Sam Hartman wrote:
Please treat these comments as normal last-call comments.
I've been asigned as a security directorate reviewer for this draft.
This draft specifies a mechanism to indicate which packets were
discarded in a RTP stream. for the most part, this doesn't seem to have
any security implications, and the text is clear. I do have one
concern.
Has the WG analyzed implications of providing feedback to an attacker on
what specific SRTP packets are discarded? In the past we've run into
trouble with security systems that were too verbose in error reporting.
As an example, in certain public-key crypto constructions knowing
whether a packet produced a decoding error vs a signature error after
decryption can provide an attacker generating forged packets valuable
information to attack the system.
In the draft, discarded packets are defined as: packets that were received but
dropped from the jitter buffer because they were either too early (for
buffering)
or too late (for playout).
Since the timestamp field in the RTP header is not encrypted,
the endpoint can discard the packet before decrypting or authenticating it.
Forged packets that are discarded are not reported by this metric block.
It's quite possible that SRTP doesn't have problems in this regard. I
just want to confirm that the analysis has been done.
Cheers,
Varun
