Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
draft-ietf-alto-xdom-disc-06

Note: This ballot was opened for revision 04 and is now closed.

(Eric Rescorla) Discuss

Discuss (2018-12-19 for -04)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3649


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.

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.


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.


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.
Comment (2018-12-19 for -04)
S 2.
>   
>      The service parameter SHOULD always be set to "ALTO:https".  However,
>      other parameter values MAY be used in some scenarios, e.g.,
>      "ALTO:http" to search for a server that supports unencrypted
>      transmission for debugging purposes, or other application protocol or
>      service tags if applicable.

What would be applicable here?


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?


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?




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?


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?

(Mirja Kühlewind) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-12-05 for -04)
Thanks for a very readable draft, especially given the that we are talking about naptr stuff :-)

I agree with Alissa's comment.

§2, 4th paragraph: "The service parameter SHOULD always be set to "ALTO:https"."
That SHOULD is redundant to the similar requirement in §3.1. Since that section describe the detailed procedures, I suggest leaving the normative keywords to it, and using descriptive language here.

Alissa Cooper No Objection

Comment (2018-12-05 for -04)
Section 6.4: It seems that people's understanding of the kind of threat described in this section has changed somewhat since 2009 when RFC 5693 was published. For example, work to provide confidentiality protection for DNS client requests to recursive resolvers (DoT and DoH) has occurred in the time since then, and the information revealed by such requests is arguably less sensitive than the information sent by ALTO clients. I don't know if the applicability of DoT/DoH to NAPTR has been written about anywhere, but at a minimum it seems that this is worthy of some discussion here.

(Spencer Dawkins) No Objection

Comment (2018-12-05 for -04)
In this text, 

   One such scenario is detailed in
   Appendix C.

there are several scenarios in Appendix C. I THINK you may want me to look at Appendix C.3, which is an example, which is fine, but whether that's what you want me to look at or not, it would be useful to point more specifically at what you're thinking about.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-07-17 for -05)
Thank you for the updates; they have captured enough of the discussion we had
to clarify that most of my points of concern are either non-concerns or have
adequate workarounds.

I'm still not entirely sure that DNSSEC in the reverse zone is available everywhere
in a robust fashion, but it seems that there is enough availability that the mechanisms
specified here can still be used in a useful manner.

However, I do think that we need to clarify in Section 5.2.2 that this mechanism is
compatible with the BCP 20 sub-allocation scheme only insamuch as you can add
NAPTR records in the relevant locations -- the current procedures described in the
text will not catch everything just on their own, IIUC.

Also, one nit in Section 2: s/is usually always be set/is usually set/

(Suresh Krishnan) (was Discuss) No Objection

Warren Kumari (was Discuss) No Objection

Comment (2018-12-19 for -04)
No email
send info
Thank you for educating me :-) 
(previous position was discuss because I didn't understand the deployment scenario).

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2018-12-05 for -04)
No email
send info
I concur with Alissa's comment.

Martin Vigoureux No Objection