Subject: [DNSOP] Using PTRs for security validation is stupid

From: Lee Howard <[email-masked]>
Date: Tue, 11 Nov 2014 17:48:25 -1000

Many SSH servers (by default) reject connections from IP addresses without
PTRs.
This is stupid.

I heard applause during the WG meeting in response to these statements;
sounded like consensus to me. I said I would check that consensus on list.

Thanks,
Lee

---

From: George Michaelson <[email-masked]>
Date: Tue, 11 Nov 2014 19:50:12 -1000

PTR checks for ssh on call-in is stupid.

But, putting ssh host keys in the DNS and not having to do that 'are you
sure? are you sure? are you sure?' dance from "Father Ted" is not stupid.

On Tue, Nov 11, 2014 at 5:48 PM, Lee Howard <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Nov 2014 20:07:31 -1000

On Nov 11, 2014, at 7:50 PM, George Michaelson <[email-masked]> wrote:
> But, putting ssh host keys in the DNS and not having to do that 'are you sure? are you sure? are you sure?' dance from "Father Ted" is not stupid.

Indeed.   But that is a completely 'nother thing.  :)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Nov 2014 22:30:58 -0800

> Lee Howard <mailto:[email-masked]>
> Tuesday, November 11, 2014 7:48 PM

(vixie indicates support of this view.)
> sounded like consensus to me. I said I would check that consensus on list.

i wasn't in hawaii so i'm adding my voice here, as well as this comment:

ssh is wizardware, it's not like a web server whose clients will lack
technical skills. almost all ssh server operators are aware that they
are ssh server operators, and know how to change this configuration knob
in their ssh server. almost all ssh client operators know their ssh
server operators on a first name basis and can pick up the phone and
explain why this configuration is stupid.

so, there is no installed-base or inertia argument which would keep this
kind of stupidity alive if it were happening in a non-wizardware service
such as e-mail or web.

-- 
Paul Vixie

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Nov 2014 21:30:36 -1000

> Many SSH servers (by default) reject connections from IP addresses without

dun't matter if it is stupid or not. dun't really matter if requiring
PTRs for mail servers, VPN servers, etc is stupid or not. What matters
is that "Many SSH servers (by default) reject connections from IP
addresses without PTRs" and that many mail servers require PTRs and
that fluffy bunny servers require PTRs. You, me, everybody in DNSOP
(or the entire IETF for that matter) deciding it is stupid doesn't
change what Billy Joe's mailserver does.

> sounded like consensus to me. I said I would check that consensus on list.

I think that there is consensus that it is stupid. There is also
consensus that using a fork to get the stuck toast out of the toaster
is a bad idea -- however....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Dan York <[email-masked]>
Date: Wed, 12 Nov 2014 15:59:37 +0000

Lee,

Warren, in his own unique style, made a point that I was wondering about...

On Nov 11, 2014, at 9:30 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

... namely that I think probably all of us on the list can agree 100% that having SSH servers reject connections from IP addresses without PTRs is stupid.   I haven't seen anyone chime in publicly that they think it *is* a good idea... and I doubt we will.

But now what?

I'm not sure that there's necessarily a whole lot of value in us coming out with a document "Using PTRs To Reject SSH Connections Considered Harmful" - I don't know that our doing so will necessarily motivate the authors of SSH servers to change anything. Certainly I think the SSH case could be listed in your document of bad things people do with PTRs in IPv4 that will break in IPv6.

Where are you trying to go with this note about consensus?

A bit puzzled,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 Nov 2014 06:07:53 -1000

The irony in SSH is that its a two way strongly authenticated connection.
 (assuming you do client keys) -So perhaps the sense of the story is that
where proof-of-identity is innately part of the exchange, it makes little
sense to deploy a barrier to entry like PTR checking, since you are using
significantly better protections against the wrong person being given
access.

PTR records permit IP address administrators with access to DNS
configurations to associate DNS names with their addresses. The informative
value this has should not be conflated with any stronger checks, and adds
little to the decision to accept a connection to a service beyond the log
value of the address holders assertion. If you chose to demand a
forward-reverse association to exist, you are very likely to exclude access
in situations you did not wish to.

-G

On Wed, Nov 12, 2014 at 5:59 AM, Dan York <[email-masked]> wrote:

