Subject: [dns-privacy] EDNS0 Padding - "profiles"?

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 22 Jul 2016 08:05:16 +0000

Hi,

i've been thinking of the best way to describe the potential implementation options when applying EDNS padding to DNS packets. As you know, RFC7830 is silent about the actual length of padding applied, since we wanted to keep the document to a simple and concise spec of the EDNS option itself. 

We're now seeing the first implementations of padding, and I've had lots of discussions around what strategy to apply when padding. The questions which arise during implementation are typically:

- Padding length strategy: (Random length, fixed length padding [which obviously is silly], padding to a block length)
- Relation of padding length between queries and responses
- Padding strategy when intended padding would exceed maximum packet size

My question is now where (if at all) we want to capture some of the ideas / strategies in a document? I think we could either add it as a few paragraphs to the profiles draft, or we could do an independent (potentially informational) draft? 

Comments?

Alex

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Jul 2016 11:41:24 +0200

In your previous mail you wrote:

>  We're now seeing the first implementations of padding, and I've had lots of 
>  discussions around what strategy to apply when padding. The questions which 
>  arise during implementation are typically:
>  
>  - Padding length strategy: (Random length, fixed length padding [which obvio
>  usly is silly], padding to a block length)

=> I agree to implement the padding EDNS option outside test tools
(e.g., dig with an explicit command line parameter) these questions
require first answers! So I support your idea.

Regards

[email-masked] (also [email-masked])

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 22 Jul 2016 15:47:33 +0200

On Fri, Jul 22, 2016 at 08:05:16AM +0000,
 Alexander Mayrhofer <[email-masked]> wrote 
 a message of 20 lines which said:

> - Padding length strategy: (Random length, fixed length padding
> [which obviously is silly], padding to a block length)

Or "random length with an inverse dependency on the size" (purely
random length would keep, on average, the relative size of the
packets).

> My question is now where (if at all) we want to capture some of the
> ideas / strategies in a document?

Yes (consider this as a promise to read and review it).

---

From: Shane Kerr <[email-masked]>
Date: Tue, 26 Jul 2016 20:01:55 +0200

Alexander,

At 2016-07-22 08:05:16 +0000
Alexander Mayrhofer <[email-masked]> wrote:

> We're now seeing the first implementations of padding, and I've had
> lots of discussions around what strategy to apply when padding. The
> questions which arise during implementation are typically:
> 
> ideas / strategies in a document? I think we could either add it as a
> few paragraphs to the profiles draft, or we could do an independent
> (potentially informational) draft? 

I tend to think that this should be a separate document. Partially this
is because I think that we'll get it wrong and have to revise the
document after a few years and it seems easier as a separate
document. ;)

Does anybody know what the best practice is in the rest of the crypto
world? (I know that DNS is a special snowflake, but we could surely use
input from people who care about such things more deeply than I ever
will...)

Cheers,

--
Shane

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 27 Jul 2016 06:46:54 +0000

> input from people who care about such things more deeply than I ever

I'm highly curious to know about that as well. I do agree that DNS is probably not a special protocol, and hence padding strategies from other protocols would work equally well for DNS.

Alex

---

From: Melinda Shore <[email-masked]>
Date: Tue, 26 Jul 2016 23:03:57 -0800

On 7/26/16 10:01 AM, Shane Kerr wrote:
> world?

Well, the correct answer to nearly any technical question is "it
depends."  But figure roughly on padding to fixed block length,
depending, and that padding contents should be random if you've got a
good source of randomness and 0 if not, depending.

I'd be happy to help review.

Melinda

---

From: Allison Mankin <[email-masked]>
Date: Thu, 28 Jul 2016 14:06:18 -0400

>
> Alexander Mayrhofer wrote:
>
> I do agree that DNS is probably not a special protocol, and hence padding
> strategies from other protocols would work equally well for DNS.
>

I like the overview of padding considerations for HTTPS in Mat Ford's TRON
Workshop talk:

    https://www.internetsociety.org/sites/default/files/T9-ford-metadata.pdf

>From another part of DNS land, a recent dnscrypt spec specifies padding for
DNS over UDP/DNS over TCP (no information about how this matches to
deployed dnscrypt proxies and servers):

https://github.com/jedisct1/dnscrypt-proxy/blob/master/DNSCRYPT-V2-PROTOCOL.txt

I like the idea of a separate draft to make recommendations for padding in
encrypted DNS.  I also really hope that we can see some implementation
experiments in parallel with the draft.

On 27 July 2016 at 02:46, Alexander Mayrhofer <[email-masked]>
wrote:

> I'm highly curious to know about that as well. I do agree that DNS is
> probably not a special protocol, and hence padding strategies from other
> protocols would work equally well for DNS.
>
> Alex
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>