Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Shane Kerr]

On 2015-10-01 12:13+0100
Dick Franks  wrote:

> Dick Franks
> 
> 
> 
> On 1 October 2015 at 11:12, Shane Kerr  wrote:
> 
> >
> > In the case where people just want to reduce the damage of ANY queries
> > in reflection attacks, I quite like the PowerDNS option of forcing ANY
> > queries to TCP via truncation. I'm not sure if this has been documented
> > in any RFC, but if not then perhaps it bears mentioning too?
> >
> 
> That rests on two assumptions:
> 
> 1)  that damage limitation from reflection attacks is the primary concern
> here, which appears no longer to be the case.

The draft documents amplification attacks:

   ANY queries are also frequently used to exploit the amplification
   potential of DNS servers using spoofed source addresses and UDP
   transport (see [RFC5358]).  Having the ability to return small
   responses to such queries makes DNS servers less attractive
   amplifiers.

Which is why I mention it.

> 2) that there is some plausible reason for doing ANY queries, in which case
> it would be interesting to know what that might be.

The entire draft presumes some plausible reason for doing ANY queries,
otherwise it would just say "we hereby deprecate ANY queries". :P

In fact the start of the motivations section tries to address this:

   ANY queries are legitimately used for debugging and checking the
   state of a DNS server for a particular owner name.

I'm not sure I totally agree, since I have never had occasion to use an
ANY query in anger, but some people seem really attached to it.

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Dick Franks]

Dick Franks



On 1 October 2015 at 11:12, Shane Kerr  wrote:

>
> In the case where people just want to reduce the damage of ANY queries
> in reflection attacks, I quite like the PowerDNS option of forcing ANY
> queries to TCP via truncation. I'm not sure if this has been documented
> in any RFC, but if not then perhaps it bears mentioning too?
>

That rests on two assumptions:

1)  that damage limitation from reflection attacks is the primary concern
here, which appears no longer to be the case.

2) that there is some plausible reason for doing ANY queries, in which case
it would be interesting to know what that might be.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-root-loopback-04: 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-root-loopback/



--
COMMENT:
--

Thanks for documenting this. I may try it:-)


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Brian Haberman's Yes on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[Brian Haberman]

Brian Haberman has entered the following ballot position for
draft-ietf-dnsop-root-loopback-04: 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-root-loopback/



--
COMMENT:
--

Thanks for writing a clear document that describes the approach and the
potential pitfalls.  As I noted earlier, I think this approach is
untenable given the fragility it will introduce.  Any chance we will see
a management item in the near future marking the resulting RFC Obsolete?

-- old comments below --

I can't decide if I should ballot Yes because this document does a good
job of describing how to deploy this approach or Abstain because the
fragility introduced in this approach appears to be untenable.

In the meantime, can someone explain why this document is stating a
requirement to deploy this approach with IPv4 only?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Paul Vixie]

Shane Kerr wrote:
>
>
> In the case where people just want to reduce the damage of ANY queries
> in reflection attacks, I quite like the PowerDNS option of forcing ANY
> queries to TCP via truncation. I'm not sure if this has been documented
> in any RFC, but if not then perhaps it bears mentioning too?

note that in a normal reflective ddos where a lot of ANY queries are
being received, the above proposal results in a full TCP session table,
thus denying TCP service to any non-attacker.

this is not a serious problem since virtually anyone can launch a denial
of service against TCP/53, without a distributed attack force. so, that
problem already exists.

if it's going to become a documented operational practice, then this
risk should be documented also.

-- 
Paul Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[Darcy Kevin (FCA)]

This may be a little off-topic for DNSOP, but has anyone considered submitting 
Errata for RFC 4291 to add the word "physical" before the word "interface" to 
the sentence

"A packet received on an interface with a destination address of loopback must 
be dropped"

?

Because, as it stands, if taken literally, even packets to lo0 should be 
discarded, thus effectively transforming so-called "IPv6 loopback" into "IPv6 
sinkhole", and leaving no formal address assignment whatsoever for true 
*loopback* functions in IPv6.

