> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <[email protected]> wrote:
>
> Shane Kerr wrote:
>> Andreas Gustafsson <[email protected]> wrote:
>>>
>>> I'm also wondering if there might be scenarios where the messages are
>>> compressed before encryption. If that is the case, padding with zeros
>>> is of limited value because they will mostly compress away, and the
>>> ability to send data of similar compressibility to actual payload
>>> data, or data of unpredictable compressibility, would be useful.
>>
>> It's an interesting idea, but I think I'd like to see some solid
>> research on this. We understand how to add 0 bytes; I don't personally
>> understand the implications of generating "similarly compressible" data
>> to prevent attackers from doing traffic analysis.
>>
>> My own feeling is that we should proceed with 0-padding, and perhaps
>> consider alternate schemes later if there is good guidance in the area
>> of non-empty padding.
>
> We can certainly proceed with *sending* 0-padding. All I'm asking is
> for receivers not to reject messages with nonzero padding, so that if
> alternate schemes are introduced in future senders, they can
> interoperate with existing receivers.
+1 All resolvers should ignore the contents padding
>
>> Surely academics have looked at this! Do you have pointers to some
>> papers covering this approach?
>
> I'm afraid not.
Shane,
There is lots of work in this area, but it is trivial to reason about the issue
from DNS perspective
Goal: hide how long the query name is, to defeat traffic analysis.
Padding of the same value in each byte can be compressed to almost nothing ==>
same as having no padding, ==> failed to meet goal.
TLS by default in many cases, compresses before transmission, ==> DNS padding
option must defeat compression
I think the WG should consider if the current text of saying use 0x00 is not
good enough,
there are 3 options, use:
- 0x00
- cheap randomness
- real randomness source
I think the middle one is good enough, a simple seeded hash function i.e. HMAC
is sufficient or /dev/urandom
Olafur
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
