Re: [tlug] SSH Issues

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > It's your (trusted) resolving server that's normally doing the
 > authentication,

*snort*  I don't trust any of my local servers as far as I can throw
them (their polices are all set by people with the fine political
sensibilities and practical ability to get things done of Aso Taro),
and the ones I have access to aren't doing authentication that is
visible to me (no "ad" flags, even though the "do" flag is present).  

 > and the libc resolver just relays whether the server claims to have
 > authenticated the records or not.

Based on your description I expected that (if it worked) I would see
an indication that the RRSIG RRs had been checked against the data
they're signing, not the RRSIGs themselves.  It's not very useful to a
human (non-debugging) user to see the RRSIG RRs most of the time, and
I didn't ask for them (ie, I asked for type=A, with +dnssec option; I
would think that if I want to see RRSIGs I can ask for type RRSIG
records).

A little digging into the RFC shows that the authoritative server just
returns the RRSIGs, and doesn't set the "ad" flag.  That's why your
server spews when I query it directly, I think.  This seems a bit
unfriendly to the users in the domain of the authoritative server!

Unless the resolver library can do the validation.  I would be very
surprised if dig *can't* do the validation of the RRset against the
RRSIG record.  After all, a recursive server presumably uses the same
resolver library.  And dig is supposed to be the Swiss Army knife of DNS.

 > > But on Gentoo there doesn't even seem to be a USE flag for resolver v9
 > > for bind-tools (ie, the package that provides dig).
 > 
 > I would think it's automatic; bind9 dig has always, for me, used the
 > bind9 resolver library.

Well, I would think that too!  But bind-tools is a separate package
from bind.  I don't know if contains the resolver library or not
... maybe it does since ldd says dig doesn't link to libresolv.so.
Seems weird that bind-tools wouldn't install the library it links to
*somewhere*, though.

 > > Borrow enough of the OpenSSH code to get the host's public key, say
 > > "thank you", maybe-replace the key into the known_hosts file, and call
 > > SSH for real, maybe?  That much of the protocol can't be all that hard
 > > to get "good enough", can it?
 > 
 > As I mentioned, that's pretty much exactly what we do. No need to borrow
 > source: the ssh-keyscan will give you back the known_hosts entry.

OK.  But you specifically wrote

    So we can go from known_hosts entry to SSHFP record, but not the
    other way.

implying you were looking in the known_hosts file, and I mistakenly
assumed that is populated with all the keys in the domain.  When you
are actually getting the key from the net I would expect "so we can
go from *host key* to SSHFP record, but not the other way."

 > it's a bit of a pain, no? And it's also not secure to rely on comparing
 > the result against the SSHFP record unless you can authenticate the
 > SSHFP record.

Of course it's a bit of a pain, SSH can do all this stuff
transparently so you sure as shootin' want it to do so.  The question
has been workarounds for systems which don't allow SSH to organize the
work.

As for authenticating the SSHFP record, you can do that with the RRSIG
record, AIUI.  Which you *should* be able to get using the "cd" flag
(but again, this doesn't work for me).  No?

 > > Getting it fixed is hard enough, but forget about getting it deployed.
 > > A real fix would involve a full move to BIND 9 resolver in glibc....
 > 
 > glibc is still using the BIND 8 resolver?

No, it's not.  The /usr/include/resolv.h (and the absence of
/usr/include/resolv8_compat.h) pretty strongly suggests that the base
is BIND 8, but there are clearly a lot of extensions.  Which is
undoubtedly part of the upgrade problem.  And unfortunately for your
application, none of those extensions happens to be DNSSEC.

Anyway, I would think that you could build SSH against the BIND 9
resolver library.  A bit of a PITA for the users, but doing that would
give all your SSH apps the benefit of Just Working with your domain, no?

 > > Geez, Curt, you of all people should know that that is presumably
 > > exactly the braindamaged process that led to the current impasse:
 > > people unwilling to wait for a full move to BIND 9 adding a few
 > > features *they* thought were "critical bug fixes" (because they'd been
 > > personally inconvenienced) to the resolver code....
 > 
 > This is not just "personal inconvenience;" it's a security issue.

I didn't say otherwise.  What extensions I see are stuff like IPv6,
though, and that is not security per se.  Nor is this something that
can be secured by releasing a patched libresolv, as you point out
yourself.  You're not secure until the admins start using secure DNS,
which they could do at any time whether we upgrade libresolv or not,
but they haven't bothered to.

I'm not defending GNU libc's past mistakes; I'm linking the *way* that
those mistakes occurred to their present state of stasis.  And I'm not
saying that something shouldn't be done.  I am saying that this is not
"incoming ICBM" urgent, and that attention to process is required.

 > > But a move to BIND 9 is not the kind of thing you can do in a quickie
 > > patch, especially not if you want to claim the security stuff is going
 > > to work.
 > 
 > Actually, the security stuff in the resolver is not nearly as tricky
 > as you make it out.

Well, it is certainly tricky enough that it DOESN'T WORK as you
described it on Gentoo.  Although it may do so on Ubuntu, that doesn't
prove it works as expected on Debian, or even RHEL and SuSE.  It may
be a doc bug; email messages are notoriously unreliable documentation.
Even yours. ;-)  Still it does not leave me with a good feeling.

In the late '90s I got a call from our Chairman of the Computer
Committee.  He'd gotten an email complaining that my host was being
used as an open relay.  This confused me greatly, as I had carefully
set up my MTA (Smail 3.101) to not relay.  Well, I shut it down,
firewalled the spam source (in those days, that was good enough for a
couple of days or so), and then tested it and indeed it was an open
relay.  After looking at the code, I realized that the "do not relay
for any remote host" flag was being correctly parsed out of the config
file, stored in the config db, and then *never referred to again* for
the remaining life of the smail process.  Thank you, Debian.

I do not *ever* want to experience that again.  Advertised security
features that don't work are *worse* than the absence of the security
feature.

 > And while I understand that the move to the bind9 resolver is
 > non-trivial I would trust it to be correct

For the particular security issue, yes.  But how about making sure it
works in combination with the other programs that are expecting the
traditional BIND 8 APIs, etc etc etc?  How about the unobvious feature
that you *must* delegate the authentication to a *local* server to get
the "ad" flag set?[1]  It's not just a question of algorithmic
correctness, as you well know; it's migrating all that code---and the
brains that maintain them---to the new regime.

Footnotes: 
[1]  For those not in the know, all the "ad" bit *can* do is prove
that there is no man-in-the-middle attack occuring.  The authoritative
server cannot authenticate the data it sends itself, that's axiomatic.
Either you trust it (eg, because you have its key-signing key through
a trusted channel and you validate the record-signing key with that),
or you don't.  If you don't trust it, then it is trivial for that
server to simply change its data in any way it likes and then sign it.