Be that as it may, since the "reservation" of the entire ::/8 block in 
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml 
isn't backed up by any corresponding /8-level definition in 
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml,
 I think the portions of ::/8 not mentioned in the latter registry are 
legitimately available for loopback purposes. Just don't put any packets on the 
wire with source or dest addresses in that range.

Or, as Mark said, just use a ULA address configured on a local interface.


- Kevin

-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Vixie
Sent: Wednesday, September 30, 2015 9:47 PM
To: John Levine
Cc: e...@isc.org; dnsop@ietf.org
Subject: Re: [DNSOP] Brian Haberman's No Record on 
draft-ietf-dnsop-root-loopback-04: (with COMMENT)



John Levine wrote:
>> It should be easy enough to create a local alias address for the 
>> purpose though.  "ifconfig lo inet6 add ::2 alias", salt to taste.
>
> Uh, no.  The *only* loopback address is ::1.  The rest of ::/8 is 
> reserved.

right. just like 127.0.0.0/8 is reserved. yet i use 127.0.0.2, .3, and so on, 
all the time. i think it's probably safe to intrude on this "reservation" for 
this use case.

> If you have a loopback software interface, you could set up a link 
> local address like fe80::1, but now your DNS software has to 
> understand link scoped addresses like fe80::1%lo.
>
> Having set up a DNS cache on my LAN using link local IPv6 addresses, I 
> can report that it doesn't work very well.

agreed.

> All in all, I think the advice to stick with IPv4 loopback addresses 
> is reasonable.  We can revisit this in 2050 when IPv4 is starting to 
> be phased out.

disagreed. ipv4 should die a-s-a-p. don't bring up any new ipv4 services unless 
you are sure they have to talk to the legacy internet. which is demonstrably 
not the case for localhost dns service.

now you don't see it:

root@family:/home/vixie # ifconfig lo0
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21

now you do:

root@family:/home/vixie # ifconfig lo0 inet6 ::2/128 alias 
root@family:/home/vixie # ifconfig lo0
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
inet6 ::2 prefixlen 128
nd6 options=21

ntpd is a grabby little thing:

root@family:/home/vixie # netstat -an | grep ::
tcp6   0  0 ::1.465*.*LISTEN
tcp6   0  0 ::1.587*.*LISTEN
tcp6   0  0 ::1.25 *.*LISTEN
tcp6   0  0 ::1.993*.*LISTEN
tcp6   0  0 ::1.143*.*LISTEN
tcp6   0  0 ::1.995*.*LISTEN
tcp6   0  0 ::1.110*.*LISTEN
udp6   0  0 ::2.123*.*
udp6   0  0 fe80::1%lo0.123*.*
udp6   0  0 ::1.123*.*
udp6   0  0 fe80::2a0:98ff:f.123   *.*

i had to alter these lines of my ipfw configuration:

add passall from any to any via lo0
add denyall from any to { ::1 or 127.0.0.0/8 }
add denyip  from { ::1 or 127.0.0.0/8 } to any

they now read:

add passall from any to any via lo0
add denyall from any to { ::1 or ::2 or 127.0.0.0/8 }
add denyip  from { ::1 or ::2 or 127.0.0.0/8 } to any

i had to add a line to ntp.conf:

restrict -6 ::1
restrict -6 ::2

noting, the other lines in that vicinity tell us things about
127.0.0.0/8 that the IETF might not know:

restrict 127.127.1.0

but anyway, it works:

root@family:/home/vixie # ntpq -p ::2
 remote   refid  st t when poll reach   delay   offset 
jitter

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Ólafur Guðmundsson]

On Wed, Sep 30, 2015 at 10:08 PM, Evan Hunt  wrote:

> On Wed, Sep 30, 2015 at 11:28:45PM -0400, Joe Abley wrote:
> > 1. Return an unsigned response. This will be marked as bogus, and
> > trigger a QTYPE=HINFO re-query that will either return an actual signed
> > HINFO from the zone or a signed proof of non-existence. We think. I
> > haven't actually tested that a re-query will happen, but Olafur is
> > confident. :-)
>
> I haven't tested it either, but that is not what I would expect.
>

