[secdir] secdir review of draft-ietf-nsis-ntlp-sctp-12.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 01 June 2010 02:00 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 519F13A6909 for <secdir@core3.amsl.com>; Mon, 31 May 2010 19:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id sob6qgyLMYDx for <secdir@core3.amsl.com>; Mon, 31 May 2010 19:00:37 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU []) by core3.amsl.com (Postfix) with ESMTP id 528863A67C1 for <secdir@ietf.org>; Mon, 31 May 2010 19:00:36 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu []) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5120OhJ025575 for <secdir@ietf.org>; Mon, 31 May 2010 22:00:24 -0400
Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU []) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5120MV3025567 for <secdir@PCH.mit.edu>; Mon, 31 May 2010 22:00:22 -0400
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU []) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5120Dx1025568 for <secdir@mit.edu>; Mon, 31 May 2010 22:00:22 -0400
X-AuditID: 1209190f-b7b20ae000003f85-9e-4c0469b66b2b
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU []) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 7A.2F.16261.6B9640C4; Mon, 31 May 2010 22:00:22 -0400 (EDT)
Received: from [] (SIRIUS.FAC.CS.CMU.EDU []) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o51209LX008145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 May 2010 22:00:18 -0400 (EDT)
Date: Mon, 31 May 2010 22:00:09 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: iesg@ietf.org, secdir@mit.edu, draft-ietf-nsis-ntlp-sctp.all@tools.ietf.org
Message-ID: <B22403434BA05CE0B3855207@atlantis.pc.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on
X-Brightmail-Tracker: AAAAAA==
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] secdir review of draft-ietf-nsis-ntlp-sctp-12.txt
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 01 Jun 2010 02:00:38 -0000

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 General Internet Signaling Transport (GIST) protocol, as defined in
draft-ietf-nsis-ntlp-20.txt, provides for flexibility in selection of
transport and lower-layer security protocols, but initially specifies
only TCP and TLS-over-TCP.  The present document extends GIST by adding
support for SCTP and DTLS-over-SCTP.

The security considerations section is quite short, incorporating by
reference the security considerations of GIST, SCTP, and DTLS.  This
seems entirely reasonable, with the exception of the specific points
mentioned below, which I'd like to see addressed directly.

It is noted in multiple places that replay protection is not available
when using DTLS over SCTP, with no further explanation other than a
reference to draft-ietf-tsvwg-dtls-for-sctp (which itself says that the
feature MUST NOT be used, but gives no explanation).  In particular,
there is no discussion as to what implications this has for GIST or for
higher-layer protocols in the NSIS stack.

Section 8 says DTLS support MUST be implemented, presumably by anything
complying with the present document and thus anything which supports
GIST over SCTP.  It then goes on to say that an implementation of GIST
over SCTP without PR-SCTP (and thus, where there is no change that
individual TLS records will be dropped from the middle of the stream due
to differing timeouts) MAY use TLS instead of DTLS.  That is, it permits
GIST-over-TLS-over-SCTP instead of GIST-over-DTLS-over-SCTP when the
latter is not available (provided PR-SCTP is not used).  Why would this
ever be necessary?  If DTLS is mandatory-to-implement, in what scenario
would TLS be available but not DTLS?

secdir mailing list