[secdir] secdir review of draft-ietf-rtcweb-alpn-03

Benjamin Kaduk <kaduk@MIT.EDU> Thu, 21 April 2016 21:22 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75A612E6BC; Thu, 21 Apr 2016 14:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.197
X-Spam-Level:
X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l8JjiBaWra8; Thu, 21 Apr 2016 14:22:52 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC3A12E21C; Thu, 21 Apr 2016 14:22:51 -0700 (PDT)
X-AuditID: 1209190d-fefff700000076cb-de-571944aadde2
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 1F.7A.30411.AA449175; Thu, 21 Apr 2016 17:22:50 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u3LLMne0030945; Thu, 21 Apr 2016 17:22:50 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3LLMkIC010563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Apr 2016 17:22:49 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3LLMknN018153; Thu, 21 Apr 2016 17:22:46 -0400 (EDT)
Date: Thu, 21 Apr 2016 17:22:45 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-apln.all@ietf.org
Message-ID: <alpine.GSO.1.10.1604211713390.26829@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixCmqrLvKRTLcYNETCYsH836zWcz4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4Mq4OpOlYBpXxZG24+wNjAs5uhg5OSQETCR2 Hz3G1sXIxSEk0MYkcf/DCXYIZyOjRPPctSwQziEmia1LuxkhnAZGif2zJrCC9LMIaEtcXbYP zGYTUJGY+WYjG4gtIuAu8e/pKhYQW1jAWOLD17tMIDavgKPE/e5rYLaogI7E6v1TWCDighIn Zz4Bs5kFtCSWT9/GMoGRdxaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0 UlNKNzGCQ0mSdwfjv7tehxgFOBiVeHg55CXChVgTy4orcw8xSnIwKYnyrlWUDBfiS8pPqcxI LM6ILyrNSS0+xCjBwawkwjvPCSjHm5JYWZValA+TkuZgURLnjbl5NExIID2xJDU7NbUgtQgm K8PBoSTBm+8M1ChYlJqeWpGWmVOCkGbi4AQZzgM0vBakhre4IDG3ODMdIn+KUVFKnPc9yFYB kERGaR5cLzjWdzOpvmIUB3pFmDcRpJ0HmCbgul8BDWYCGsx/VxRkcEkiQkqqgfExb5bLpDlr Nb/eiXnAFfqSM+FGzJW7Nj5qnwq+bdiQU13Jtdk7tsY5tPrcm4d6ufrK+rsTJkif+3zCovLC 6hDm7WYytpeUHvYEpZ/a8dE0ZNU0p6US3eVZ3SIP+q6Lzjnx6ZB1jf0fxnLZyeKz2xTmHbqU 5HpYL/d1xQI13aPcB37kVezx6lFiKc5INNRiLipOBACHVLE50AIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/bNUz30HFH9MSN5VvNXvmXROcDBQ>
Subject: [secdir] secdir review of draft-ietf-rtcweb-alpn-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2016 21:22:58 -0000

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