Telechat Review of draft-ietf-rtcweb-alpn-03
review-ietf-rtcweb-alpn-03-secdir-telechat-kaduk-2016-04-28-00

Request Review of draft-ietf-rtcweb-alpn
Requested rev. no specific revision (document currently at 04)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2016-05-03
Requested 2016-04-07
Authors Martin Thomson
Draft last updated 2016-04-28
Completed reviews Genart Last Call review of -03 by Russ Housley (diff)
Secdir Telechat review of -03 by Benjamin Kaduk (diff)
Opsdir Last Call review of -03 by Carlos Pignataro (diff)
Assignment Reviewer Benjamin Kaduk 
State Completed
Review review-ietf-rtcweb-alpn-03-secdir-telechat-kaduk-2016-04-28
Reviewed rev. 03 (document currently at 04)
Review result Ready
Review completed: 2016-04-28

Review
review-ietf-rtcweb-alpn-03-secdir-telechat-kaduk-2016-04-28

[My apologies to those receiving this twice; I do not know why typing
draft names seems to be so hard.]

Hi all,

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.

I think this document is ready.

The main goal is to provide an authenticated indicator to the webrtc peers
that confidentiality is needed for the "media" (video, audio) streams of
that webrtc session (or that it is not needed); ALPN, which is bound to
the DTLS handshake, is used to do so.

The only potentially interesting direct consequence that I see is that
this constrains any other (future) usage of ALPN by webrtc, since only one
ALPN label can be selected for a given DTLS association.  Should a need
arise, presumably additional ALPN labels can be defined that describe the
appropriate combination of confidentiality and any future protocol needs.

This document is not intended to cover the details of how the actual
webrtc sessions are established and cryptographically protected (if
necessary), so there does not seem to be a need for it to discuss the
security considerations relevant to those parts of the protocol.

-Ben

_______________________________________________
secdir mailing list
secdir at ietf.org


https://www.ietf.org/mailman/listinfo/secdir


wiki: 

http://tools.ietf.org/area/sec/trac/wiki/SecDirReview