On Wed, 25 Mar 2015, Viktor Dukhovni wrote:
Finally, what I think is the biggest issue:--- IPSEC and forward DNS [ The below was explained to me by Paul Wouters in London, thanks Paul. Any mistakes in the below are mine, so if I've got the wrong end of the stick, that's not Paul's fault. ] Creating IPSEC security associations based on forward DNS names is rather problematic. There is no discussion of the associated issues. Suppose we have: ns1.saint.example. IN A 192.0.2.1 _53.saint.example. IN IPSECA 0 1 1 <saintly-digest> serving the saint.example domain. Clients secure their connections to this nameserver by creating an IPSEC association with 192.0.2.1 using the given key material. Along comes: ns1.evil.example. IN A 192.0.2.1 _53.evil.example. IN IPSECA 3 1 1 <evil-digest> publishing the same IP address as a nameserver for his own evil.example domain. Now clients create a replacement IPSEC tunnel to 192.0.2.1 (there can only be one) and suddenly evil.example is free to intercept saint.example's traffic.
Actually, you cannot intercept the traffic. Assuming the real IKE daemon on 192.0.2.1 is configured with the "saint key", the client will see that the server fails authentication. But this does provide a denial of service against both the client and the saint server. And if the client would fail to clear based on evil.example, than it could potentially cause all saint traffic to end up in the clear as wel. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
