[v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05

Brian Weis <bew@cisco.com> Thu, 28 September 2017 16:15 UTC

Return-Path: <bew@cisco.com>
X-Original-To: v6ops@ietf.org
Delivered-To: v6ops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C919134228; Thu, 28 Sep 2017 09:15:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Weis <bew@cisco.com>
To: <secdir@ietf.org>
Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-rfc6555bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150661534403.27693.10060826661300587258@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 09:15:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/n91b8N41MuluxmS86tjcIk02Nr4>
Subject: [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 16:15:44 -0000

Reviewer: Brian Weis
Review result: Has Nits

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

>From the Introduction, "This document expands on "Happy Eyeballs" [RFC6555], a
technique of reducing user-visible delays on dual-stack hosts." It lists a set
of steps by which a client can asynchronously perform IPv6 and IPv4 DNS
queries, and also semantics on how to handle the replies such that the user
delay is minimized.

The Security Considerations section simply states "This memo has no direct
security considerations.", and I believe this is true. However, I wonder about
"indirect" security considerations. RFC 6555 warns several times against
breaking a browser's same-origin policy, which seems to me to be an "indirect"
security consideration. I realize that browser policies have changed
considerably since RFC 6555 was published, and I personally do not know if
same-origin is still in general use or whether there are other newer but
similar issues of which an implementor should be aware. But if there are, then
this section should note them. Otherwise, I consider the document ready to be