>   On Nov 11, 2014, at 9:30 PM, Warren Kumari <[email-masked]> wrote:
>
> ... namely that I think probably all of us on the list can agree 100% that
> having SSH servers reject connections from IP addresses without PTRs is
> stupid.   I haven't seen anyone chime in publicly that they think it *is* a
> good idea... and I doubt we will.
>
>  But now what?
>
>  I'm not sure that there's necessarily a whole lot of value in us coming
> out with a document "Using PTRs To Reject SSH Connections Considered
> Harmful" - I don't know that our doing so will necessarily motivate the
> authors of SSH servers to change anything. Certainly I think the SSH case
> could be listed in your document of bad things people do with PTRs in IPv4
> that will break in IPv6.
>
>  [email-masked]   +1-802-735-1624
>  Jabber: [email-masked]

---

From: John Kristoff <[email-masked]>
Date: Wed, 12 Nov 2014 10:33:47 -0600

On Tue, 11 Nov 2014 17:48:25 -1000
Lee Howard <[email-masked]> wrote:

> Many SSH servers (by default) reject connections from IP addresses
> without PTRs.  This is stupid.

Which ones?  OpenSSH does not.  It has a 'UseSSH' option that is often
enabled by default, but all this does is log a message if the PTR name
of the client address doesn't match the address when the name is then
resolved.  Dropbear has it disabled in source code by default.  Tectia
behaves similarly to OpenSSH.

> I heard applause during the WG meeting in response to these
> statements; sounded like consensus to me. I said I would check that
> consensus on list.

I may be ignorant of context not having been there or having reviewed
any transcripts that may exist.  Is this a non-issue or a more pressing
issue somewhere else perhaps?

John

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 12 Nov 2014 06:37:39 -1000

kumari> I think that there is consensus that it is stupid. There is also
kumari> consensus that using a fork to get the stuck toast out of the
kumari> toaster is a bad idea -- however....

york> I'm not sure that there's necessarily a whole lot of value in us
york> coming out with a document "Using PTRs To Reject SSH Connections
york> Considered Harmful" - I don't know that our doing so will
york> necessarily motivate the authors of SSH servers to change
york> anything. Certainly I think the SSH case could be listed in your
york> document of bad things people do with PTRs in IPv4 that will break
york> in IPv6.

Yup... There is discussion in a couple of distro web sites on changing
this default but while most novice sysadmins will tend to use distros,
if they upgrade, it doesn't stomp the /etc files. That's usually a
feature. In this case, it means we're going to be living with this bad
default for a while.

But no reason not to talk to our friends that work on debian/freebsd et
al and have them change the default to at least not make it worse but it
will be around a while.

I would say that this is a situation where the part of the v6 PTR space
we seem to be more inclined to argue about (broadband/consumers) are
probably not being bit as much by this. Most won't use ssh and those of
us that do use ssh over v6 probably do know our friendly sysadmin (or
have ways of getting PTRs fixed by hand).

So as we resurrect the reverse mapping considerations draft, we point
out there that doing this check seems to be current default but that it
isn't useful/helpful? That and get the distros to fix the default?

---

From: Lee Howard <[email-masked]>
Date: Wed, 12 Nov 2014 06:58:23 -1000

On 11/11/14 9:30 PM, "Warren Kumari" <[email-masked]> wrote:

>>without

You've combined issues. Mail servers rejecting mail from unmanaged
networks (such as houses) is a feature. If an ISP doesn't publish PTRs,
mail server operators are unaffected.

>is a bad idea -- however....

Because it is stupid, toaster designers do not make sure that toasters are
fork-accessible.
We are not obligated to facilitate other people's stupidity.

Lee

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 12 Nov 2014 07:48:19 -1000

Lee, 

The usage case that got brought up at the mike “PTR records are used by logging systems” 
got me thinking “when does a logging system need this information” 
and the answer is I think “when a human is looking at the log” in all other cases if the system is running at 
high speed the delay in looking up addresses is just too long.
Thus I would say the usage case is “a log processing tool MAY do PTR lookups” 
the real information about addresses can be extracted from other sources as well like 
whois and geo-location data bases etc. 

The other usage case that I can think of is network debugging. 

Thus the real question in this case “what granularity in name is needed and when ?” 

Below is short list of of possible requirement based on the needs of these two “usage cases”

