Re: [alto] Benjamin Kaduk's and Eric Rescorla's Discusses on draft-ietf-alto-xdom-disc-04

[Benjamin Kaduk <[e-mail]>]

Hi Sebastian,

On Mon, Jan 28, 2019 at 10:28:20PM +0100, Sebastian Kiesel wrote:
> 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.

While that is sound advice, and we cannot realistically make stronger
mandates to use DNSSEC, I don't think it fully captures the extent of at
least my DISCUSS.  (Perhaps this falls into the "further issues" that will
be addressed separately?  Let me know if that's the case.)

In particular, I want to be sure that DNSSEC is available as a realistic
option in all possible ALTO deployments.  There are two prongs to this --
availability of DNSSEC in the reverse zone for private-use addresses (my
final DISCUSS point), and reliance on third parties for DNSSEC in the
reverse zone (my penultimate point).

To illustrate the latter with an example, at home, my residential ISP gives
me an IP address via DHCP.  My ISP does not give me an interface to adjust
the entries for my address in its reverse zone, and while my particular ISP
does appear to sign the reverse zone, can we guarantee that all such ISPs
will do so?  I do not have leverage against my ISP to make them offer me a
way to create NAPTR records for my assigned IP address (e.g., since I have
to use DHCP and am not contracted for a fixed IP allocation), so ALTO
cross-domain discovery would not be usable for me at home if I was running
a service that would merit it (which would, of course, be forbidden by my
terms of service anyway).  By publishing this document, we are in effect
making a claim that the availability both of DNSSEC for the reverse zone by
transit providers, and the availability of interfaces to allow insertion of
(NAPTR) records into the reverse zone by those same transit providers, is
sufficently well advanced that it will be usable for a large fraction of
the ALTO target audience.  It's not clear to me what grounds we have to
support such a claim, and that's what I'm trying to get at with my
penultimate DISCUSS point.  Part of this will depend on what exactly the
ALTO target audience is, of course, and consequently the ISPs they are
likely to be using.

Does that help clarify my thinking?

Thanks,

Benjamin

> 
> 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 -----