Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-05.txt

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

Question to the broader Working Group:

Shall i include the following strategy into the document at this
stage, or should we (see "EXPERIMENTAL" document status) divert this
into a future specification which updates or obsoletes the current
document?

Comments appreciated.

best,
Alex

On Thu, Jun 21, 2018 at 8:57 PM, Brian Dickson
<[email-masked]> wrote:
> Sorry to be commenting so late in the process...
>
> Was the strategy of "MTU(-ish) maximum padding policy" ever suggested,
> possibly as an alternative to Maximum Padding Policy?
>
> IMHO, there are signifiant benefits, even beyond privacy:
>
> It addresses the issues on Random that Eric R raises
> It doesn't fragment (at least locally and/or if "Internet MTU" value(s) are
> used, like 1492 or 1472 or 1452 rather than 1500 (takes into account
> expectations on use of MPLS and/or L2 encapsulation in the middle while
> still using "maximum-ish" padding,  of fixed size per client
> It largely defeats use of DNS amplification, since the query packet will
> already be as big as the biggest response. Of course, it doesn't defeat
> anonymizing attacks, it just reduces the use of authority servers for
> strictly amplification purposes.
>
> Brian Dickson
>
> On Fri, Apr 13, 2018 at 3:47 AM <[email-masked]> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the DNS PRIVate Exchange WG of the IETF.
>>
>>         Title           : Padding Policy for EDNS(0)
>>         Author          : Alexander Mayrhofer
>>         Filename        : draft-ietf-dprive-padding-policy-05.txt
>>         Pages           : 10
>>         Date            : 2018-04-13
>>
>> Abstract:
>>    RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify
>>    the actual padding length for specific applications.  This memo lists
>>    the possible options ("Padding Policies"), discusses implications of
>>    each of these options, and provides a recommended (experimental)
>>    option.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dprive-padding-policy-05
>> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-padding-policy-05
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-padding-policy-05
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> dns-privacy mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Bob Harold <[email-masked]>
Date: Wed, 25 Jul 2018 15:54:45 -0400

On Wed, Jul 18, 2018 at 8:28 AM Alexander Mayrhofer <
[email-masked]> wrote:

> I do not have an opinion on that question.

> > already be as big as the biggest response.

I thought the query and response used separate padding sizes, since queries
are typically much smaller.  So an attacker could use small padding to a
server that used "maximum-ish" padding and get amplification.  I don't
think we want to pad queries to more than 288?

-- 
Bob Harold

> Of course, it doesn't defeat