Subject: [dns-privacy] Direction of draft-mayrhofer-edns0-padding

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Jul 2015 12:28:41 +0000

Hi,

I'm working through my notes from the DPRIVE session regarding the EDNS0 Padding option. My takeaway was as follows:

- Generally, this seems to be a reasonable idea
- Besides the use to evade size-based message correlation, this could also be useful in other cases, eg. "proof of work" for clients when requesting larger packets (Peter K.)
- However, the draft should only specify the option itself, and not indulge into the various usage scenarios
- The EDNS0 assignment policy is Speficiation Required / Expert Review, hence does not necessarily require an RFC
- The preferred way forward is individual draft, AD-sponsored.
- Discussion can continue on the DPRIVE list

Regarding the actual contents of the draft, my takeaway was:

- Is "1" the right minimum length for the option? Why not "0"?
- Padding must obviously not exceed the announced EDNS0 packet size - some words about that
- No consideration is required whether or not a server may pad, because clients are required to ignore unknown options anyways.
- The Security considerations section needs more work.

Is that in line with the perception of the WG members? Anything I forgot to mention / consider?

Thanks,
Alex

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 29 Jul 2015 06:41:10 -0700

On 29 Jul 2015, at 5:28, Alexander Mayrhofer wrote:

> Hi,
>
> I'm working through my notes from the DPRIVE session regarding the 
> EDNS0 Padding option. My takeaway was as follows:
>

That may be too strong of an assessment. There were questions about 
whether the padding should be done in DNS or in TLS. My personal view is 
that if the two types of padding give similar benefits, it absolutely 
should be done in TLS for many reasons. I think we need to get more 
input (possibly from CFRG) about the benefits of padding at each layer.

> - Besides the use to evade size-based message correlation, this could 
> also be useful in other cases, eg. "proof of work" for clients when 
> requesting larger packets (Peter K.)

This is possibly a bad idea. In the IPsecME WG, we have had an active 
work item on proof-of-work for clients to prevent DDoS, with lots of 
good discussion on how to do it, and we're probably going to only leave 
it as an Experimental document. In summary, adding proof-of-work hurts 
the group you care most about, namely clients on small machines.

> indulge into the various usage scenarios

That's exactly the place we are ending up in IPsecME, and it's not where 
we expected.

> - The EDNS0 assignment policy is Speficiation Required / Expert 
> Review, hence does not necessarily require an RFC
> - No consideration is required whether or not a server may pad, 
> because clients are required to ignore unknown options anyways.

See above. I propose that we not do this at all if it turns out to be 
better done in TLS so that we don't create an attractive nuisance. If 
CFRG says that it is better to do it in the inner protocol, then we 
should proceed, but with the narrow focus of preventing analysis of 
TLS-protected traffic, not for proof-of-work.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 14:55:01 +0100

On 29/07/15 14:41, Paul Hoffman wrote:
> should be done in TLS for many reasons. 

With no hats, I disagree. Given that we don't yet know how
to effectively pad at any layer, my belief is that we should
define the basic mechanism at every layer so that when someone
does figure it out, the protocol mechanics exist.

The way I think about this is a) the most effective padding
can be done in the application layer, but b) that may not be
feasible so lower layer padding (esp in TLS) should also
exist and on the 3rd hand - there may be a few cases where
different protocols are multiplexed in such a way that one
lower layer padding mechanism could help with both, but
that'll be really rare.

> I think we need to get more

(With hat:-) CFRG is not the right group for a few reasons. First -
effective use of padding like this isn't a crypto thing - we're not
dealing with a block cipher here. CFRG are also busy enough right now
on stuff they should be getting done.

But we don't actually have a centre of expertise about effective
padding so I can see why you suggest CFRG. Ideas as to how to try
foster/create such a thing would be welcome. Mostly I think the
hard part there will be to attract the few folks who know about
this topic and are willing to work on it openly.

> the group you care most about, namely clients on small machines.

I also think separating out proof-of-work ideas is better.

Cheers,
S.

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 29 Jul 2015 07:12:54 -0700

> does figure it out, the protocol mechanics exist.

Interesting. I thought we had heard discussion of padding at both 
layers, and thus I thought people would by now have good ideas about 
which is better. Drat.

> lower layer padding mechanism could help with both, but

The way I think about this is that the application layer doesn't know 
whether or not it is covered by TLS, so any padding done there when TLS 
is not used wastes bandwidth. TLS always knows that it is running, and 
what is running under it, and therefore padding is always appropriate 
there.

> on stuff they should be getting done.

Probably true.

> this topic and are willing to work on it openly.

