Re: [secdir] Secdir review of draft-ietf-radext-dtls-10

Alan DeKok <> Wed, 30 April 2014 15:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 159EE1A08E8; Wed, 30 Apr 2014 08:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1yrGZZyZj02h; Wed, 30 Apr 2014 08:47:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0CC6B1A08E2; Wed, 30 Apr 2014 08:47:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DF622240093; Wed, 30 Apr 2014 17:46:59 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tu34Yq8rxpyg; Wed, 30 Apr 2014 17:46:55 +0200 (CEST)
Received: from Thor.local (unknown []) by (Postfix) with ESMTPSA id 6F5DC2240048; Wed, 30 Apr 2014 17:46:55 +0200 (CEST)
Message-ID: <>
Date: Wed, 30 Apr 2014 11:46:54 -0400
From: Alan DeKok <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Brian Weis <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc:, The IESG <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Apr 2014 15:47:35 -0000

Brian Weis wrote:
> 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.
> This is a re-review; I last reviewed draft-ietf-radext-dtls-06. Reproducing my summary from that review: This document describes requirements and implementation details regarding using DTLS as a transport layer for RADIUS packets. It is a companion to RFC 6614 ("TLS Encryption for RADIUS"), and this I-D references many of the sections in that RFC rather than re-defining them. While the security considerations of encapsulating RADIUS in TLS and DTLS are very similar there are a number of operational issues where a UDP protocol is more advantageous than a TCP, and vice versa. Both documents are worth specifying; providing more secure alternatives to the simple RADIUS MD5 integrity checks is critical.
> The current draft addresses my earlier comments, and is much improved due to other changes as well. I believe is ready to publish.
> I noticed one nit in the "DTLS Data" definition (Section 5.1): s/variable which may information about/variable which may contain information about/.

  Fixed, thanks.