Howdy, On Fri, Jul 10, 2015 at 1:57 AM, [email protected] <[email protected]> wrote:
> > *From:* Ted Hardie <[email protected]> > *Date:* 2015-07-10 02:04 > *To:* yaojk <[email protected]> > *CC:* dns-privacy <[email protected]> > *Subject:* Re: [dns-privacy] Fw: Fw: New Version Notification for > draft-zuo-dprive-encryption-over-udp-00.txt > On Wed, Jul 8, 2015 at 12:21 AM, Jiankang Yao <[email protected]> wrote: > >> >> >> It's also not clear to me, given that the stub public key is sent in the >> query to the recursive resolver how you avoid an attacker standing up a >> back-to-back user agent which strips that option, substitutes its own >> public key, gets the data and then passes it on. (It may be, of course, >> that this attack is out of scope). >> *[Jiankang Yao]* >> Yes, the attacker standing up a back-to-back user agent can strip that >> option, substitute its own public key, get the data and then pass it on. >> but I think that it should be no use because the attacker can not know >> the contents of the DNS packet send by the stub. >> > I think I wasn't clear enough about the attack. If the attacker strips > the option and sends it with its own public key, it can decrypt the > response. It can send its version in advance of sending the original > packet along, so it can see the response and potentially drop packets that > match some policy. (If they are acceptable, it just sends the queued > packet along). It can also be done along side the original packet, to > enable tracking without applying policy. That's mildly detectable, since > the recursive resolver would see multiple queries, but it would be pretty > easy to obfuscate by generating new client public keys and varying the > query interval. > > Does that make sense? > > [Peng Zuo] > > since the whole DNS query packet(except the DNS header) is encrypted by > the stub using the public key of the recursive resolver, the dns packet > structure becomes invisable to attackers, attackers could not locate the > additional section of the DNS query, so i think it would be difficult for > the attacker to substitute it with its own key. > > You may want to update section 2.2, then. I read its description of the RDATA option as being a separable segment, and other readers may be similarly confused. Thanks for the clarification, regards, Ted > regards, > > > ------------------------------ > [email protected] > > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
