Subject: [dns-privacy] Benoit Claise's No Objection on draft-ietf-dprive-edns0-padding-02: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Tue, 01 Mar 2016 01:04:57 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-dprive-edns0-padding-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Looking at this logic ...

   Responders MUST pad DNS responses when the respective DNS query
   included the 'Padding' option, unless doing so would violate the
   maximum UDP payload size.

   Responders MAY pad DNS responses when the respective DNS query
   indicated EDNS(0) support of the Requestor.

   Responders MUST NOT pad DNS responses when the respective DNS query
   did not indicate EDNS(0).

... I believe we need to improve the second paragraph. Taken out of
context of the first paragraph, it might be misleading.

   Responders MAY pad DNS responses when the respective DNS query
   indicated EDNS(0) support of the Requestor and the 'Padding' option
   is not included.

Editorial:

However, even if both DNS query and response messages were encrypted, 
meta data of could still be used to correlate such messages with well 
known unencrypted messages, hence jeopardizing some of the 
confidentiality gained by encryption. One such property is the message
size.

 meta data of?

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 2 Mar 2016 12:14:33 +0100

Benoit,

thanks for the COMMENT - i will add the proposed text change to make the
logic clearer before the draft goes to the RFC editor.

Alex