Re: [tlug] SSH Issues

[Curt Sampson <cjs@example.com>]

On 2008-11-24 16:48 +0900 (Mon), Stephen J. Turnbull wrote:

> Stephen J. Turnbull writes:
> 
> Oops.  lwres *is* BIND.

Oh, is that the lwres you were talking about? Yes, it is. For some
reasonable notes on the interaction between this and DNSSEC, see:

    http://www.cafax.se/dnssec/maillist/0000-00/msg00004.html

On 2008-11-24 19:43 +0900 (Mon), Stephen J. Turnbull wrote:

> You have a strange understanding of *professional* ethics.  It is of
> course unethical, whether you are a professional or not, to misuse
> others' resources.

I think I have the same understanding as you. And I still don't think
it's unethical not to install and run DNSSEC in a very large number
of cases. I would also claim that, understanding better than you what
DNSSEC does, having installed it myself, and having followed the various
politicial issues relating to it for some time, I'm in a much better
position than you to determine whether it's ethical, as a sysadmin, not
to set it up.

> Ah, thank you.  So I'm supposed to have a public key *in advance* and
> install it in software under my control.

Yes. Just like every other cryptographic authentication system in
existence, you can't do authentication unless you start out with some
trusted key material of some sort. This is nothing to do with DNSSEC;
this is basic cryptography.

> That clears everything up. So DNSSEC is really about not about the
> public Internet, but rather about communication within organizations,
> in the sense that the parties have to cooperate *before* they can use
> it.

In the same sense that https is, yes. In other words, no, if I'm
interpreting correctly these sense for which you seem to be reaching.

DNSSEC has its own delegation and chain of trust mechanisms, which
people can use as they wish or not, and depending on who else is
co-operating. Just like SSL, PGP, etc.

> Sure, you mentioned keys in your original post.  But something this
> important bears stating clearly and repeating, maybe?

No, no more than "you have to be plugged in for the Internet to work"
bears repeating in a discussion about whether you should be using TCP
or UDP to deal with latency issues. This is really, really basic stuff,
Stephen. If you're going to argue with me about the potential security
effects of enabling the AD bit in the resolver library, you need to be
starting at a much higher level than this.

As an example, I do note that we've had during this conversation several
discussions about dealing with SSH, and you've never either brought up
this exact same issue, nor complained about others not stating it.

> And the only thing uncharitable about it was collecting most of what
> you wrote in one place, and paraphrasing it in a relatively precise
> way.

It was not at all precise. In fact it was wrong, because you paraphrased
based on some sort of entirely different context, and attributed to me
paraphrasings that no sensible person knowledgeable about DNSSEC, or
possibly even cryptographic authentication in general, would make.

As for this:

> What I was missing was that having the key installed locally in
> advance is necessary for it to work at all.

1. You perhaps need to go back and learn the very basics of
cryptography. As I mentioned above, you simply cannot authenticate
cryptographically without some sort of pre-shared secret, somewhere.

2. In fact, the statement you make above is not strictly the case,
in that you can gain many benefits from DNSSEC without even doing
authentication on your machine. But that starts to get into a lot of
details and analysis that I don't care to spend an hour or two going
into right now.

> (No, that's not obvious on the face of it: Diffie-Hellman and all
> that. Doesn't work in this case....

That Diffie-Hellman requires just what I've been talking about above,
and DNSSEC could even run on top of it instead of RSA, which works
identically in principle, is exactly what I'm talking about here. If
you're trying to say that there is a case where Diffie-Hellman can allow
you to authenticate someone or something without some sort of trusted
key material, you're just dead wrong.

> I don't need a tutorial....

I'm sorry, but yes you do. At this point, your requests for me to "work
a little harder to be precise in [my] statements" are a request for just
that.

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