Subject: [dns-privacy] Working Group Last Call for draft-ietf-dprive-edns0-padding

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Nov 2015 10:53:51 -0500

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.

This starts a two week Working Group Last Call process, and ends on
8 December 2015

thanks
tim

---

From: 神明達哉 <[email-masked]>
Date: Tue, 24 Nov 2015 11:42:48 -0800

At Tue, 24 Nov 2015 10:53:51 -0500,

> feels the document is *not* ready for publication, please speak out with

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