Subject: [dns-privacy] WG Last Call: draft-ietf-dprive-padding-policy-03.txt

From: Brian Haberman <[email-masked]>
Date: Mon, 22 Jan 2018 08:29:29 -0500

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Jan 2018 14:00:16 +0000

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:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> 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;-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 29 Jan 2018 16:49:59 +0100

On Mon, Jan 22, 2018 at 08:29:29AM -0500,
 Brian Haberman <[email-masked]> wrote 

> 	Filename        : draft-ietf-dprive-padding-policy-03.txt

Executive summary: OK for me, seems ready.

Some remarks, none of them blocking.

* I would prefer 4.1 "no padding" and 4.2 "fixed length padding" to be
moved to an appendix to emphasize they are mentioned just for
completeness, not for actual implementation.

* a RFC 7942 Implementation Status section could be cool, quoting
<http://edns0-padding.org/implementations/>

* there is no mention of RFC 7858. Is padding useful except when the
data is encrypted? I don't think so. (Stephen Farrell made a similar
remark.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 29 Jan 2018 16:58:33 +0100

On Mon, Jan 22, 2018 at 02:00:16PM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 241 lines which said:

> - 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.)

I suggest an appendix "Besides padding" with:

It is possible that there are other mechanisms that one might use to
further increase the difficulties of DNS traffic analysis. For
instance, gratuitous queries and/or answers could be added to cover
the real traffic. Or jitter could be added, with a random delay before
replying. We currently don't have enough theoretical analysis or
experimental data to recommend one of these mechanisms.

> - There's no way to know (for sure) which padding scheme a peer is
> using I think?

Local decision, indeed.

> 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.

And it's complicated: there are several policies, each with several
parameters. It would require the standardization of a mini-language,
and of an IANA registry of padding policies.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 29 Jan 2018 08:47:30 -0800

> completeness, not for actual implementation.

+1 to this proposal.

--Paul Hoffman