Subject: Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-padding-policy-05: (with COMMENT)

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 18 Jul 2018 14:49:47 +0200

Benjamin,

thanks for the review. Comments inline:

On Wed, Jun 20, 2018 at 11:38 PM, Benjamin Kaduk <[email-masked]> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dprive-padding-policy-05: No Objection
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> At risk of triggering suggestions that there is an echo in the room: This
> document is targetting Experimental status.  Is there a way to know when
> the experiment has ended and/or what the conclusion is?

The reason for this document to be Experimental was that the
recommendation is based on a single empiric study. I would say that if
/ once more empiric studies are undertaken, we can subsequently create
a document with Standards track. Note that such work is eg. proposed
in https://mailarchive.ietf.org/arch/msg/pearg/JGuNpoi0IkUPwk6Z08QjXtzTGXA
- so we can expect to hear more from the research community in the
future.

> I know this document does not claim to be exhaustive, but I wonder
> if there was any consideration for a "random multiple fixed block length
> padding", where a fixed block length is used, but the padded message does
> not always use the smallest multiple of the block length that will fit the
> message.  That is, sometimes there is an extra block length or three of
> padding after the "normal" padding to get to the block length.  (This
> strategy is quite closly related to Random Block Length Padding, where the
> candidate block lengths are multiples of the single "fixed" block length,
> but I cannot convince myself that the two are completely identical.)

This was not considered yet. We do have received another suggestion
for a possible padding policy, and my idea was that we could push that
to a future revsion of the policy (once we have more empiric
findings). I have a question pending to the WG for that other policy
to understand what the WG prefers.

> Section 4.1
>
>    The Block Size will interact with the MTU size.  Especially for
>    length values that are a large fraction of the MTU, unless the block
>    length is chosen so that a multiple just fits into the MTU, Block
>    Padding may cause unneccessary fragmentation for UDP based delivery.
>    Also, chosing a block length larger than the MTU of course always
>    forces to always fragment.
>
> This paragraph is (modulo two words) a duplication of a previous paragrpah
> in this section; I think this one (the penultimate paragraph) should be
> removed.

Done, thanks for spotting that. Was an editing mishap.

> Section 7
>
>    No matter how carefully a client selects their Padding policy, this
>    effort can be jeopardized if the server chooses to apply an
>    ineffective Padding policy to the corresponding response packets.
>    Therefore, a client applying Padding may want to choose a DNS server
>    which does apply at least an equally effective Padding policy on
>    responses.
>
> Is there any way for the client to determine the behavior of DNS servers in
> this matter other than trial-and-error?  Perhaps some additional text would
> be helpful.

There is currently no way to signal the server's padding policy.

We have discussed the idea off-list -  However, the result was that
even if a server would communicate which policy it followed, a rogue
server could still apply a "worse" padding scheme. It all boils down
to the trust relationship between client and server, and this is a
problem that can hardly be solved "in-band".

>    [...] Counter-measures
>    against such other side channels could include injecting artificial
>    "cover traffic" into the stream of DNS messages, or delaying DNS
>    responses by a certain amount of jitter.  Such strategies are out of
>    scope of this document.  Additionally, there is neither enough
>    theoretic analysis nor experimental data available to recommend any
>    such countermeasures.
>
> (This seems very closly aligned with Eric's DISCUSS.)  My understanding is
> that in general, random jitter is not actually very helpful in this regard.
> So I'm curious to hear a summary of the WG discussions on this strategy.

This was suggested by Stephen Farrell as part of the WGLC. The
respective discussion about that paragraph is here:
https://mailarchive.ietf.org/arch/msg/dns-privacy/YYpw8N2V56U-U_vJKwrl1ES28j0

I'm looking at Eric's DISCUSS next, and will look at how to address this.

best,
Alex

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Jul 2018 10:07:27 -0500

> thanks for the review. Comments inline:

Also inline.

> - so we can expect to hear more from the research community in the

I think we're all excited to hear more from the research community, yes.
Do you think it makes sense to add a note in the Introduction that this
document is Experimental so that we can get more data from deployments and
testing?

> to understand what the WG prefers.

Sure.  I don't think you need to hold up this document to add more
examples; putting them in a future update seems fine.

> problem that can hardly be solved "in-band".

True.  I'm ambivalent about whether there's value in adding text about
"this choice must be made based on information obtained out of band" or
"this requires the client to have some level of trust in the server".

> I'm looking at Eric's DISCUSS next, and will look at how to address this.

Hmm, looking at the resolution there, maybe we want to say that an attacker
who can observe a large number of requests can still infer information from
the resulting distribution, here, as well?  But this is almost an
in-passing remark that might not merit that level of detail...

-Benjamin

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 20 Jul 2018 09:49:29 +0200

Benjamin,

thanks for the additional comments. Actually, the idea of specifically
describing why the document is Experimental is great. I'll talk to
Brian/Chairs whether i should do an RFC editors note, or roll an
additional revision. That could also cover your additional
suggestions.

best,
Alex