At Tue, 24 Nov 2015 10:53:51 -0500, Tim Wicinski <[email protected]> wrote:
> This starts a Working Group Last Call for > draft-ietf-dprive-edns0-padding > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/ > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out with > your reasons. It generally looks good to me. I have some minor comments: - Introduction (and overall doc): However, even if both DNS query and response packets were encrypted, meta data of these packets could be used to correlate such packets I suggest using "message(s)" instead of "packet(s)" when it talks about DNS queries and responses. I don't think "packet(s)" can cause confusion or misunderstanding in practice, but terminology-wise it doesn't seem to be very correct; in my understanding "packet(s)" usually mean layer3 (and maybe UDP) datagrams. Especially because our primary encryption tool will be TLS, differentiating packet(s) and message(s) seem to make more sense. - Section 3 servers pad DNS packets by a variable number of bytes. The 'Padding' option MUST occur at most once per OPT meta-RR. "per OPT meta-RR" sounds like a single DNS message could contain more than one OPT RR (or is it only me?), but it's impossible per RFC6891. I also wonder what if the receiver sees more than one Padding option. Should it treat it as an error or ignore the anomaly? (Should we care about it in the spec at all?). I would then wonder why this must be a MUST. It certainly doesn't make sense to include more than one padding option, but it wouldn't affect interoperability either. - Section 6 Padding DNS packets obviously increases their size, and will therefore lead to increased traffic, can lead to increased number of truncated packets when used over UDP-based transport. I don't see how it can lead to increasing truncation. Wouldn't it be impossible since the padding is only included when it wouldn't "violate the maximum UDP payload size" (as described in Section 4)? -- JINMEI, Tatuya _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