Agree. However, we are not in a rush on this (we haven't even agreed on 
TLS / DTLS), so having the discussion about where to pad before we 
blindly start padding in DNS.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 29 Jul 2015 12:23:39 -0400

Hi folks--

> input (possibly from CFRG) about the benefits of padding at each layer.

In the TLS WG, the broad consensus is that if padding is possible at the
application layer, that is the right place to pad.  The rationale
concerns countermeasures to traffic analysis -- in particular, the
application layer has much more knowledge than the TLS layer about what
its traffic generally looks like.  traffic analysis countermeasures are
subtle and closely tied to existing patterns of usage.  TLS is an
abstraction that is intentionally removed from what the application
layer does.

Also, there is no padding mechanism available in TLS at the moment :)
i'm trying to get one into TLS 1.3 for those application layers that
have nowhere to pad, and i could conceivably write up an extension to
TLS 1.2.  But even having that mechanism, you'd need to be able to set
policy about when to pad and by how much.

So from the thinking and work i've done on this, padding at the
application layer is preferable where possible.  Paul, you say you have
many reasons for wanting to do it in TLS -- can you explain some of
those a bit more?  I want to make sure i'm not missing anything vital.

> the group you care most about, namely clients on small machines.

I agree with Paul here that conflating padding with proof-of-work seems
like a bad idea.  For one, proof-of-work schemes tend to encourage one
partner to dictate the work to the other partner -- in such a scheme,
each peer wouldn't be able to pad according to its known traffic
patterns.  for another, if the proof-of-work scheme is intended to
require some kind of puzzle-solving, i wouldn't want someone who just
wants to pad to have to incur extra computational costs.

If someone wants a "proof-of-work" extension to DNS, i think that should
be specified independently so that it doesn't get tied into this
proposal.  It's not like the registry [0] is short of codepoints.

In practice, the EDNS0 spec appears to allow the use of unknown options
for padding already, since peers are expected to ignore options they
don't know.  Adopting this draft would provide a codepoint allocation
that explicitly acknowledges this as a practice and avoids codepoint
squatting or abuse of the "Reserved for Local/Experimental Use" section
for folks who try to make use of it.

   --dkg

[0] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 29 Jul 2015 10:05:18 -0700

On 29 Jul 2015, at 9:23, Daniel Kahn Gillmor wrote:

> application layer, that is the right place to pad.

That will teach me to stop going to the TLS WG. :-)

> The rationale

Basically, the DNS stack will not know whether or not it is running 
under TLS/DTLS when the query and reply are formed; TLS/DTLS will be 
opportunistic. So, to be safe, the DNS client or server will be forced 
to add padding even when it is not needed, and thus make every message 
longer.

We don't know how much padding is required to prevent analysis for 
particular query/response pairs, and thus need to add lots of 
random-length padding to each message to prevent the analysis. This 
seems wasteful. Instead, if the TLS stack could add the padding, it 
would only happen when needed.

But I understand the problem of "we don't even have that now" and "we 
don't know when we will have it". The draft in question is trivial to 
implement, but configuring it (with the length per query or response) 
seems impossible without adding large amounts.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 18:48:45 +0100

Hiya,

> That will teach me to stop going to the TLS WG. :-)

And this one may teach me to try harder to get to dprive:-)

> to add padding even when it is not needed, and thus make every message

I don't get that. Surely at most 1 query or response will be sent
when in such a state of ignorance, after which the application layer
can easily know if a TLS session exists. We are after all still
talking about stub<->recursive still, right?

> random-length padding to each message to prevent the analysis. 

I also don't get that. I agree we're not sure how to best use
padding. But we can define the simple bit of protocol needed now
and then after folks figure out how best to use it we could have
some more recommendations to make. And those might end up being
context dependent. So I see no need to mandate something wasteful
now.

> This

Again, I'm not that pessimistic. My guess is that implementers
will figure out effective ways to pad. We don't need to tell them
everything about that here and now.

S.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 29 Jul 2015 11:00:07 -0700

> talking about stub<->recursive still, right?

We are not defining an API, so there is no way for the application layer 
to know what it is running under.

> context dependent. So I see no need to mandate something wasteful

That would be fine. What I worry about is that people will say "we can 
pad; people tell us to pad liberally; we will pad liberally". It would 
be great for the spec to say "probably don't do this much until more 
research has been done".

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 19:06:14 +0100

> to know what it is running under.

Eh? There may be some implementations like that but I'd be very
surprised if, when dprive is done, most implementations don't have
an is_doing_dprive() call they can make use of in application
layer code.

Sure if you're running over IPsec that's a problem, but it hasn't
been for TLS consuming applications that I know.

> be great for the spec to say "probably don't do this much until more

That'd be fine if we can't do better by the time we're publishing
that RFC text, yes.

S.