Only validating resolver will send follow up query,



>
> If the resolver gets a bogus response to a query of type ANY, I
> would expect it to try the same query at another name server,
> until it had exhausted all authoritative name servers, and then
> reply with SERVFAIL.
>

Here is the deal there are 3 sources of ANY queries to authoritative
servers
a) Malicious ones  both direct or reflected flood via open resolvers
b) Someone debugging or trying to zone walk
c) Resolver forwarding a ANY query because the cache for that name was
EMPTY.

We need to look at each one  and
for a) what we return does not matter but it should be small as it is just
noise
for b) we need them to comprehend the answer
for c) we need the resolver to accept the answer and not send followup
queries when a)  or b) is the reason they got the query

HINFO meets all the goals for a) and b).
This leaves us with c) in the case when query source is a legitimate
application, but in this case the HINFO is a useless
information and the application should realize that this attempt at getting
something for free failed and fall back on queries for what it wants i.e.
MX and A +  records.

I used to be in the camp for TC bit but that was before I realized that
open resolvers/forwarders are quite happy to do TCP, meaning you get a
flood of TCP connections. TC only addresses the issue of direct forged
floods.


> > 2. Sign the HINFO RR as it is synthesised (or pre-sign one, to avoid the
> > edge authority servers needing access to a signing key).
>
> Pre-signing essentially reduces to adding an empty HINFO to every node in
> every zone, then using the pick-one-RRset method, but ensuring that HINFO
> is always selected first.
>
> > That is true. However, one of the use-cases for this approach is a
> > nameserver for which a search for records present at a particular owner
> > name (as would normally be performed when responding to an ANY query) is
> > expensive.
>
> It's not at all obvious to me that this is cheaper.
>

There is NO need to sign, unsigned HINFO returned for ANY query looks to an
validating resolver just like an
incomplete answer thus it can either return the HINFO or ask the followup
question for the HINFO and get a signed
denial that the HINFO exists ==> which looks like the HINFO was just
deleted from the zone i.e. temporal inconsistency.

The draft optimizes against a) and b) the the  cost of the possible extra
queries for c) when there is a validating resolver, which most of the time
might be a be answering out of cache thus it is not  forwarding ANY query.
The goal of the draft is to give resolvers something to cache. thus getting
help from the resolvers in deflecting the flood.
We wanted to optimize defending against the misuse of ANY query in attacks.
It is up to each operator to decide what to do and when.
Not having a well documented way to deal with this is  the main problem.

For off-line signed zones the auth server can copy this behavior of
"forging" unsigned HINFO and then dealing with the verification triggered
extra queries.

>
> With either method, you have to search down through the zone to find out
> whether the node exists (otherwise you'd be returning NXDOMAIN, rather than
> a minimized response).  Since you're doing that search anyway, choosing an
> RRset to return is pretty cheap.  And actually, you really *should* also
> look through the RRsets at the node to make sure there isn't a non-empty
> HINFO record before you synthesize an empty one, and if you're doing *that*
> anyway, choosing an RRset wouldn't cost any more and could well cost less.
>

Given the assumption that we are optimizing for defense there is no need
for an authoritative resolver to know if it is authoritative for the zone
the query was for, it can just return HINFO as an negative answer to the
ANY query type.

The whole question is around the following equation "ANY == ALL"
 I say ANY != ALL, your proposal was so say stop after first RRset found so
we agree on the core question the
only difference is on what to return.
In our proposal you are optimizing for c) without knowing if the type you
return is of value to the originator of the query,
furthermore your answer is likely to be larger.

For me answering few hundred ANY queries a second is not a problem (steady
state) ,
answering few millions a second is a problem (regular events) is.
Simple forwarders will keep asking thus what is returned does not matter,


> Assuming we aren't 

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[John R Levine]

On your system, I'm sure it works fine.  On other systems that
implement IPv6 in other ways, maybe not.


Which is why I think

https://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00

should be resurrected (not directly relevant to DNSOP of course).


