[alto] Benjamin Kaduk's and Eric Rescorla's Discusses on draft-ietf-alto-xdom-disc-04
Sebastian Kiesel <ietf-alto@skiesel.de> Mon, 28 January 2019 21:28 UTC
Return-Path: <ietf-alto@skiesel.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B802B13115A; Mon, 28 Jan 2019 13:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 y4_G_WiPbTQj; Mon, 28 Jan 2019 13:28:34 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2B2131157; Mon, 28 Jan 2019 13:28:34 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de ([2a02:a00:e000:116::41]:52400) by gw01.ehlo.wurstkaes.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ietf-alto@skiesel.de>) id 1goES9-0007Jn-Vu; Mon, 28 Jan 2019 22:28:26 +0100
Date: Mon, 28 Jan 2019 22:28:20 +0100
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: Benjamin Kaduk <kaduk@mit.edu>, Eric Rescorla <ekr@rtfm.com>
Cc: iesg@ietf.org, alto-chairs@ietf.org, draft-ietf-alto-xdom-disc@ietf.org, alto@ietf.org, jan.seedorf@hft-stuttgart.de, ietf@kuehlewind.net
Message-ID: <20190128212820.mgodgtjallw46b2n@gw01.ehlo.wurstkaes.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Organization: my personal mail account
Accept-Languages: en, de
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/idCLVHlQ7y-dokWHFu2qJ34_1_c>
Subject: [alto] Benjamin Kaduk's and Eric Rescorla's Discusses on draft-ietf-alto-xdom-disc-04
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jan 2019 21:28:37 -0000
Hi Benjamin and Eric, both of you have entered a Discuss on draft-ietf-alto-xdom-disc-04, because the current version of the document does not make usage of DNSSEC mandatory (and because of further issues, which we will address in separate mails, respectively). However, we (the authors) believe that the two positions are not completely aligned. After internal discussion and consultations with our AD we propose the following change regarding the use of DNSSEC (for a complete new version of sec. 6.1 please see at the end of this mail): All implementations of the cross- domain ALTO server discovery procedure MUST support DNSSEC or be able to use of such functionality in the underlying operating system. Network operators that publish U-NAPTR resource records to be used for the cross-domain ALTO server discovery procedure SHOULD use DNSSEC to protect their subdomains of in-addr.arpa. and/or ip6.arpa., respectively. Would that proposal address your concerns adequately? Thanks Sebastian ----- Begin proposal for new section 6.1 ----- 6.1. Integrity of the ALTO Server's URI Scenario Description An attacker could compromise the ALTO server discovery procedure or the underlying infrastructure in a way that ALTO clients would discover a "wrong" ALTO server URI. Threat Discussion The cross-domain ALTO server discovery procedure relies on a series of DNS lookups, in order to produce one or more URI(s). If an attacker was able to modify or spoof any of the DNS records, the resulting URI(s) could be replaced by forged URI(s). This is probably the most serious security concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all, or it might give suboptimal or forged information. In the latter case, an attacker could try to use ALTO to affect the traffic distribution in the network or the performance of applications (see also Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server could threaten user privacy (see also Section 5.2.1, case (5a) in [RFC6708]). Protection Strategies and Mechanisms The application of DNS security (DNSSEC) [RFC4033] provides a means to detect and avert attacks that rely on modification of the DNS records while in transit. All implementations of the cross- domain ALTO server discovery procedure MUST support DNSSEC or be able to use of such functionality in the underlying operating system. Network operators that publish U-NAPTR resource records to be used for the cross-domain ALTO server discovery procedure SHOULD use DNSSEC to protect their subdomains of in-addr.arpa. and/or ip6.arpa., respectively. Additional operational precautions for safely operating the DNS infrastructure are required in order to ensure that name servers do not sign forged (or otherwise "wrong") resource records. Security considerations specific to U-NAPTR are described in more detail in [RFC4848]. In addition to active protection mechanisms, users and network operators can monitor application performance and network traffic patterns for poor performance or abnormalities. If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random results, the usage of the ALTO server may be discontinued (see also Section 15.2 of [RFC7285]). Note The cross-domain ALTO server discovery procedure finishes successfully when it has discovered one or more URI(s). Once an ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply. A threat related to the one considered above is the impersonation of an ALTO server after its correct URI has been discovered. This threat and protection strategies are discussed in Section 15.1 of [RFC7285]. The ALTO protocol's primary mechanism for protecting integrity (and confidentiality) is the use of HTTPS-based transport, i.e., HTTP over TLS [RFC2818]. Typically, when the URI's host component is a host name, a further DNS lookup is needed to map it to an IP address, before the communication with the server can begin. This last DNS lookup (for A or AAAA resource records) does not necessarily have to be protected by DNSSEC, as the server identity checks specified in [RFC2818] are able to detect DNS spoofing or similar attacks, after the connection to the (possibly wrong) host has been established. However, this validation based on the server certificate can only protect the steps that occur after the server URI has been discovered. It cannot detect attacks against the authenticity of the U-NAPTR lookups needed for the cross-domain ALTO server discovery procedure, and therefore, these resource records have to be secured using DNSSEC. ----- End proposal for new section 6.1 -----
- [alto] Benjamin Kaduk's and Eric Rescorla's Discu… Sebastian Kiesel
- Re: [alto] Benjamin Kaduk's and Eric Rescorla's D… Benjamin Kaduk
- Re: [alto] Benjamin Kaduk's and Eric Rescorla's D… Sebastian Kiesel