Skip to main content

Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
RFC 8686

Discuss


Yes

(Mirja Kühlewind)

No Objection

Alvaro Retana
(Alexey Melnikov)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)

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

Alvaro Retana No Objection

Warren Kumari (was Discuss) No Objection

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

(Eric Rescorla; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (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.

(Mirja Kühlewind; former steering group member) Yes

Yes (for -04)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2018-12-05 for -04)
I concur with Alissa's comment.

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -04)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (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.

(Ben Campbell; former steering group member) No Objection

No Objection (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.

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (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/

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -04)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -04)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (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.

(Suresh Krishnan; former steering group member) (was Discuss) No Objection

No Objection (for -05)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -04)