Skip to main content

Last Call Review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05
review-ietf-xrblock-rtcp-xr-discard-rle-metrics-05-secdir-lc-hartman-2013-06-27-00

Request Review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-07-01
Requested 2013-06-20
Authors Joerg Ott , Varun Singh , Igor Curcio
I-D last updated 2013-06-27
Completed reviews Genart Last Call review of -05 by Francis Dupont (diff)
Genart Telechat review of -06 by Francis Dupont (diff)
Secdir Last Call review of -05 by Sam Hartman (diff)
Assignment Reviewer Sam Hartman
State Completed
Request Last Call review on draft-ietf-xrblock-rtcp-xr-discard-rle-metrics by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 09)
Result Has nits
Completed 2013-06-27
review-ietf-xrblock-rtcp-xr-discard-rle-metrics-05-secdir-lc-hartman-2013-06-27-00
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.

It's quite possible that SRTP doesn't have problems in this regard.  I
just want to confirm that the analysis has been done.