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

[Ted Hardie <[e-mail]>]

Howdy,

On Fri, Jul 10, 2015 at 1:57 AM, [e-mail] <[e-mail]> wrote:

>
> *From:* Ted Hardie <[e-mail]>
> *Date:* 2015-07-10 02:04
> *To:* yaojk <[e-mail]>
> *CC:* dns-privacy <[e-mail]>
> *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 <[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?
>
> [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,
>
>
> ------------------------------
> [e-mail]
>
>
>
>