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

Tommy Pauly <> Fri, 20 October 2017 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56F9D13445F for <>; Fri, 20 Oct 2017 15:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dGtTwD2BWqFq for <>; Fri, 20 Oct 2017 15:04:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74E79133055 for <>; Fri, 20 Oct 2017 15:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1508537063; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ct7EQtLelpiIkfite9iMEYLWo7+VC7nwdk2p8cqYQrs=; b=N9RFvV89awKGMB/rODQIPu7rg43YwqvmAc5mEEveCCo/blUgfmC0n4IIxFqJqGx4 N3mbCUfMAREqdcv2PBKFGhr+/nhqb1nAAbny38lMcxO7xPVNnmWg+sAV0wQl0lv7 B39wpAX1gnB9a/w6pRxsNS9uclWK0m1ZRaf44dy5AQeldGgdUR7Wu8BB/21j2MZb dZS9QSyPS8FmoNnMty7Y3oag7D6fZEalNrQv6iJ1OSrFcl5vC9/I+ZbqFfwQeewG QacV3NRxgeGbms2UXTvPT6GHoB2wtK+Z8ZtTeDZWLjl0npys6l9gXom9lnhMFhJA uYgBmj4QHQoKmodI6Ti5gQ==;
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Apple Secure Mail Relay) with SMTP id B4.A3.23776.7E27AE95; Fri, 20 Oct 2017 15:04:23 -0700 (PDT)
X-AuditID: 11973e15-3421e9c000005ce0-36-59ea72e77cef
Received: from ( []) by (Apple SCV relay) with SMTP id 43.F8.31187.7E27AE95; Fri, 20 Oct 2017 15:04:23 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_HrV5ZiY671tfC16Z/oJ3uw)"
Received: from [] by (Oracle Communications Messaging Server 64bit (built Aug 25 2017)) with ESMTPSA id <>; Fri, 20 Oct 2017 15:04:23 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Date: Fri, 20 Oct 2017 15:04:21 -0700
In-reply-to: <>
To: Brian Weis <>
References: <>
X-Mailer: Apple Mail (2.3445.5.5)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FAYrvu86FWkwZILvBZ9bxtZLXYsuMts 8WzjfBaLDwsfslicPraX2YHVY8rvjaweS5b8ZApgiuKySUnNySxLLdK3S+DKuHXwE2PBUduK HZfbGRsYt5h0MXJySAiYSOw4+ZgRxBYSWM0kcfWYURcjB1h8YmcIRPggo0TLej0Qm1dAUOLH 5HssIDazQJjE2ZeL2CBqvjBK3P9aDNIqLCAhsXlPIkiYTUBF4vi3DcwQrTYSv3dOAWsVFvCT 6O1tBNvKIqAqsf/VERaQVk4BV4mpl6ohpsdJPPjUBdYqIiAnMe/3BVaITS4SLz88ZIQ4XlHi 4aYuoDgXkL2CTWLq+c2MExiFZiG5dBaSS2cBrWAWUJeYMiUXIqwt8eTdBVYIW01i4e9FTMji CxjZVjEK5SZm5uhm5pnpJRYU5KTqJefnbmIExcd0O9EdjGdWWR1iFOBgVOLhrRB7FSnEmlhW XJl7iFGag0VJnLc3BygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcdaUmZczeHYsi+1nLw1I Wvd/sWT5gvv+YZvnP//+ZIv91oL0aDVd+eS3N/t5xc5zJ89NiguzF7XZdH8r/3KO3MLfC2OW zOKwtuaauOuFcJvlir5nSg2P+s74rL/GGlPNUfzguWOd7f13/41uVHyS3FBYPvfBNoVVL+Km VHXoLYu4Hjvz1pxL3kosxRmJhlrMRcWJAIGsCDZwAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAcoPu86FWkweY/nBZ9bxtZLXYsuMts 8WzjfBaLDwsfslicPraX2YHVY8rvjaweS5b8ZApgiuKySUnNySxLLdK3S+DKuHXwE2PBUduK HZfbGRsYt5h0MXJwSAiYSEzsDOli5OQQEjjIKNGyXg/E5hUQlPgx+R4LiM0sECZx9uUiNoia L4wS978Wg7QKC0hIbN6TCBJmE1CROP5tAzNEq43E751TwFqFBfwkensbGUFsFgFVif2vjrCA tHIKuEpMvVQNMT1O4sGnLrBWEQE5iXm/L7BCbHKRePnhIVirhICixMNNXawTGPlnITluFpLj ZgFNZRZQl5gyJRcirC3x5N0FVghbTWLh70VMyOILGNlWMQoUpeYkVproJRYU5KTqJefnbmIE B3Rh+A7Gf8usDjEKcDAq8fBekHgVKcSaWFZcmXuIUYKDWUmE92EhUIg3JbGyKrUoP76oNCe1 +BCjNAeLkjjvjjtPIoUE0hNLUrNTUwtSi2CyTBycUg2M7gc+KL5tsT4rKMgtxyItq9UqpXxa cPPzvS+lZ61S+Lf7fWzeFT8715OvLNz+GLTtuPE++2xAxMVdugVc73P3z7275//F7R/XiejN K+mbIOt6P8RRatmU2bxnNzG8qXPZlecSf89nXoVej1ObGePFwM64s0e7bYr7p8u+Nn/zJdTp Qd63lLY0JZbijERDLeai4kQAeHZdcmQCAAA=
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: Fri, 20 Oct 2017 22:04:27 -0000

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
> comments.
>> 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
> published.
> _______________________________________________
> v6ops mailing list