Last Call Review of draft-ietf-rtcweb-use-cases-and-requirements-14

Request Review of draft-ietf-rtcweb-use-cases-and-requirements
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-05-13
Requested 2014-04-17
Authors Christer Holmberg, Stefan Hakansson, Goran Eriksson
Draft last updated 2014-05-22
Completed reviews Genart Last Call review of -14 by Brian Carpenter (diff)
Genart Telechat review of -14 by Brian Carpenter (diff)
Secdir Last Call review of -14 by Ben Laurie (diff)
Opsdir Last Call review of -14 by Tina Tsou (diff)
Assignment Reviewer Ben Laurie
State Completed
Review review-ietf-rtcweb-use-cases-and-requirements-14-secdir-lc-laurie-2014-05-22
Reviewed rev. 14 (document currently at 16)
Review result Has Nits
Review completed: 2014-05-22


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.

>From a security POV this document is mostly ready: it includes as
common requirements for all use-cases:

 F11     It must be possible to protect streams and data
           from wiretapping [RFC2804].


F13     The browser must encrypt, authenticate and
           integrity protect media and data on a
           per-packet basis, and must drop incoming media
           and data packets that fail the per-packet
           integrity check.  In addition, the browser
           must support a mechanism for cryptographically
           binding media and data security keys to the
           user identity (see R-ID-BINDING in [RFC5479]).

which are nice, _but_ it seems to me that, given that metadata
interception is now the norm, that there should be an additional
requirement that identity data should not be available to attackers
(i.e. that a GPA or a MitM should not be able to determine who the
end-points are from data transmitted in the stream).

I note that RFC 5479 also does not appear to include this requirement.

Also, F11 is perhaps a little weak in that it appears to only require
protection from a GPA, not from a MitM. RFC 5479 is a little unclear
on this point (it discusses active attackers but doesn't specifically
say protocols should defend against them).

Certificate Transparency is hiring! Let me know if you're interested.