We all love having the names displayed by trace route for each hop ==> 
	names of router interfaces are a SHOULD in my mind 

We all want big services to have PTR records, this web servers, mail servers, etc. 
	Addresses that provide services SHOULD have a PTR record 

“End-user” addresses do not need a PTR record but could be simple wild card responses like “Customer.HNL.biz-ISP.net” 
as none is complaining about 
123.136.133.31.in-addr.arpa. 3600 IN	PTR	dhcp-887b.meeting.ietf.org.
or 
9.5.9.d.7.4.e.f.f.f.9.e.f.c.a.2.6.3.1.0.0.7.3.0.c.7.6.0.1.0.0.2.ip6.arpa. 15 IN	PTR s2001067c037001362acfe9fffe47d959.hotel-wireless.v6.meeting.ietf.org.

This message  raised some questions
On Nov 11, 2014, at 5:29 PM, George Michaelson <[email-masked]> wrote:

> I'll take a dollar for every query in PTR we take at the ipv4  /8 and Ipv6 /12 level. Thats somewhere around 170,000/sec.
> 
> Luckily, you'll all stop before I have the entire western economy in my pocket, but thats ok. I'll take the cents.. I'll take the millicents... 
> 
> Seriously: the volume of query is not small. It may be pointless but by golly its popular.
> 
> What do people do with it? I have no idea. But as long as people want to query, the RIR are happy to anchor the domains.
> 

That to me indicates that people use log post processing all the time and Intrusion Detection Systems are doing PTR lookups
by policy 
For IDS are their expectations any different than log processors?
and if IDS’s are taking decisions based on the content of PTR records what granularity do they need? 

  Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 13:13:57 -0500

> Thus I would say the usage case is “a log processing tool MAY do PTR lookups” 

There's no reason to suppose that the name a source has at the time
you look at the log is the one that it had when it performed the
action.  I think doing PTR lookups when processing logs is just a way
to introduce errors (just as doing PTR lookups when creating the log
entry is a way to introduce system overhead and delays).

If we're going to go through all of this again, I really do urge
people to look at the list archives from 2006-2008.  We went through a
lot about these use cases then.  You can reach back further if you
like -- the draft's filename once contained the word "required", which
is I suspect part of what hurt it so much.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Richard Clayton <[email-masked]>
Date: Wed, 12 Nov 2014 18:28:22 +0000

In message <[email-masked]>, Olafur
Gudmundsson <[email-masked]> writes

>whois and geo-location data bases etc. 

the only valid thing that a logging system can record is the IP address
(and of course in IPv4 the port number)...

... everything after that is almost always just informed speculation :(

whois tells you the beneficial user of the address block, it doesn't
tell you whose announcement your local router is using

geo-location is of highly variable quality ... one of the suppliers of
connectivity to West Africa recently changed their headquarters address
as recorded in the whois for their AS and suddenly lots of IP address
space moved from being in NG to being in MU (with a consequent impact on
all sorts of logging and heuristics at large mail handling companies!)

and of course the actual name that is returned is controlled by the
someone who is not necessarily trustworthy -- you can really confuse
neophytes by returning mail.google.com as the result of the reverse
lookup for some IPs that are nothing to do with Google...  which is why
of course the people who still believe in the value of PTR have to do a
reverse lookup and then come forward again in the hopes of a match.

This is my specialist subject, if bored there's lots more flawed
assumptions explained in my PhD thesis :)

>The other usage case that I can think of is network debugging. 

Yes and no ... all that extra traffic for lookups can get in the way!

but the software tools could be improved to translate addresses into
useful text without relying on the crutch of reverse DNS

>Thus the real question in this case “what granularity in name is needed and when 

What systems would actually like to know is "what range of addresses can
be considered to be the same as this one" ??

