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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
