Subject: [dns-privacy] Joel Jaeggli's Discuss on draft-ietf-dprive-edns0-padding-02: (with DISCUSS)

From: "Joel Jaeggli" <[email-masked]>
Date: Mon, 29 Feb 2016 11:55:27 -0800

Joel Jaeggli has entered the following ballot position for
draft-ietf-dprive-edns0-padding-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is just something I want to discuss, it's not an objection...

At this point we say:

   Implementations therefore
   SHOULD avoid using this option if the DNS transport is not encrypted.

If you did allow this on unencrypted dns transport this seems like it
serves as a utility function for  DNS amplification.

Wouldn't it be better to say MUST NOT?

e.g. this is exclusively for use with TLS / DTLS supporting  sessions?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Feb 2016 20:59:13 +0000

> https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/

If you're running your DNS over IPsec or an SSLVPN
then using this might also be ok. So while a "MUST NOT
use in clear" does seem like it might be correct, that's
not the same as "MUST NOT except if using (D)TLS"

S.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Feb 2016 16:10:42 -0500

> not the same as "MUST NOT except if using (D)TLS"

Is there a difference between what it says ("if the DNS transport is
not encrypted") and what you said ("in the clear")?  Would there be a
reason not to change "SHOULD" to "MUST" in the existing text?

b

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Feb 2016 21:16:49 +0000

On 29/02/16 21:10, Barry Leiba wrote:
> not encrypted") and what you said ("in the clear")? 

Depends on what one means by DNS transport I guess. I don't recall
whether the WG had chatted about that.

> Would there be a

If e.g. DNS/UDP/IPsec is not an "encrypted DNS transport" then a SHOULD
is better. If DNS/UDP/IPsec is considered "encrypted DNS transport" it
looks like a MUST is fine, but I've not yet re-read this doc for the
telechat, and of course the WG may have had something else in mind.

S.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 29 Feb 2016 22:34:47 +0100

Joel,

At 2016-02-29 11:55:27 -0800
> e.g. this is exclusively for use with TLS / DTLS supporting  sessions?

If the concern is amplification, then this is independent of
encryption. Unencrypted TCP or even DNS cookies should address the
concern, the same as they do for any large response.

In the interests of simplicity I think your suggestion of making it a
MUST NOT makes sense though. Perhaps a sentence explaining the
motivation for such a strong recommendation is beneficial in that case.

Something like:

   The use of the EDNS(0) Padding provides only a benefit when DNS
   packets are not transported in clear text. Further, it is possible
   EDNS(0) Padding may make DNS amplification attacks easier.
   Implementations therefore MUST NOT use this option if the DNS
   transport is not encrypted.

Personally I would be happy if the definition of "DNS transport"
remains vague in the hopes of covering everything. ;)

Cheers,

--
Shane

---

From: joel jaeggli <[email-masked]>
Date: Mon, 29 Feb 2016 13:39:51 -0800

> remains vague in the hopes of covering everything. ;)

I like this proposal just fine, if we're not violating the assumptions
of any of the participants...

thanks
joel

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Feb 2016 23:14:55 +0000

> of any of the participants...

<nh>
  <aol>
      Me too!
   </aol>
</nh>

W
P.S: yes, that *was* fun!

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Mar 2016 11:53:17 +1100

If you want warn fuzzies then say MUST NOT otherwise it is just
noise.

You can't enforce it.  Do you throw away clear text packets with
the option in the request / response?  Adding it won't break anything.
You make testing more difficult by saying MUST NOT.

I don't intend to change a line of code to support the pad option
in named.  I might add it to dig for testing but that is about it.
named will just continue to ignore the option on requests.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 29 Feb 2016 17:05:10 -0800

Sent from my iPhone

> On Feb 29, 2016, at 16:53, Mark Andrews <[email-masked]> wrote:
> 
> 

Well if you ignore it obviously that suits me fine.

As  the recipient of a lot unwanted port 53 source traffic I'd prefer that the implementation guidance strongly discourage situations where it can be used against me in anger.