Subject: Seciton 5 resolution (Sec Concerns)
Incomplete, but gives the jist... Section 5: Significant portions of this specification deal directly with security properties, and shall not be summarized again here. Rather, general properties of security practices and know risks in resolution protocols are well documented in many other specifications. DNS Spoofing As this system is dependant on the DNS, one can not be sure that the information one get back from DNS, and subsequently, the XRI resolution response, is no more secure than original DNS query. To solve that, the use of DNSSEC [DNSSEC] for securing and verifying zones is to be recommended, and the use of trusted resolution as defined in this specification or server authenticated HTTPS should be considered, when unambiguous and authoritative responses are paramount. [aren't they always] HTTP Security Much of the security considerations set forth in HTTP/1.1 [RFC2616] apply to XRI Resolution protocols defined here. Special consideration should be given proxy and caching behaviours to ensure accurate and reliable responses from resolution requests. In particular, network topologies increasingly have transparent proxies, for various reasons, some of which may insert VIA and other headers as a consequence, or may even cache content without reguard to poper caching policies set for by the HTTP authority for a resource. Caching Authorities In addition to traditional HTTP chacing proxies, XRI resolution authority proxies may exist in the resolution topology. these entities are especially instructed to take precautions against cache poisoning (as decribed in [RFC....]), as these caching entities may represent trust decision points within a deployments resolution architecture. LookAhead and Proxy Resolution - special trust considerations for in-network resolvers Well-Know locations - secure distribution of community root keys and authority URI's (perhaps trusted XRID?) - DDOS SAML Considerations References [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.