Subject: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 10 Sep 2018 05:27:26 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-refuse-any-07: Yes

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-dnsop-refuse-any/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm wondering if it would make sense to provide stronger guidance that the
conventional ANY response SHOULD be provided if TCP is used as TCP already
provides a retrun routability proof...? Also maybe provide a refernce to
RFC7766?

And one smallish comment: Would it make sense to refer
draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC)
instead of RFC7719?

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 13 Sep 2018 09:02:22 +1100

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

This has nothing to do with "retrun routability"  if big answers are given
to resolver via TCP then the resolver can be used as amplifier and there
Millions of those on the net.

IMHO the only time big ANY answer CAN be returned is when the connection is
authenticated and approved.

> draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC)
Hope this happens by RFC-editor or in AUth48

Olafur

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 13 Sep 2018 17:25:04 +0200

Hi Olafur,

please see below.

> Am 13.09.2018 um 00:02 schrieb Ólafur Guðmundsson <[email-masked]>:
> 
> 
> 
> On Mon, Sep 10, 2018 at 11:27 PM, Mirja Kühlewind <[email-masked]> wrote:
> This has nothing to do with "retrun routability"  if big answers are given to resolver via TCP then the resolver can be used as amplifier and there Millions of those on the net. 

With TCP you usually set up a TCP connection (3-way handshake) then send the request on that connection and get the reply on that connection. You can not change the IP address in the mean time. So there should not be that amplification attack anymore. That was what I was saying.

> 
> IMHO the only time big ANY answer CAN be returned is when the connection is authenticated and approved. 

Not sure what you mean by „approved" but I guess that is what TCP gives you. If you really need authentication you’d need to use TLS but not sure why that would help.
> Hope this happens by RFC-editor or in AUth48

It will only happen if you replace [RFC7719] which [draft-ietf-dnsop-terminology-bis-09] because then the RFC editor knows that there is a dependency and will wait with the publication until draft-ietf-dnsop-terminology-bis-09 has an RFC number and then replace automatically [draft-ietf-dnsop-terminology-bis-09] with the RFC-to-be.

Mirja

---

From: 神明達哉 <[email-masked]>
Date: Thu, 13 Sep 2018 11:25:03 -0700

At Thu, 13 Sep 2018 17:25:04 +0200,

>> This has nothing to do with "retrun routability"  if big answers
>> are given to resolver via TCP then the resolver can be used as
>> amplifier and there Millions of those on the net.

> With TCP you usually set up a TCP connection (3-way handshake) then
> send the request on that connection and get the reply on that
> connection. You can not change the IP address in the mean time. So
> there should not be that amplification attack anymore. That was what
> I was saying.

(I'm not intending to speak for him but) I guess what Ólafur intended
to say is that if a legacy (so not implementing dnsop-refuse-any) and
open resolver sends an ANY query over TCP and gets and caches the
large "conventional" response, that resolver can be exploited as an
amplifier for subsequent ANY queries with a forged source address (and
quite likely over UDP).  If so, that's true, but I don't think it
trivial to force such a resolver to send the ANY query over TCP in the
first place, and the argument against "a return of routability proof"
doesn't seem to be strong enough.  In fact, I'd interpret Section 4.4
of draft-ietf-dnsop-refuse-any-07 as it allows the conventional ANY
response over TCP exactly thanks to this return of routability proof
(this "responder" is much less likely to be exploited as an amplifier
thanks to that).  If the intent of this section has really nothing to
do with that, I'd like to see some explanation about the actual intent
in the document.

Whether we *SHOULD* (rather than MAY) allow the conventional response
in case of TCP is a different question, on which I don't have a strong
opinion.

--
JINMEI, Tatuya

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 14 Sep 2018 08:26:04 +1100

Jinmei explained perfectly what I was trying to say

Olafur

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Sep 2018 12:26:04 +0100

> in case of TCP is a different question, on which I don't have a strong

I think at the moment it is mostly harmless and sometimes helpful for
debugging or inspection - e.g. `dig` switches to TCP by default for ANY
queries to avoid confusing users with partial answers, so it makes use of
this SHOULD.

If I look into my crystal ball at a future where resolvers query auth
servers over TLS, then the balance might change. Maybe at that point it'll
be better for resolvers to implement refuse-any rather than relying on
auth servers to do it for them; or maybe it'll be better to do
refuse-any over all transports. Dunno :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Fitzroy: Variable 3 or 4, becoming southerly or southeasterly 5 or 6 in
west. Moderate. Occasional rain in west. Good, occasionally moderate in west.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Sep 2018 13:28:55 +0200

Hi all,

please see below.

> Am 14.09.2018 um 13:26 schrieb Tony Finch <[email-masked]>:
> 

That the question I had. Currently the doc only says 

"A DNS responder MAY behave differently when processing ANY queries
   received over different transport“

which kind of implicitly say, refuse-any is always the right default… I was wondering if for the case of TCP a SHOULD would actually be more appropriate. 

> queries to avoid confusing users with partial answers, so it makes use of

There is no SHOULD right now...

> refuse-any over all transports. Dunno :-)

That’s also fine. If it is not clear which recommendation should be given for TCP then it does make sense to say anything more than what the doc currently says.

Mirja