Seems like a good idea.  I've got a dozen v4 loopback addresses on my 
server doing various useful things.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[David Conrad]

> On Oct 1, 2015, at 10:45 AM, John Levine  wrote:
> 
>>> Uh, no.  The *only* loopback address is ::1.  The rest of ::/8 is 
>>> reserved.
>> 
>> Anything is a loopback address if you alias it on your loopback interface.
>> 
>> ::2 was only intended as an example (that's why I said "salt to taste"),
>> but it was not a particularly well-chosen one.
> 
> On your system, I'm sure it works fine.  On other systems that
> implement IPv6 in other ways, maybe not.

Which is why I think

https://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00

should be resurrected (not directly relevant to DNSOP of course).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[George Michaelson]

Strong +1. This is an obvious, useful, rational and alas, strictly
irrelevant point. Which I agree with.

-G

On Thu, Oct 1, 2015 at 12:51 PM, David Conrad  wrote:

>
> > On Oct 1, 2015, at 10:45 AM, John Levine  wrote:
> >
> >>> Uh, no.  The *only* loopback address is ::1.  The rest of ::/8 is
> reserved.
> >>
> >> Anything is a loopback address if you alias it on your loopback
> interface.
> >>
> >> ::2 was only intended as an example (that's why I said "salt to taste"),
> >> but it was not a particularly well-chosen one.
> >
> > On your system, I'm sure it works fine.  On other systems that
> > implement IPv6 in other ways, maybe not.
>
> Which is why I think
>
> https://tools.ietf.org/html/draft-ipversion6-loopback-prefix-00
>
> should be resurrected (not directly relevant to DNSOP of course).
>
> Regards,
> -drc
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[John Levine]

>> Uh, no.  The *only* loopback address is ::1.  The rest of ::/8 is 
>> reserved.
>
>Anything is a loopback address if you alias it on your loopback interface.
>
>::2 was only intended as an example (that's why I said "salt to taste"),
>but it was not a particularly well-chosen one.

On your system, I'm sure it works fine.  On other systems that
implement IPv6 in other ways, maybe not.  I have a Windows 7 box and
as far as I can tell it doesn't even have a loopback interface, rather
some special case for 127/8 and ::1.  (Not ::2, I checked.)

It seems to me a rather poor idea for an IETF document to advise
people to use addresses that IETF standards documents say are
reserved.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-root-loopback-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group 
of the IETF.

Title   : Decreasing Access Time to Root Servers by Running One 
on Loopback
Authors : Warren Kumari
  Paul Hoffman
Filename: draft-ietf-dnsop-root-loopback-05.txt
Pages   : 11
Date: 2015-10-01

Abstract:
   Some DNS recursive resolvers have longer-than-desired round trip
   times to the closest DNS root server.  Some DNS recursive resolver
   operators want to prevent snooping of requests sent to DNS root
   servers by third parties.  Such resolvers can greatly decrease the
   round trip time and prevent observation of requests by running a copy
   of the full root zone on a loopback address (such as 127.0.0.1).
   This document shows how to start and maintain such a copy of the root
   zone that does not pose a threat to other users of the DNS, at the
   cost of adding some operational fragility for the operator.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-root-loopback-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-root-loopback-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Joe Abley]

On 1 Oct 2015, at 1:08, Evan Hunt wrote:


The disadvantages of pick-one-RRset that I can see are 1) more
information leaked (but nothing that couldn't be obtained by sending
queries for individual qtypes anyway), and 2) modestly larger response
size (but still a lot better than unminimized ANY responses).

Perhaps both approaches should be described in the draft.


I think I've run out of reasons why the HINFO approach is better than 
your pick-one idea, which mainly leaves us with the HINFO approach 
feeling a lot like a dirty hack that makes me want to shower, while 
yours gets the job done without needing updates to 1035, assuming we 
feel comfortable with the assertion that ANY doesn't have to mean ALL in 
the context of an authority server. I like it quite a lot. Sorry again 
to have missed it when you first brought it up.


