Re: [tlug] SSH Issues

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

Curt Sampson writes:
 > On 2008-11-25 01:10 +0900 (Tue), Stephen J. Turnbull wrote:
 > 
 > > But no, HTTPS is *not* analogous to DNSSEC.  It serves many purposes
 > > without need of authentication or prior communication of any kind.
 > 
 > No, it does not serve those purposes, though there's a very common
 > illusion out there that it does. There are MITM attacks in the wild
 > based around exactly the common idea that you still have encryption
 > without authentication.

So what?  I mentioned how those attacks work in my reply to the OP,
and obviously they apply to HTTPS, too.  I didn't say HTTPS with
self-cert works for *all* purposes (for example, my bank had better
authenticate as well as encrypt).  But I really don't worry that
somebody's going to go to that much trouble to borrow my Slashdot
password and post derogatory comments about you or President-elect
Obama.  I'm much more worried about the DVD-writers attached to PCs at
BofA (and angry about the ones installed to banks in Tokyo that have
already been used to leak 10,000s of account holders' private data)
than I am about my HTTPS usage in general, despite most of it being
to sites with self-certs as far as I know.

You're making two elementary mistakes here, which are (a) to assume
that less than the best security you can get is not security at all,
and (b) that you can analyze a security protocol in the absence of a
statement of the goals of the system as a whole.  That's OK in a toy
textbook example, but not when you're making global statements about
protocols.

 > I don't have time to dig up the various blog entries

http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

 > In other words, you should assume that, unless you've *authenticated*
 > the other end of an HTTPS connection, you should assume that it's quite
 > possible you're talking to an attacker in the middle who's evesdropping
 > on everything you do.

Of course.  I do.  (There's a funny existential story to go with that,
but that requires beer. Remind me.)

 > > So I don't understand your analogy.  What purpose does DNSSEC serve if
 > > the data being received is not being authenticated?
 > 
 > None. Just as with HTTPS.

As I explained above, you're wrong.  For some purposes, TLS with
self-certs is "good enough security".  For others, a fresh Verisign
cert is not good enough.  It is *not* your place as security expert to
make that determination globally, you have to know what the purpose
is.

 > You're thinking of something different here. See my example above.

You're right, I was thinking of something different.

 > > As HTTPS shows, authentication is not the only use of cryptography in
 > > network security.
 > 
 > As HTTPS shows (see above), encryption without authentication does not
 > protect against eavesdropping.

Again, you're missing a quantifier there.  It protects against
"casual" eavesdroppers on an ethernet, but not against attackers who
can suborn a gateway.  Encryption *with* authentication protects
against a suborned gateway, but not against an attacker with a
subpoena.  And so it goes.

 > I guess it's not explicable to me what DNSSEC would be used for
 > besides authentication.

So what?  Especially in security imagining the impossible as an
explanation for the improbable is an important skill. ;-)

 > It's not, because with DH, as with HTTPS above, you're subject to
 > MITM attacks unless you can authenticate the remote end. Thus, you
 > need some out-of-band information that indicates that you're
 > talking to whom you really think you're talking to, and not an
 > attacker.

No, you don't always need that.  Sometimes you only care about getting
authentic information, and the information is self-authenticating (ie,
without reference to who provided it).  Eg, I really don't care if
somebody steals my MacPorts Trac password; I only use it to report
bugs, and *want* all the data (except my password) to be made public.
If I then see the bug page with my report, that's all I care about.[1]
MacPorts has been authenticated, not as the identity of my HTTPS
partner, but rather as the recipient of the data I sent.

In fact that is what you claimed about about DNSSEC at one point (that
the user doesn't care what server they got it from), although you
later made qualifying statements about authenticating the source.


Footnotes: 
[1]  Strictly speaking, I do care about possibility that somebody
might gain entrance under my password and vandalize the site, but if
they do that with my password, most likely they have passwords of lots
of other people, too.  Dilution of responsibility....
Also, note that this is a hypothetical.  I would guess that MacPorts'
Trac has a certificate from Apple or a 3rd party, and I'm not seeing
it because Firefox is sucessfully verifying it.