Subject: [dns-privacy] Why MUST EDNS(0) Padding option only appear once?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Nov 2021 12:24:08 -0400

Hi DPRIVE folks--

RFC 7830 (The EDNS(0) Padding Option) says:

> The "Padding" option MUST occur at most, once per OPT meta-RR (and
> hence, at most once per message).

Over on https://github.com/PowerDNS/pdns/issues/10884 there's some
discussion of a case where it would be technically advantageous for a
DNS server to include more than one EDNS padding option.  In particular,
a forwarding DNS resolver might want to remove some EDNS option from an
already-padded query or response before forwarding while keeping the DNS
frame the same size.  A very simple way to do this when the cleartext
DNS frame is in memory is to overwrite the undesired EDNS option with
another EDNS padding option, but that would run afoul of the above
"MUST" when the frame is already padded.

Obviously, it's not impossible to shuffle EDNS options around in the
frame to coalesce the padding octets into a single Padding option.  But
in the interest of keeping the "fast path" fast, and of reducing the
opportunity for bugs in the codebase the implementers at the linked
issue are hesitant to do that kind of work.

I reviewed the previous drafts of RFC 7830 all the way back to
https://datatracker.ietf.org/doc/html/draft-mayrhofer-edns0-padding-00
and the "at most once" language appears in all of them -- but i don't
see a justification for it.

RFC 2119 of course says of upper-case keywords:

>   they MUST only be used where it is actually required for
>   interoperation or to limit behavior which has potential for causing
>   harm (e.g., limiting retransmissions).  For example, they must not
>   be used to try to impose a particular method on implementors where
>   the method is not required for interoperability.

Does anyone know the rationale for this "MUST occur at most once" ?  Is
there an additional privacy leak if there were to be more than one EDNS
Padding option?  Are there implementations that would choke if they
received more than one EDNS Padding option?

Has anyone done any experiments to see whether multiple Padding options
do break interoperability?  If not, does anyone have a DNS interop
testing rig that could be easily updated to include such a test?

        --dkg

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 1 Nov 2021 18:56:59 +0100

On 01/11/2021 17.24, Daniel Kahn Gillmor wrote:
> Is there an additional privacy leak if there were to be more than one EDNS
> Padding option?

I don't think it's possible to leak more privacy by doing that. Assuming 
an encrypted channel, only the overall length of the DNS message should 
matter.  Perhaps if the "surprising" repeat could trigger some bug, I 
imagine the effect might then be observable, but it still doesn't sound 
privacy-risky to me.

--Vladimir | knot-resolver.cz

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Nov 2021 11:19:47 -0700

On 11/1/2021 10:56 AM, Vladimír Čunát wrote:
> I don't think it's possible to leak more privacy by doing that. 
> Assuming an encrypted channel, only the overall length of the DNS 
> message should matter.  Perhaps if the "surprising" repeat could 
> trigger some bug, I imagine the effect might then be observable, but 
> it still doesn't sound privacy-risky to me.

We have similar discussions of that in the DNS over QUIC context. QUIC 
has its own framing, and it is possible for example to put two DNS 
queries back to back in the same encrypted packet. Padding with EDNS 
interferes with that, and it might be just as well to use QUIC padding 
instead. But then, QUIC padding is inserted by the QUIC stack, so it 
will only be "set right" if there is a way for the application to 
somehow specify a QUIC padding policy. Otherwise, better be safe and use 
EDNS padding.

-- Christian Huitema

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Nov 2021 16:23:21 -0400

On Mon 2021-11-01 18:56:59 +0100, Vladimír Čunát wrote:
> matter.

This is my intuition as well, though i haven't done any deep analysis on
it.

> Perhaps if the "surprising" repeat could trigger some bug, I imagine
> the effect might then be observable, but it still doesn't sound
> privacy-risky to me.

I'm also having a hard time imagining what bug would be triggered.  I
imagine that most implementations just ignore all EDNS Padding options
they encounter, not only the first one, but i haven't tested it widely.

     --dkg