Ballot for draft-ietf-alto-xdom-disc
Discuss
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Thank you for educating me :-) (previous position was discuss because I didn't understand the deployment scenario).
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.
I concur with Alissa's comment.
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.
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.
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/
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.