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 | IETF 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 | 2015-10-14 (Latest revision 2013-11-11) | |
Completed reviews |
Genart IETF Last Call review of -05
by Francis Dupont
(diff)
Genart Telechat review of -06 by Francis Dupont (diff) Secdir IETF Last Call review of -05 by Sam Hartman (diff) |
|
Assignment | Reviewer | Sam Hartman |
State | Completed | |
Request | IETF 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.