Re: [alto] Eric Rescorla's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)

[Sebastian Kiesel <[e-mail]>]

Hi Mirja, all,

On Fri, Jan 18, 2019 at 11:12:32AM +0100, Mirja Kuehlewind (IETF) wrote:
> Hi Sebastian,
>
> so to summarize I think what’s needed is some discussion about what
> can happen if DNSSEC is not used and maybe even a requirement that
> certain data MUST be integrity protected.
>
> I think that could also address Benjamin’s discuss. Can you maybe
> propose some new/additional text for the security consideration
> section and see if we can first address Ekr discuss and then start a
> conversation with Benjamin?

I think the discussion about what could happen without DNSSEC was
already pretty accurate, but I've reworked it a bit, see below.

The authenticity of the whole scheme indeed relies completely on DNSSEC.
So the real question is, which level of requiring DNSSEC is apropriate
and will address both Discusses.  My proposal is:

    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.


What do you think?

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