That allows them to start considering reputations and rate-limiting and
all the other sorts of things that we currently load onto single IP
addresses and which are the real problem to address with IPv6 -- as I
keep on saying, without apparently getting much traction :(

Now if that range gets some sort of human-friendly string when the data
is supplied that merely saves the receiving software from constructing
its own friendly string.  This may seem like a win, but I bet you it
isn't if you normally use Thai or Chinese glyphs on a day-to-day basis.

>       names of router interfaces are a SHOULD in my mind 

Traceroute is terribly geeky -- and unless you actually own the devices
being traversed (and understand all the other gear that your packets
traverse) the replies have considerably less value than most people
expect....

>       Addresses that provide services SHOULD have a PTR record 

I'm now puzzled ... where would you be doing a reverse lookup for a
server when you hadn't just done a forward lookup and would therefore be
able to keep track of what the IP address meant ???

Also... I suspect you're thinking that IPv6 servers will operate on
small numbers of addresses ... no reason for that, it might be
convenient to dish out a different IPv6 address for every DNS lookup,
and if so then the reverse lookups are going to be an expensive to
generate and cache nuisance -- so we ought to understand their value a
little better than just arguing that "you can do it in IPv4"

BTW: there is no sense in saying "you should not do in IPv4" that way
lies madness, but saying "but it won't work in IPv6" does seem helpful

>“End-user” addresses do not need a PTR record but could be simple wild card 
>responses like “Customer.HNL.biz-ISP.net” 
>9.5.9.d.7.4.e.f.f.f.9.e.f.c.a.2.6.3.1.0.0.7.3.0.c.7.6.0.1.0.0.2.ip6.arpa. 15 IN 
>PTR s2001067c037001362acfe9fffe47d959.hotel-wireless.v6.meeting.ietf.org.

It's not about complaining -- it's about saying "if you ask for a
reverse lookup you probably won't get a useful reply -- so think harder
about why you asked in the first place, it's probably just habit -- and
if you thought you were somehow creating some extra "trust" or
"security" then you are most likely rather mistaken. 

[...]

>> What do people do with it? I have no idea. But as long as people want to 
>query, the RIR are happy to anchor the domains.
>
>That to me indicates that people use log post processing all the time and 
>Intrusion Detection Systems are doing PTR lookups
>by policy 

If they're making significant decisions based on PTR records then they
probably need to be ground down into granules :(

- -- 
Dr Richard Clayton                         <[email-masked]>
                                  tel: 01223 763570, mobile: 07887 794090
                    Computer Laboratory, University of Cambridge, CB3 0FD

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 08:37:16 -1000

> behaves similarly to OpenSSH.

If there's no response to the PTR query, you have to wait 90 seconds for it to timeout.   Otherwise, you are correct.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 08:38:50 -1000

> feature. In this case, it means we're going to be living with this bad

As long as the file hasn't been tweaked, most distros will in fact updated it.   Unfortunately there are other defaults in /etc/sshd_config that are really harmful, so some people do update them, but I think most don't, and the ones who do can be trusted to further update it if they start getting complaints about PTR lookup timeouts.

---

From: Doug Barton <[email-masked]>
Date: Wed, 12 Nov 2014 10:43:23 -0800

On 11/12/14 9:48 AM, Olafur Gudmundsson wrote:
> The usage case that got brought up at the mike “PTR records are used
> by logging systems” got me thinking “when does a logging system need
> this information” and the answer is I think “when a human is looking
> at the log” in all other cases if the system is running at high speed
> the delay in looking up addresses is just too long.

In networks with users that have consistent, unique host names, but can 
get different IP addresses; doing the reverse lookup at the time that 
the connection occurred is necessary. (Such situations are common in 
enterprise networks.)

Doug

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 08:46:01 -1000

> Where are you trying to go with this note about consensus?

I will not speak for Lee, but where I would _like_ him to go is to simply point out the reasons why policies like this don't make sense.   We don't even need to tell people not to do it; just explain why it doesn't make sense, and trust them not to be stupid.   I will probably be laughed at for that last sentiment, but it's hard to get consensus on firm advice on this topic, whereas I think it's pretty easy to get consensus that:

- PTR records don't actually help with security for ssh
- The lack of a PTR record doesn't convey any affirmative information about the host that lacks it.
- The presence of a PTR record doesn't either.

And therefore, the three use cases that Lee put up on the slides yesterday can be usefully discussed, and the conclusions to draw are pretty obvious:

1. For SMTP, whether or not you think validating the reverse makes sense, the absence of a PTR record for a host that is not an MTA is okay.   However, you may want to add a PTR record containing valid information for hosts that do run MTAs, regardless of your opinion on what other MTAs should do with respect to checking PTR records.
2. For geolocation, PTR records containing bogus data are unhelpful at best, so there's no reason to add them to address this use case.
3. For ssh, PTR records are completely useless, so there is no reason to add them to address this use case.

There may be some other reason why a bogus PTR record is better than no PTR record, but we are at present not aware of such a reason.

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 12 Nov 2014 08:58:36 -1000

TLemon> There may be some other reason why a bogus PTR record is better
TLemon> than no PTR record, but we are at present not aware of such a
TLemon> reason.

There is the NYT web site case and may be others.

In the past, ISPs have just pre-populated v4 PTRs because it wasn't hard
to do in configs and it masked folks doing things like NYT.

This draft does give us a chance to see if that really is still at all
common. It it turns out that it really is just one or two large sites
and we can document it, that does give DNS folks at ISPs some ammo for
"fixing" something that "isn't broken", at least according to mgmt.

That ISP default isn't likely to change quickly but hard facts do go a
long way in such discussions. ;)

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 12 Nov 2014 09:10:21 -1000

ogud> The usage case that got brought up at the mike ``PTR records are
ogud> used by logging systems''  got me thinking ``when does a logging
ogud> system need this information''  and the answer is I think ``when a
ogud> human is looking at the log'' in all other cases if the system is
ogud> running at high speed the delay in looking up addresses is just
ogud> too long.

Depends on the environment and application. For enterprise and security,
seems more common to do PTR lookups in real time. For web sites and
really high traffic volume, more common to post-process.

ogud> ``End-user'' addresses do not need a PTR record but could be
ogud> simple wild card responses like ``[[Customer.HNL.biz-ISP.net]]'' 
ogud> as none is complaining about 

ogud> 123.136.133.31.in-addr.arpa. 3600 IN PTR [[dhcp-887b.meeting.ietf.org]].

ogud> or 

ogud> 9.5.9.d.7.4.e.f.f.f.9.e.f.c.a.2.6.3.1.0.0.7.3.0.c.7.6.0.1.0.0.2.ip6.arpa. 15
ogud> IN PTR
ogud> s2001067c037001362acfe9fffe47d959.hotel-wireless.v6.[[meeting.ietf.org]].

Other than mail/spam filtering, these do seem to work most
places. That's why ISPs have mostly gotten away with wildcarding PTRs in
v4.

ogud> That to me indicates that people use log post processing all the
ogud> time and Intrusion Detection Systems are doing PTR lookups by
ogud> policy  For IDS are their expectations any different than log
ogud> processors?  and if IDS's are taking decisions based on the
ogud> content of PTR records what granularity do they need? 

IDSs presumably have a more "known" and stable user population; things
that don't match that tend to be assumed as hostile. Not sure it's a
good assumption but I suspect most IDS teams assume that they (or at
least their organization) have some control over A/AAAA/PTR cleanliness
and response time.

Enterprises are also more likely to have their IP addr mgmt, DHCP and
DNS talking. This leads to higher quality PTRs than in consumer ISP or
wireless hotspot environments.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 09:17:11 -1000

> There is the NYT web site case and may be others.

'splain?   I'm not finding anything with google.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Nov 2014 14:57:16 -0500 (EST)

On Wed, 12 Nov 2014, Lee Howard wrote:

> networks (such as houses) is a feature.

There is no such thing as a "mail server". There are hosts on the
internet, and some of them send and receive email.

Access Providers love restricting features of their IP addresses.

It reduces human resources in the complaint department. Which we should
try to solve differently so access IP's don't need to be artificially
restricted.

If the access provider has a webfarm too, they have an incentive to
demote their access IPs in favour of their webfarm service.

The current anti-spam race is dangerous. We are forcing endusers to
do email via a select few mail providers. This encourages advertising,
centralised control and censorship.

We are already seeing a next step in this race. People hire something
cheap in a cloud like AWS. And those IP ranges have already started
to get their first "untrusthworthy" marks. Some VPN service providers
noticed that some cloud IPs are blocked for browing because often their
competition uses those cloud IPs to suck down a copy of their entire
website/datastore.

I fully understand the need to filter/ban misbehaving IP addresses. But
the PRT method is just so bad. The reason ISPs put stupid PTRs in there is
also to reduce cost/complains from their users. Those who blame the ISPs
are the ones that encouraged it by blocking things without PTRs. Extending
that to block "recognised auto-generated PTRs" is continuing a bad race.

It would not be too hard to write down something that would fix this for
SMTP.  We have DKIM/DNSSEC which is a much better method for determining
whether or not a message coming from an IP without PTR should be dropped
or not. If needed, the HELO could be extended so the receiving SMTP
server can present a cookie to be signed by the incoming SMTP server
based off a public key in DNSSEC for that zone. Which would allow an
SMTP server to refuse receiving the actual data.

Doing PTR records is actually more of a risk than a benefit.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Nov 2014 15:04:19 -0500 (EST)

> feature. In this case, it means we're going to be living with this bad

Actually, distros try to use a dir.d/*.conf type structure these days
for exactly this reason. It allows base options that are untouched to be
upgraded even if there are custom user options. openssn is one of those
that unfortunately does not support that.

> al and have them change the default to at least not make it worse but it

Distros tend to stick to upstream options. So for example if you want
this changed in fedora/rhel, you will need to talk to openssh because
according to their man page (for openssh-6.4p1-5):

      UseDNS  Specifies whether sshd(8) should look up the remote host name and
              check that the resolved host name for the remote IP address maps
              back to the very same IP address.  The default is “yes”.

Paul
ps. if you talk to them, please also get them to change the default for
VerifyHostKeyDNS= to "ask".

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 12 Nov 2014 11:11:58 -1000

ebersman> There is the NYT web site case and may be others.

TLemon> 'splain?   I'm not finding anything with google.

Not sure if it's still the case but did confirm a couple of years ago
that NYT web access breaks if you don't have some kind of PTR. Doesn't
matter what's in it; you just need non-NXDOMAIN response.

Never understood it but have talked to other operators who'd see this
too.

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 12 Nov 2014 11:21:04 -1000

paul> Actually, distros try to use a dir.d/*.conf type structure these
paul> days for exactly this reason. It allows base options that are
paul> untouched to be upgraded even if there are custom user
paul> options. openssn is one of those that unfortunately does not
paul> support that.

Thanks for the correction/clarification.

paul> Distros tend to stick to upstream options. So for example if you
paul> want this changed in fedora/rhel, you will need to talk to openssh
paul> because according to their man page (for openssh-6.4p1-5):

paul>      UseDNS Specifies whether sshd(8) should look up the remote
paul>      host name and check that the resolved host name for the
paul>      remote IP address maps back to the very same IP address.  The
paul>      default is "yes".

paul> ps. if you talk to them, please also get them to change the
paul> default for VerifyHostKeyDNS= to "ask".

I can ask...

But I'm also finding various "best practice" websites recommending
turning on VerifyReverseMapping.

Seeing shades of augean stables...

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 Nov 2014 11:23:53 -1000

I would be asking anyone who says VerifyReverseMapping on by default,
and VerifyHostKeyDNS
likewise, should justify their position.

Because the collective wisdom I'm seeing here is that its a false benefit,
and considering what SSH is, and what it seeks to do its rather sad to be
driven down a street which adds little (or nothing) and prevents beneficial
outcomes.

I agree its pushing back on razor wire, but maybe thats a 'take one for the
team' moment. If I knew the people I'd be pushing too. If I find I do know
people in this space, I will be.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Nov 2014 16:29:08 -0500 (EST)

On Wed, 12 Nov 2014, George Michaelson wrote:

> I would be asking anyone who says VerifyReverseMapping on by default, and VerifyHostKeyDNS likewise, should justify their position.

VerifyHostKeyDNS is about using SSHFP records in DNS. There is a clear
benefit unless you want to make a phone call every time you login to a
server you were never on before.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Nov 2014 13:35:14 -0800

> Paul Ebersman <mailto:[email-masked]>
> Wednesday, November 12, 2014 1:11 PM
> ...
>

fwiw, none of my home ipv6 clients have ptr's (SLAAC makes that
difficult), and i read NYT daily, no problems.

-- 
Paul Vixie

---

From: Bob Harold <[email-masked]>
Date: Wed, 12 Nov 2014 16:41:09 -0500

On Wed, Nov 12, 2014 at 4:35 PM, Paul Vixie <[email-masked]> wrote:

> It looks to me like NYT only has IPv4, so there might be a PTR on the IPv4
that your IPv6 gets translated to?

Bob Harold
umich.edu

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Nov 2014 13:46:30 -0800

> Bob Harold <mailto:[email-masked]>
> Wednesday, November 12, 2014 1:41 PM
>
>
> It looks to me like NYT only has IPv4, so there might be a PTR on the
> IPv4 that your IPv6 gets translated to?

all my home clients are dual-stack v4/v6. (i was comcast's first native
dual-stack customer, yay me!)

so if nyt doesn't have v6, then i'm reaching them over native v4.

-- 
Paul Vixie

---

From: Lee Howard <[email-masked]>
Date: Wed, 12 Nov 2014 12:22:05 -1000

I've done a little more digging on the Kerberos use case.

Here's an email thread from discussion whether to change the default
behavior:
http://mailman.mit.edu/pipermail/kerberos/2011-July/017313.html

The one person who explained his use cases also later said (in all caps) he
knew it needed to change eventually.

And here's the RFC saying it's wrong: rfc4120 (from that thread).

Lee

From:  George Michaelson <[email-masked]>
Date:  Wednesday, November 12, 2014 6:07 AM
To:  Dan York <[email-masked]>
Cc:  Warren Kumari <[email-masked]>, Lee Howard <[email-masked]>, DNSOP
WG <[email-masked]>
Subject:  Re: [DNSOP] Using PTRs for security validation is stupid

> (assuming you do client keys) -So perhaps the sense of the story is that where
> proof-of-identity is innately part of the exchange, it makes little sense to
> deploy a barrier to entry like PTR checking, since you are using significantly
> better protections against the wrong person being given access.
> 
> PTR records permit IP address administrators with access to DNS configurations
> to associate DNS names with their addresses. The informative value this has
> should not be conflated with any stronger checks, and adds little to the
> decision to accept a connection to a service beyond the log value of the
> address holders assertion. If you chose to demand a forward-reverse
> association to exist, you are very likely to exclude access in situations you
> did not wish to.
> 
> -G
> 
>> I'm not sure that there's necessarily a whole lot of value in us coming out
>> with a document "Using PTRs To Reject SSH Connections Considered Harmful" - I
>> don't know that our doing so will necessarily motivate the authors of SSH
>> servers to change anything. Certainly I think the SSH case could be listed in
>> your document of bad things people do with PTRs in IPv4 that will break in
>> IPv6.
>> 
>> [email-masked]   +1-802-735-1624 <tel:%2B1-802-735-1624>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 15:00:45 -1000

> matter what's in it; you just need non-NXDOMAIN response.

It is not doing this for IPv6 web queries (the IETF network isn't doing PTR records, and I'm on the nat64 network, so not going to the IPv4 www server).

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 15:02:56 -1000

> It is not doing this for IPv6 web queries (the IETF network isn't doing PTR records, and I'm on the nat64 network, so not going to the IPv4 www server).

<latella>Hm, I guess the IPv6 address I got for nytimes was a NAT64 address.   Nevermind.</latella>

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 12 Nov 2014 15:05:33 -1000 (HST)

On Wed, 12 Nov 2014, Ted Lemon wrote:

> It is not doing this for IPv6 web queries (the IETF network isn't doing 
> PTR records, and I'm on the nat64 network, so not going to the IPv4 www 
> server).

Actually it is.  I'm on the nat64 network and my address maps back to 
nat64.meeting.ietf.org.

-- 
Antonio Querubin
e-mail:  [email-masked]
xmpp:  [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 16:00:32 -1000

On Nov 12, 2014, at 3:05 PM, Antonio Querubin <[email-masked]> wrote:
> Actually it is.  I'm on the nat64 network and my address maps back to nat64.meeting.ietf.org.

That's the IPv4 address.   I was mistakenly thinking I was using an IPv6 address. :)

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 12 Nov 2014 17:37:16 -1000

Ted Lemon wrote:
...
> 3. For ssh, PTR records are completely useless, so there is no reason to
add
> them to address this use case.
>
I am not trying to justify their use, and have no specific knowledge about
how the practice got started, but would observe that 15+ years ago a ptr
existence check would have been a cheap dos mitigation technique given that
checking invalid credentials had  a large impact on cpu's of the day. It may
be worth pointing out that cpu cycles are cheap, and that the time /
networking resources needed to do a ptr check may now exceed the cost of
just accepting all connection attempts.

Tony

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 17:45:44 -1000

On Nov 12, 2014, at 5:37 PM, Tony Hain <[email-masked]> wrote:
> It may

That makes sense.