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

Jouni <jouni.nospam@gmail.com> Fri, 25 April 2014 18:05 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0F41A05C3; Fri, 25 Apr 2014 11:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 myixJ4eSlRNx; Fri, 25 Apr 2014 11:05:21 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B138D1A065B; Fri, 25 Apr 2014 11:05:20 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id u14so365803lbd.2 for <multiple recipients>; Fri, 25 Apr 2014 11:05:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZkuZtO2AJSgPhEhGiAIhf6vq80UnlX7eR/MQEfz1CKE=; b=o51qApMAlAlRqOh8zmvAqTQ5LXL3Chdcvk82CcaW3aH5Mo1r7EYLaR6Gb73jVBYqWW +UAD8lzvSakQQRoDajxFlauk7z40ahz00Vrcxk1JH7J//oXyBx+feCiD/nnW2R9Vf7Rw Fob2whj5qm+/Mlkdp1z1dMQl6lonBqfa6pe2G/sDGoFrd7GLKLLRmLu4U/kxhqfrO/5B 6Z5IhlFcBx4uhauwL4lkPKsW414IQq1iJL6Fte77mbtn1526v0szi+czKx8zlM083dGk HlruJ4qT7DMqZoGjPaj7b+8DLwKjwj894R1kYPYrHzb1kJg4IzFL3q8uqsyv5zR6PX8H 8jCQ==
X-Received: by 10.152.4.41 with SMTP id h9mr2217667lah.43.1398449113478; Fri, 25 Apr 2014 11:05:13 -0700 (PDT)
Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPSA id q4sm8859694lbh.20.2014.04.25.11.05.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 11:05:12 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <BA0624E2-BF90-4709-81F0-99FBD9015E20@cisco.com>
Date: Fri, 25 Apr 2014 21:05:11 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <008F4E44-C5D6-4E4F-B799-F179126F9745@gmail.com>
References: <BA0624E2-BF90-4709-81F0-99FBD9015E20@cisco.com>
To: Brian Weis <bew@cisco.com>
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ziEz8yzOyfuzlDrjSb0lqgiJElg
Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Fri, 25 Apr 2014 18:05:23 -0000

Thanks Brian. We'll take care of the nit your spotted.

- Jouni


On Apr 25, 2014, at 7:59 PM, 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/.
> 
> Brian