Re: [tlug] SSH Issues

[Curt Sampson <cjs@example.com>]

On 2008-11-19 10:40 +0900 (Wed), Stephen J. Turnbull wrote:

> 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).  

Which is why we run Linux and our "local" server is the one running on
our own laptop.

>  > 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.

Correct. I normally don't see the RR records in a dig query to my
resolving server.

> 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.

Exactly correct.

> This seems a bit unfriendly to the users in the domain of the
> authoritative server!

I'm not sure what you mean by "users in the domain" of a DNS server, but
this is the way it is for two good reasons:

    1. It opens up an easier denial of service attack, since you
    can force the host to use significant CPU by demanding that it
    authenticate a lot of records.

    2. Authoritative servers should never resolve anyway; it's a
    popular vector for DNS spoofing attacks.

> ...implying you were looking in the known_hosts file, and I mistakenly
> assumed that is populated with all the keys in the domain.

No, normally my known_hosts file never has any cynic.net. records in it.

> 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?

Hm, so add RRSIG validation to OpenSSH? That's a thought.

> 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.

Well, one of the reasons they perhaps haven't bothered to is issues like
this. Had I been on Linux boxes instead of NetBSD boxes back when I was
setting all this up, I almost certainly would have bailed on the effort.

>  > 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.

I am a) not sure that it didn't work correctly, since I'm not sure of
the exact details of what you did, and b) even if something was wrong,
I'm not sure it was the resolver library's fault.

Passing on to an application whether or not the AD bit is set is not a
particularly difficult thing.

> How about the unobvious feature that you *must* delegate the
> authentication to a *local* server to get the "ad" flag set?[1]

Actually, it's unobvious to those not familiar with DNSSEC, but if you
consider the system as a whole, and where the computing power lies, it's
actually a pretty reasonable way to set things up.

I thought DNSSEC did a lot of things in suboptimal ways, too, when I
first started with it. Experience has taught me that in most cases the
issue was that I didn't understand the system well enough.

> The authoritative server cannot authenticate the data it sends itself,
> that's axiomatic.

Sure it can. So long as it has the public key, it can check the signatures.

> 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.

This embodies a fairly major misunderstanding of DNSSEC. Authoritative
servers don't sign anything; they serve already signed records. They
have no need for the private key, and it would be considered very poor
practice to leave your signing key lying around on your authoritative
servers.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com