[secdir] secdir review of draft-ietf-dane-srv-12
Carl Wallace <carl@redhoundsoftware.com> Mon, 13 April 2015 17:43 UTC
Return-Path: <carl@redhoundsoftware.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 A411E1ACEAE for <secdir@ietfa.amsl.com>; Mon, 13 Apr 2015 10:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 6FpoQj8BcueY for <secdir@ietfa.amsl.com>; Mon, 13 Apr 2015 10:43:58 -0700 (PDT)
Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAC41AD0BB for <secdir@ietf.org>; Mon, 13 Apr 2015 10:43:58 -0700 (PDT)
Received: by qkx62 with SMTP id 62so191068502qkx.0 for <secdir@ietf.org>; Mon, 13 Apr 2015 10:43:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=HgY/euQOzAk5UatC4vhyegtuf3r/F+y+TdE+O34H6Fo=; b=QB0LPbbQKGEIW1joQgFi9ybBqx74apbYJ2NR0J9RnvkjmZgVrCwfV7OzFJW5VesATf C5hL/NhVVYhK6BsiuEi9MpbaRStjXt5WjC/n+whn+ILQdT3q1RNejB7VaTAPxT+DAESQ 7x+flWw0Ljf3niBQP6A79SOlK9A2lAsbpodtwnGiP8bUwEUqbhyHy4a3sQSsuJxc+7Vr O9cf+PUvHv3PNbgpDX5tn/2lmRFo9LO8eYcNh6upSSuJ+ZCBVzf6sG+mLkdbc+SDtkfX U3eW3OE88OtMIXBwMzHJ3JKHg5BB9mntJeC5FingmcMkzT65C+stgDsyMs/iheKdb9tr /OYg==
X-Gm-Message-State: ALoCoQm5elt749zpsDNNNXmkzhG1AHDqOk9bQtb4lZzIitIDKi8eBY9EBpmxqOn7/e1hrsyAIbUt
X-Received: by 10.229.214.199 with SMTP id hb7mr20285641qcb.12.1428947037034; Mon, 13 Apr 2015 10:43:57 -0700 (PDT)
Received: from [192.168.2.27] (pool-96-241-148-223.washdc.fios.verizon.net. [96.241.148.223]) by mx.google.com with ESMTPSA id n72sm6289424qha.19.2015.04.13.10.43.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:43:56 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.7.141117
Date: Mon, 13 Apr 2015 13:43:53 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: draft-ietf-dane-srv-12.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Message-ID: <D1517899.32B98%carl@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-dane-srv-12
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/WPnpYq4xPHiWqPyUm1Zq_MZmbQY>
Subject: [secdir] secdir review of draft-ietf-dane-srv-12
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: Mon, 13 Apr 2015 17:43:59 -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 document is basically ready. A few minor nits are below. The primary comment is that there are a few instances where abbreviated certificate checks are cited and potentially mask a need to do full certification path validation. Therefore this document provides guidelines that enable protocols that rely on SRV lookups to locate and use TLSA records. In section 1 - May be worth adding a note to the third bullet to clarify that multiple target endpoints may be defined for a given service domain, including a mix of endpoints that have and do not have TLSA records. - Should the "always use" in the third bullet be "MUST use"? - May be worth clarifying in the fifth bullet that no usable TLSA records for one target endpoint does not mean there are no usable TLSA records for another target endpoint. The security considerations address this point and the point in the first bullet above, but it seems worth reenforcing in the body as well. - Bullet 5 should reference RFC5280 alongside RFC6125 and/or reference "non-DANE behavior" a la section 3.1 (but using the target server hostname). In Section 4.2 - Should this reference RFC6698 section 2.1 or section 4? Section 4 seems like a better target to me. - Replace reference to "expiration checks from RFC5280" with "validation checks from RFC5280" unless you mean for some forms of 5280 checks to be honored here. Current wording could create a misimpression that only expiration checks need be performed. In section 10.2 - In the last sentence, clients must also validate the certificate back to the designated trust anchor, not just check the reference identifiers.
- [secdir] secdir review of draft-ietf-dane-srv-12 Carl Wallace
- Re: [secdir] FW: secdir review of draft-ietf-dane… Peter Saint-Andre - &yet
- Re: [secdir] FW: secdir review of draft-ietf-dane… ⌘ Matt Miller
- Re: [secdir] FW: secdir review of draft-ietf-dane… Peter Saint-Andre - &yet
- Re: [secdir] secdir review of draft-ietf-dane-srv… Carl Wallace
- Re: [secdir] secdir review of draft-ietf-dane-srv… Peter Saint-Andre - &yet