I read this and support it moving forward, it's good enough as-is. But I also have two nits and two questions:-)
- 4.5 still has a "TODO:" - Section 5: I think the numbered list might be better if you added a "(0) This only applies if you're encrypting." RFC 7830 does say you MUST NOT pad if the transport is not encrypting but it might be worth saying it here too. - Is there any (good) literature on related mechanisms that one might use to further increase the difficulties of traffic analysis based on DNS traffic? I'm thinking about synthetic cover traffic or of adding jitter to the timing of requests, but there could be other things one might do. Even if we aren't in a position to provide experimental recommendations about such things, (I'd be happy if we were), it'd be good to at least add a mention and some references if we could. While such work could be done later and in a separate specification, it is pretty closely related to this so would also fit nicely in here if we had good text to add. (I don't have text to offer, sorry.) - There's no way to know (for sure) which padding scheme a peer is using I think? If so, would there be any benefit in making that possible? I think the answer is that's there's not enough to gain by doing so. If there were then one could indicate that via some padding octets I guess, even though that's pretty hacky. Cheers, S. On 22/01/18 13:29, Brian Haberman wrote: > All, > This message starts a two week WG Last Call on advancing: > > Title : Padding Policy for EDNS(0) > Author : Alexander Mayrhofer > Filename : draft-ietf-dprive-padding-policy-03.txt > Pages : 9 > Date : 2018-01-17 > > as an Experimental document. The last call will end on February 5, 2018. > All substantive comments are to be sent to the mailing list for > discussions. Editorial comments can be sent to the document editor. > > Regards, > Brian & Tim > > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-)
0x7B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
