Hello Hosnieh, Hosnieh Rafiee writes:
> 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. > As the draft mentioned the stub-resolver cannot rely on the DNSSEC validation of an un-authenticated, unknown DNS resolver. Either the stub-resolver, or the application, needs to do the DNSSEC validation. While not widely deployed, this is possible today. For this local validation, the stub-resolver or the application has one or more DNSSEC "well-known" trust-anchors (like the DNS root zone trust anchor, or the ".de" zone trust anchor) pre-configured. The validation does not rely on the any data received via the unautenticated DNS resolver. The integrety of DNSSEC signed DNS zone data can always be checked. A malicious unauthenticated and unknown DNS resolver can stop all communication by providing false DNS data, but the false data is always detected. DNSSEC validation does not rely on the the data received through the DNS resolver, which might be malicious. The trust anchor is configured before this communication, out-of-band, coming with the software or manually configured. -- Carsten -- Sent with my mu4e _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
