Re: [tlug] SSH Issues

[Curt Sampson <cjs@example.com>]

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

> That doesn't matter, except to make you overconfident that you
> are the only person who understands what this conversation is about.

Well, I'll freely admit that you appear to be deliberately trying to
slew the argument away from what I'm trying to talk about, here.

> IMO, this is not an issue of cost/benefit; this is a professional
> ethics issue.

Which is, in turn, a cost/benefit issue. It's not professional to spend
a lot of time on something that gives little value to the client, and in
turn ignore other things that would give the client more value.

>  > > Er, who said it was the library's "fault"?  My main point is precisely
>  > > that even if the library is correct, that doesn't guarantee anything
>  > > is going to work.
>  > 
>  > Will it break things? In what way?
> 
> I already told you my sad Smail story.

Indeed. So, you have anecdotal evidence that something broke in a
completely different situation, and you've decided based on that, and
admittedly very little knowledge of DNSSEC, that supporting the AD bit
in queries is a highly risky move.

You'll excuse me if I don't find your evidence compelling.

Don't take that as not agreeing that the risks should be managed: take
that as disagreeing that, in this particular case, they have been
managed well.

> However, you were complaining that glibc is dragging its feet....

Which they are. If this feature were only a couple of years old, I could
understand it. But waiting this long to make the change, and in the
meantime steadily diverging in features, bugs, and Lord knows what else
from what is essentially the reference implementation of a resolver, is
not a good thing. And particularly when it's such a low-risk feature.

>  > As does your "validation"; in both cases you trust that the data were
>  > generated by some particular source.
> 
> Of course it *doesn't*!  That's precisely why I used the term
> "validation".  Validation, as you know, is merely a mechanical
> procedure of checking the result of running an algorithm on data.
> Cf. "validating XML process."  Authentication is similar, but includes
> the additional semantics that a successful validation implies that the
> some claim about the data is verified (not necessarily the source!)

Well, "duh."

I was, here, assuming that in our example we had the rest of the
cryptographic system set up. Without giving you exact configuration
files and pages of details about key management throughout my company,
you can always argue that it's "just validation." If your point is
simply to poke holes in my argument so you can say you've "won," usenet
style, you're using a great job. But, as is usual with these sorts of
things, you will learn little, I'll get frustrated, and nobody will
benefit.

> You write "N.B.: this source is *not* the authoritative server. It's
> the administrator of the zone."
> 
> So, evidently your claim is that "If the 'ad' flag is set in the reply
> received by the originating client, the records received are authentic
> in the sense that it is confirmed they were provided by the zone
> administrator."  I do not believe that the DNSSEC standard makes such
> a strong claim.

That is not my claim at all. Blinded by your ignorance of DNSSEC
and your wish to "win" here, your are picking the most uncharitable
interpretations of my words.

> If that's not your claim, precisely what do you claim?

I think at this point that no further enlightenment will come of me
trying to run a DNSSEC tutorial for you on this list, and it would cost
me a lot of time. If you wish to to come up with what you think someone
smart, rather than an idiot like me, would be claiming here, feel free
to post it and I'll let you know what you got right and wrong.

But if you want a hint as to where you are going wrong, just re-read
this again, carefully, and try to understand it:

>  > And I'm telling you again, that is entirely wrong. When it comes to
>  > DNSSEC validation (i.e., the authentication of the records), you do not
>  > care in the slightest from what server the records came; you do not
>  > trust the server. All you are doing is checking to see if the records
>  > are correct or not, regardless of the server whence they came.

And just to clarify:

> What do you mean by "correct"?  "Valid" or "authentic"?

That depends on whether you know what public key you're supposed to be
using to validate them.

> And if "authentic", do you mean that the authentic source is the zone
> admin, or that the authentic source is an IP address, or that some
> other claim about the data has been authenticated?

The authentic source is someone with the private key matching that
public key.

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