Olafur had a particular code-base in mind as motivation for documenting 
this, and he may have some perspectives that I have missed. On that 
note, I will take a few steps away from the microphone.



Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[Tony Finch]

John Levine  wrote:
>
> If you have a loopback software interface, you could set up a link
> local address like fe80::1, but now your DNS software has to
> understand link scoped addresses like fe80::1%lo.
>
> Having set up a DNS cache on my LAN using link local IPv6 addresses, I
> can report that it doesn't work very well.

Yes, in July last year I reported bugs against several DNS packages about
lack of support for scoped link-local addresses.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Requesting WGLC of draft-grothoff-iesg-special-use-p2p-*

[str4d]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Christian Grothoff wrote:
> Dear DNSOP / chairs,
> 
> The same applies to the various P2P drafts:
> 
> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-
>
> 
bit/

Section 5, paragraph 3 - The example uses .onion, which I assume is
leftover from the original single document. It should be changed to
.bit in this document.

> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-g
ns/
>
> 
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p
/

Section 5, paragraph 3 - The example uses .onion, it should be changed
to .i2p in this document.

> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-e
xit/

Section
> 
5, paragraph 3 - The example uses .onion, it should be changed
to .exit in this document.

str4d

> 
> We would like the IETF to follow the same process it applied to
> .onion, especially given that the origin of these drafts pre-dates
> the .onion submission and they are equally technically justified,
> except of course that the urgency of the IAB .onion certification
> did not apply.
> 
> Naturally, we're also happy to receive constructive comments, but
> maybe 2 years of energetic discussions will finally suffice?
> 
> 
> Thanks!
> 
> Christian
> 
> On 09/13/2015 10:15 PM, Warren Kumari wrote:
>> Dear DNSOP / chairs,
>> 
>> We were requested to hold off on this document until the .onion 
>> document had completed it's process. As this has now been
>> approved, and lies with the RFC Editor, we are requesting WGLC
>> of draft-ietf-dnsop-alt-tld ("The ALT Special Use Top Level
>> Domain")
>> 
>> W
>> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWDhcTAAoJEBO17ljAn7PgGjUP/0oc1eIAuz4kBuUpPWaQkmLW
XhIAmOaIOMI1hOCoI23PnhWC4BAuWwHGweIavTpz4/y7wJPxZL9BjR3QLe08K7Yp
Ghc5O+gIwVFCeqC3z2679kQwGxvJ0KgeuELplPjhLIailXFYla4wI78fZNKFBcTL
sB+wG39dyfcXblOo/RbJUo93scRQCo27FgqIkBUYp8Nc/1j7cI28P8QoXFnIqgXT
dUlkCHZbg0KCCFAOlct0r5mz9qv8hB1VwWhYOVsmkfEofl3rEOt7LJeUB6yrp0op
r0IutByaZq9BShACjOHeXP/r5Vy+1RfGHxe0a2p4rlUHtBIumSgKkrnw9RhtcCg2
ut9trpbrYfn2vve8HFNOlVpMwNaoh8W3CPwQW7gVb1bdzKePXcpEHD0iv4FP4UTw
z6R8tED93ZurX0ILJIjWFMzpF0/h4FjrmNcehCYh3nNnAHrgFBiZVb0zr73kkYuT
FZf+e/9DibsGDzOOwcnIrYe+OnIUnyPN2k7yXhz0AUrts75xbY9mMVQmNGuiaDOl
9WfrFSoJpu1is2/flC5v4zqT6MXCovVtiv2bWiaC2lwgq+NjuyVcaTgONwkXNFqz
fLTEqGLW/Fes7z99iqZG2vepZLUYvzURcoYoku6EEVC0NBZ7aD2VRTaXrx1JA4D6
onInpRb/tUsgkqxG2zhX
=Vt/A
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Evan Hunt]

On Thu, Oct 01, 2015 at 09:02:09AM -0700, Ólafur Guðmundsson wrote:
> Only validating resolver will send follow up query,

Correct, but it would send them to every name server until it
got a non-bogus reply. This is unnecessary collateral damage.

