Last Call Review of draft-ietf-rtcweb-fec-08
review-ietf-rtcweb-fec-08-secdir-lc-orman-2019-02-07-00
Request | Review of | draft-ietf-rtcweb-fec |
---|---|---|
Requested revision | No specific revision (document currently at 10) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2019-02-01 | |
Requested | 2019-01-18 | |
Authors | Justin Uberti | |
I-D last updated | 2019-02-07 | |
Completed reviews |
Secdir Last Call review of -08
by Hilarie Orman
(diff)
Opsdir Telechat review of -08 by Jürgen Schönwälder (diff) |
|
Assignment | Reviewer | Hilarie Orman |
State | Completed | |
Request | Last Call review on draft-ietf-rtcweb-fec by Security Area Directorate Assigned | |
Reviewed revision | 08 (document currently at 10) | |
Result | Has issues | |
Completed | 2019-02-07 |
review-ietf-rtcweb-fec-08-secdir-lc-orman-2019-02-07-00
Hi, Please note that this review is for draft-ietf-rtcweb-fec-08, not the PERC draft referenced in the subject. Thanks! Ben. > On Feb 1, 2019, at 1:42 AM, Hilarie Orman <hilarie@purplestreak.com> wrote: > > Security Review of WebRTC Forward Error Correction Requirements > draft-ietf-rtcweb-fec-08 > > Do not be alarmed. 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. > > The document describes the appropriate uses of FEC for web content when > using WebRTC. It also describes how to indicate that FEC is being used. > > The Security Considerations mention the possibility of additional network > congestion when using FEC. Although this can be a problem, I do not think > it is a security issue, thus it does not belong in this section. > > There is a security-related issue wrt to FEC and encryption. If the > error model is that message blocks may be lost but not altered in > transit, then FEC with encryption is fine. But if FEC is added for > the purpose of correcting corrupted bits in a message block, then it > is important that FEC is done after encryption. The draft seems to > ignore the issue, and it also seems to recommend a processing scheme > that would result in encryption of the FEC data. If there is a body > of practice for other IETF FEC protocols that explains these issues, > an explicit reference to it in the Security Considerations would be > very helpful. > > Hilarie > >