draft-ietf-dprive-edns0-padding-01.txt says: > The PADDING octets SHOULD be set to 0x00. Application developers who > are concerned about misguided lower layer compression MAY instead > fill the PADDING octets with the output of a cryptographic random > number generator. Responders MUST NOT reject messages containing > non-0x00 PADDING octets.
I don't think the draft should specifically suggest using the output of a cryptographic random number generator as padding. Earlier, I said "the ability to send data of similar compressibility to actual payload data, or data of unpredictable compressibility, would be useful". RNG output is neither of similar compressibility as the DNS message payload nor of unpredictable compressibility - its compressibility is predictably close to zero. If you pad with random data to a fixed total size, compress, and encrypt, it is still possible to tell small DNS messages from large ones - messages that were originally small will now be large, and vice versa. I think the choice of padding content should be left to the implementation, like the choice of padding size already is. Also, the text "Responders MUST NOT reject..." should apply to both responders and requestors. My suggested wording would be: The PADDING octets SHOULD be set to 0x00. PADDING octets of any value MUST be accepted in messages received. or, if you think it is necessary to include a rationale for allowing non-zero values, I would suggest: The PADDING octets SHOULD be set to 0x00. Other values MAY be used; for example, if there is a concern that the padded message could be subject to compression before encryption, the padding could be chosen to control the size of the compressed message. PADDING octets of any value MUST be accepted in messages received. -- Andreas Gustafsson, [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
