Re: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt

[Ted Hardie <[e-mail]>]

On Wed, Jul 8, 2015 at 12:21 AM, Jiankang Yao <[e-mail]> 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?

regards,

Ted