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

"Brian Weis (bew)" <> Sat, 21 October 2017 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C82D9134326; Fri, 20 Oct 2017 17:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KzozuOJ6XRhV; Fri, 20 Oct 2017 17:23:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 660E812ECEC; Fri, 20 Oct 2017 17:23:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12158; q=dns/txt; s=iport; t=1508545418; x=1509755018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=knGA335VQSnYQqwE2N2WAV9QXGFzI6vxrxwjEPQNLmU=; b=JuaHUDdlZQWLbcZ+kY9dm4PbjGJAn44keQkzfBPgq2JtL9Pn+3a0oq+O um16fZksuoDOxBQSuTW5SIeTlJUubvTS0B9DvKqhvAYYOwHvinFb0yhZ+ R06BL3tAerFRg4r5XKOKxkKyq2oB6/wUiuP5cg8fW4AfLXtfVkP2QNS1I Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAAHk+pZ/4wNJK1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDX2RuJweDc4ofj0CScIVBEIIBChgBCoUYAhqEIT8YAQIBAQE?= =?us-ascii?q?BAQEBayiFHgIBAwEBIUsLEAIBCA4CLwMCAgIlCxQRAgQOBYk8ZBCqf4IniyQBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMuggeDOSmDAYMygSABCAoBCS0KJoJNL4I?= =?us-ascii?q?yBaFfAodhjQ6CFZEKkmUsgjwCERkBgTgBHziBA1h6FUktAYI2hF92iBwNGAeBB?= =?us-ascii?q?YERAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,408,1503360000"; d="scan'208,217";a="313425614"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2017 00:23:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v9L0Nacw001795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 21 Oct 2017 00:23:36 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Oct 2017 20:23:35 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 20 Oct 2017 20:23:35 -0400
From: "Brian Weis (bew)" <>
To: Tommy Pauly <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05
Thread-Index: AQHTSe9lZB3LABs0BESiUtIkFPc68aLttO0A
Date: Sat, 21 Oct 2017 00:23:35 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_642F64175C014F95A0B0BEBA7A475D58ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Oct 2017 00:23:41 -0000

Hi Tommy,

Thanks for the background info. Your new text in the Security Considerations looks great to me, and I consider this document Ready to publish.


On Oct 20, 2017, at 3:04 PM, Tommy Pauly <<>> wrote:

Hello Brian,

Thanks for your review! We've just posted a new version of the draft that includes an extra section in the security considerations.

The references in RFC 6555 to Same-Origin Policy point to RFC 6454. That document actually only references that the policy gates schemes, hosts, and ports—not IP addresses directly. Relying on consistent IP address results from hostname resolution as a security property would be a problem that arises any time a new DNS query is made, so we believe that Happy Eyeballs does not actually expose any new concern here. Using TLS to validate the identity of a server, along with validation of the same host, port, and scheme, should avoid any concern with using different DNS results.

The comment I've added to the security considerations indicates that implementations should not assume that addresses will be consistent for a hostname as a security property, and that Happy Eyeballs may make it more likely in some scenarios that an address will change between connection attempts.


On Sep 28, 2017, at 9:15 AM, Brian Weis <<>> wrote:

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

v6ops mailing list<>

Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796