[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.