Skip to main content

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

Discuss


Yes

(Mirja Kühlewind)

No Objection

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

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

Warren Kumari
(was Discuss) No Objection
Comment (2018-12-19 for -04) Sent for earlier
Thank you for educating me :-) 
(previous position was discuss because I didn't understand the deployment scenario).
Eric Rescorla Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2018-12-19 for -04) Sent
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 IESG member
Yes
Yes (for -04) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2018-12-05 for -04) Not sent
I concur with Alissa's comment.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2018-12-05 for -04) Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Ben Campbell Former IESG member
No Objection
No Objection (2018-12-05 for -04) Sent
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 IESG member
(was Discuss) No Objection
No Objection (2019-07-17 for -05) Sent
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 IESG member
No Objection
No Objection (for -04) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2018-12-05 for -04) Sent
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 IESG member
(was Discuss) No Objection
No Objection (for -05) Sent for earlier

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -04) Not sent