I change my story a bit based on some offlist discussions ... So the point 1 from summary email changes like this 1- Opportunistic encryption is not appropriate for the privacy of stub resolver to recursive resolver scenario unless the node has a possibility to authenticate this resolver. If you think when your domain is signed by DNSSEC, a fake resolver cannot cause any problem for you, I gives you an example. You can argue with your own example.
This is the scenario where there is no authentication but a record is supposed to signed by a DNSSEC server. A domain called www.example.com signed by DNSSEC A. Client B wants to browse "www.example.com". It asks the IP address of this from resolver C. Attacker D spoof the IP address of resolver C and response to this query with the IP address of his own server F. The client cannot verify this attacker in any case since it is only a stub resolver and dependent to a recursive resolver for query different authoritative DNS server in order to verify this DNSSEC server. This is why the stub resolver accepts whatever receives from this fake DNSSEC server. So, either client B encrypt the queries send back and forth to the resolver, it ends to the case where the unwanted person can still eavesdrop this communication by directly answer to the node in place of resolver. In my opinion it does not matter whether this record is signed or encrypted, the stub resolver has no possibility to verify that record. So, an attacker can directly be in the middle of the communication and forward all the packets to his desire place. So DNSSEC in this stage or last mile does not help. > > How can you sign DNSSEC data without being in the posession of the > > private signing key(s) all the way to the root? So based on the revision in item 1. I can also revise my answer here. I don't need to sign the DNSSEC data since the stub resolver is dependent to me (or a DNSSEC recursive resolver) to verify any other DNSSEC server. Best, Hosnieh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