> Here is the deal there are 3 sources of ANY queries to authoritative
> servers
> a) Malicious ones  both direct or reflected flood via open resolvers
> b) Someone debugging or trying to zone walk
> c) Resolver forwarding a ANY query because the cache for that name was
> EMPTY.

I see five categories.  Malicious queries can come in directly, or
through a resolver, or from a spoofed source.  Legitmate queries can
come in directly or through a resolver.

- With spoofed source queries it doesn't matter what we answer.  Setting
  TC=1 or dropping would be fine.

- With a direct query (from dig, for example) it doesn't matter what we
  answer. REFUSED would be fine.

- With a query from a resolver, we have to send an answer that the resolver
  will accept, so it doesn't keep trying; we also have to send an answer
  that will *not* impair the resolver's ability to resolve other names
  later.

The problem is, we can't perfectly distinguish between these categories.
DNS COOKIE will help to weed out the spoofed sources when it's deployed
widely enough to rely on, and DNS RRL will mitigate the damage, but things
will always get through.

I see no choice but to assume the least convenient case:  that a query for
type ANY is coming from a resolver which is passing along a query from a
legitimate client.

In order to avoid doing any harm to that presumptive resolver, we *must*
perform a database lookup to find out whether the qname exists and whether
it's below a zone cut, so we'll know whether to return NXDOMAIN, a
delegation, or a minimized response.  And if the zone is signed and
we're sending a minimized response, then it *must* include a valid
signature.

> There is NO need to sign, unsigned HINFO returned for ANY query looks to an
> validating resolver just like an
> incomplete answer thus it can either return the HINFO or ask the followup
> question for the HINFO and get a signed
> denial that the HINFO exists ==> which looks like the HINFO was just
> deleted from the zone i.e. temporal inconsistency.

It doesn't look like an incomplete answer; it looks like a *bogus* answer.
A validating resolver will react by sending the same query to every other
auth server for the zone until it gets something that validates.
Eventually it'll SERVFAIL, and at that point perhaps the application
will do something sensible, but we're wasting resolver resources in the
meantime.

> Given the assumption that we are optimizing for defense there is no need
> for an authoritative resolver to know if it is authoritative for the zone
> the query was for, it can just return HINFO as an negative answer to the
> ANY query type.

You've got to search the database for zone cuts, or you'll end up with a
resolver thnking example.com is authoritative for www.child-zone.example.com.

You've got to search down to see if there's a leaf node above the qname,
or the resolver won't be able to use a cached NXDOMAIN as a signal to
stop sending queries for descendant nodes in the future.

> In our proposal you are optimizing for c) without knowing if the type you
> return is of value to the originator of the query,

I don't care whether the response is of value to the originator; I'd
return no answer at all if I could.  (Unfortunately, NODATA for type ANY
is interpreted by some caches to mean "no data of any type", and REFUSED
wouldn't stop a resolver from asking.)

> furthermore your answer is likely to be larger.

Admittedly true.  Still an improvement over conventional ANY responses.

> If we agree that both are acceptable and each server only needs to support
> one of the two then that is fine with me.

Both are acceptable as long as we don't break the DNS.

I cannot support a proposal that does break the DNS.

If we do what's necessary to avoid breaking the DNS, then I don't
believe there's any practical advantage to the HINFO approach, but
I wouldn't oppose.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt

[Tony Finch]

Paul Hoffman  wrote:
>
> For this type of system, you want a hash or checksum function where
> finding collisions takes more than N attempts, and all of those attempts
> must be based on random guessing, not on some structure of the messages.
> N can be calibrated by the value of an attacker fooling you and the
> amount of time they have to create the collision. N=2^64 is probably
> sufficient for this attack because we still don't have a way to do 2^64
> guesses in a reasonable amount of time, and SHA-1 is still probably
> within that boundary. However, FNV (a non-cryptographic hash) has the
> same amount of collision protection but runs much faster.

FNV can be broken by a remote attacker - there are side-channel attacks
which leak hash randomization secrets. Python switched from FNV to
SipHash, which is about the same speed but a lot stronger.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop