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

From: Sara Dickinson <[email-masked]>
Date: Mon, 5 Feb 2018 13:12:17 +0000

HI All,

I also support this draft moving forwards.

A minor suggestion is to update the following sentence in the Security Considerations section so it doesn’t inadvertently sound like advice to only ever implement a single policy:

CURRENT:
“Therefore, any implementor of EDNS(0) Padding must carefully consider the chosen
   policy and its parameters.”

PROPOSED:
“Therefore, any implementor of EDNS(0) Padding must carefully consider which
policies to implement, the default policy chosen, which parameters to make configurable,
and the default parameter values.”

Also, I’m not sure it needs it because the document is short, but an ‘at-a-glance’ table comparing the policies which includes the recommendations might be useful.

Sara.

> On 22 Jan 2018, at 13:29, Brian Haberman <[email-masked]> wrote:
> 
> 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
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 7 Feb 2018 14:41:05 +0100

Hello Sara,

I've just submitted -04, addressing your comments as follows:

> and the default parameter values.”

thanks - changed.

> Also, I’m not sure it needs it because the document is short, but an ‘at-a-glance’ table comparing the policies which includes the recommendations might be useful.

I've decided not to, particularly since we've now moved two of the
strategies to an Appendix. I think there's few enough to grasp the
viable options now..

best,
Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 7 Feb 2018 14:44:20 +0100

Stephane,

I've just posted -04, which addresses your comments as follows:

On Mon, Jan 29, 2018 at 4:49 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> * 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.

Done, since i've seen one additional "+1".

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

I've decided to not add this. The reason for that is that there *are*
a few implementations of Padding out there, but there's very little
implementation of the actual recommended strategy in there. The link
you quoted would have belonged to the original Padding draft, but then
again,i only set up the website once the RFC was out ;)

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

Added a note saying it's only relevant when transport is encrypted,
and added a whole paragraph in the introduction to refer to 7858 and
also 8094.

best,
Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 7 Feb 2018 14:47:59 +0100

Stephane, Stephen,

i've just posted -04 of the draft, addressing your WGLC comments as follows:

On Mon, Jan 29, 2018 at 4:58 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> 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.

I've extended the relevant paragraph in the security considerations
section to say:

"Note that even with encryption and padding, it might be trivial to
identify that the observed traffic is DNS. Also, padding does not
prevent information leak via other side channels (particularly timing
information and number of query/response pairs). 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."

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

I agree with Stephane - it would be pretty complicated, and unless
there's a clear indication there's an advantage knowing about the
policy of the other side, there's no real use (eg. if two policies
interacted in a particularly favorable way..)

Also, this would rather require updating RFC 7830 to allow for
signalling, or introducing even another EDNS option .... I'd rather
not follow that rathole for now :)

best,
Alex

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 7 Feb 2018 13:49:23 +0000

> On 7 Feb 2018, at 13:41, Alexander Mayrhofer <[email-masked]> wrote:
> 
> Hello Sara,
> 

Agreed!

Thanks.

Sara.