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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 18 Jan 2019 11:12:32 +0100

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?

Thanks!
Mirja

> Am 17.01.2019 um 14:42 schrieb Eric Rescorla <[email-masked]>:
> 
> 
> 
> On Wed, Jan 16, 2019 at 4:15 PM Sebastian Kiesel <[email-masked]> wrote:
> On Wed, Dec 19, 2018 at 12:49:22PM -0800, Eric Rescorla wrote:
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-alto-xdom-disc-04: Discuss
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > The security considerations for this document don't seem to be
> > adequate. In general, the security of this mechanism seems to rely on
> > DNSSEC, and yet it's not mandated.
> 
> While I definitively understand your concern, I am not sure whether
> you are implying a possible way forward.  Please clarify, does "and yet
> it's not mandated." mean that we should use a MUST [RFC2119] to tell
> network operators what to do (i.e., sign their in-addr.arpa. subdomain)?
> 
> The minimum obligation from 3552 is to document the security
> properties of your protocol adequately, given that you're not requiring
> DNSSEC (or even DoH). Given that you don't require this, the
> 3552 analysis needs to be undertaken under the the assumption
> that the attacker completely controls DNS and then work through
> the consequences.
> 
>  
> To my understanding, RFC2119 keywords are mainly used to ensure
> interoperability between implementations.
> 
> We routinely require that protocols have some sort of security mechanism
> or only run over secure transports,
> 
> 
> Using DNSSEC for the reverse zone seems like a very good idea at this
> point in time (and it can be done - see at the end of this mail), but
> given recent and onging developments such as DOH, is it wise to mandate
> one specific mechanism, when we are only very loosely coupled to it?
> 
> Well, DoH doesn't provide the same security properties as DNS and the
> integrity property is quite important here. But you're not requiring *any*
> form of DNS security.
> 
> 
> 
> > DETAIL
> > S 6.1.
> > >   
> > >         However, it should also be noted that, if an attacker was able to
> > >         compromise the DNS infrastructure used for cross-domain ALTO
> > >         server discovery, (s)he could also launch significantly more
> > >         serious other attacks (e.g., redirecting various application
> > >         protocols).
> > 
> > Hmm... Are there no settings in which ALTO servers give information
> > that isn't something that is a subset of info in DNS? This seems like
> > it needs more analysis.
> 
> ALTO servers will definitively give information beyond what we could put
> in the DNS - otherwise we wouldn't need the ALTO protocol [RFC 7285].
> Typical information could be processed information extracted from
> routing tables, indicating the topological distances or "routing costs"
> between any pairs of IP addresses.
> 
> Scenarios and risks related to unintended information disclosure through
> ALTO have been discussed in detail in Section 5.2 of RFC 6708 (both
> from the point of view of the publisher and the client sending queries).
> Possible consequences of and mitigation strategies for wrong (forged)
> ALTO information are discussed in Sections 15.1 and 15.2 of RFC 7285.
> 
> What this paragraph above wants to say is that an attack against the
> integrity of the DNS could make these risks become a reality. 
> However, the consequences described in the above-mentioned sections seem in
> general - without knowing and analyzing the exact deployment 
> scenario - rather limited and manageable compared to other risks that
> may occur if we cannot trust integrity protection in our DNS
> infrastructure.
> 
> 
> > S 6.1.
> > >         certificate will contain the host name (CN).  Consequently, only
> > >         the host part of the HTTPS URI will be authenticated, i.e., the
> > >         result of the ALTO server discovery procedure.  The DNS/U-NAPTR
> > >         based mapping within the cross-domain ALTO server discovery
> > >         procedure needs to be secured as described above, e.g., by using
> > >         DNSSEC.
> > 
> > This is not an acceptable description of how to use TLS. Given that
> > you are using HTTPS, you need to cite 2818. And as this is a new
> > application of HTTPS, you should be specifying modern TLS, i.e.,
> > mimimum 1.2 and 7525.
> 
> The XDOM discovery procedure itself does NOT use HTTPS/TLS. 
> 
> It's part of a system which does and you're describing the overall properties of that system.
> 
> I can live without the citation to 7525, but even as a descriptive matter, talking just about the CN is not a correct description of how HTTPS validation works.
> 
> 
> 
> > S 6.4.
> > >         statement [RFC5693] and/or discussed in the ALTO working group,
> > >         this scenario has not been identified as a relevant threat.
> > >   
> > >      Protection Strategies and Mechanisms
> > >         No protection mechanisms for this scenario have been provided, as
> > >         it has not been identified as a relevant threat.  However, if a
> > 
> > Another threat here is the disclosure of the exact query you are
> > making to the ALTO server. An attacker might be interested in that,
> > and it's not all manifest in the DNS query.
> 
> Protecting the exact query, after all an HTTP POST, is mainly covered in
> RFC 7285.  XDOM disc just needs to make sure that an attacker cannot
> redirect a client to the URI of a malicious ALTO server and do a MITM
> attack even with TLS in place.
> 
> Which as far as I can tell, it does not do.
> 
> 
> > S 2.
> > >      The discovery procedure sequentially tries two different lookup
> > >      strategies: First, an ALTO-specific U-NAPTR record is searched in the
> > >      "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
> > >      corresponding to the given IP address or prefix.  If this lookup does
> > >      not yield a usable result, the procedure tries further lookups with
> > >      truncated domain names, which correspond to shorter prefix lengths.
> > 
> > Seems like wildcards could get a lot of this, no?
> 
> sorry, I am not sure whether I understand this comment correctly.
> Could you please be a bit more verbose here?
> 
> Instead of having this complicated fallback system, it seems like you could correctly
> respond to most of these queries by having wildcards. This is just a comment.
> 
>  
> > S 3.4.
> > >      | IPv4       |        32  |  R32       | R24, R16, R8               |
> > >      | IPv4       |  24 ... 31  |  R24       | R16, R8                    |
> > >      | IPv4       |  16 ... 23  |  R16       | R8                         |
> > >      | IPv4       |   8 .. 15  |   R8       | (none)                     |
> > >      | IPv4       |   0 ..  7  | (none, abort: invalid prefix length L)  |
> > >      +------------+------------+------------+----------------------------+
> > 
> > I'm trying to work out how this works. Say that AT=IPv4 and L=27, so
> > we have like ff.ff.ff.ff/28 (I know this is illegal, but it saves me
> > on math). My first look up should be: 240.255.255.255.in-addr.arpa,
> > and then my next one should be 255.255.255.in-addr.arpa? Is that
> > correct?
> > 
> > Where does the text say that I should zero the low-order bits in R32?
> 
> you will match /28 against the second column of the table and conclude
> that the second row applies. Consequently, you MUST lookup R24 first and
> then SHOULD try R16 and R8 until success.
> 
> in your example, R24 is 255.255.255.in-addr.arpa so it doesn't matter
> whether or not you zero the 4 least significant bits first, they get
> cut off anyway.
> 
> All right.
> 
> 
> > S 3.4.
> > >      | IPv6       | 64 (..127) |  R64       | R56, R48, R32              |
> > >      | IPv6       |  56 ... 63  |  R56       | R48, R32                   |
> > >      | IPv6       |  48 ... 55  |  R48       | R32                        |
> > >      | IPv6       |  32 ... 47  |  R32       | (none)                     |
> > >      | IPv6       |   0 .. 31  | (none, abort: invalid prefix length L)  |
> > >      +------------+------------+------------+----------------------------+
> > 
> > What's the reasoning for this pattern?
> 
> The number of truncate-then-try-lookup steps is a compromise between
> flexibility for those who want to install such NAPTR RRs
> and not causing excess load on the DNS in particular if no such NAPTR
> RRs are present.
> 
> In the IPv4 case, an upper bound of 4 steps seems straightforward and
> natural, due to the dotted quad notation.  We decided to use a similar
> number (5) of steps also for IPv6. Maybe, one more step, for /40 would
> make sense, so all steps truncate the same number of bits, but not
> significantly more steps.  By no means does this scheme mean that we
> assume or encourage address allocations following only these bit
> boundaries!
> 
> btw: the same 5 lookup steps for IPv6 are specified in RFC 7216, which
> has inspired our procedure.
> 
> What I'm asking for is to document the reasoning in this specification.
> 
> 
> > S 5.1.1.
> > >      mechanisms such as STUN [RFC5389] would be needed and considerations
> > >      for UNSAF [RFC3424] apply.  Therefore, using the procedures specified
> > >      in this document for resource consumer based ALTO server discovery is
> > >      generally NOT RECOMMENDED.  Note that a less versatile yet simpler
> > >      approach for resource consumer initiated ALTO server discovery is
> > >      specified in [RFC7286].
> > 
> > Why can't people do STUN?
> 
> Technically it would be possible, with some fine print about topology
> awareness in scenarios with cascaded NATs etc.  We don't need it for our
> scenarios. I forgot who talked us into citing RFC3424 quite some time
> ago. For the sake of a more generally applicable procedure (see above)
> we can remove the "NOT RECOMMENDED", if this is considered a good idea.
> 
> My point is that we regularly use STUN for things, so saying that you can't do X because it would require STUN is not a strong argument.
> 
> -Ekr
> 
> 
> ----------------------------------------------------------------------
> 
> example: R24 = 3.69.129.in-addr.arpa.
> 
> dig -t ANY 3.69.129.in-addr.arpa.
> 
> ; <<>> DiG 9.10.3-P4-Debian <<>> -t ANY 3.69.129.in-addr.arpa.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59261
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;3.69.129.in-addr.arpa.         IN      ANY
> 
> ;; ANSWER SECTION:
> 3.69.129.in-addr.arpa.  600     IN      RRSIG   NAPTR 10 5 600 20190120142147 20190110132147 36896 69.129..in-addr.arpa. PjbZQVxia87jSlAn+kpKtYlqYBKZ1DOightrZf6ZmeHRvznJM6vPrInY zoBm1iEoi03JnTgAfhHs1hl0JLRDjD+xJRzDKn82PJVoUVV9m9H1HBbw RWkQgxB/xLmUMAlaVO6/URbOEKnfIYtXz5WsvT5I2udk2STWmJu/Vdoa mUP3SB5kvsAGkw6hwfPmc9M5NWAKeL49pPoaNFtA9KDlOIYmTXQ3OjCU pXhFgiNAx3hjgUFtk1fTo6iHaAYLROsMGnZjcBR/jW+NWRLhqKPuwUzf fMY7AvLSm7SiLyaKCPBjGJ2tO3iKWDNmvd3BK+TFbavLI3kDTcLydIq/ K2PFnDI1e0sW98pPKMy9epvpghy/h3gR8058DNpw5iU5xLbK72/5gf2D Tlt3oBqLm2t+T+2TzyVXByR4ZQQHuK2GearDZJqeXbCrznczVURPvWLU OOmCj67mlv/BicW7ToAvozv9OTs+j68eZbQHnPnTtDdUpD5bciwRhBBW r9FZgwqBLB7X82aZ4Pp6tqeSiqkZiWRZIIe3pFhGusOsI27UHH3VwRnp iUuYfVjyC5j75qd7zuf/azOEWMbdaVXFpwu7c0zAKWMx0Cl1sMM/+sj8 awpoG5zrLqkAu0hbj8huB0eZKIdC3p5G6+Bz4LAaDDpv0+Orvl1Up4SU buUfoOmjGpo=
> 3.69.129.in-addr.arpa.  600     IN      NAPTR   100 10 "u" "ALTO:https" "!.*!https://nks-devel3.rus.uni-stuttgart.de/alto/ird!" \"\".
> 
> ;; Query time: 439 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Jan 17 00:39:58 CET 2019
> ;; MSG SIZE  rcvd: 700
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 28 Jan 2019 00:09:36 +0100

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 28 Jan 2019 10:11:08 +0100

Hi Sebastian,

thanks! I think that’s the right thing to do. Can you check with Benjamin and Ekr if that is a way forward (eventually starting a new thread with both of them). If we can’t come to a conclusion (soonish), I can schedule that as a discussion on an informal telechat.

Mirja

> Am 28.01.2019 um 00:09 schrieb Sebastian Kiesel <[email-masked]>:
> 
> Hi Mirja, all,
>