Re: [TLS] the use cases for GSS-based TLS and the plea for integrating

pgut001@cs.auckland.ac.nz wrote:
> 
> Kyle Hamilton <aerowolf@gmail.com> writes:
> > Why wouldn't the SSH paradigm work here?
> 
> You mean "connect to anything listening on port 22, then hand over your
> password in the clear (inside the SSH tunnel)"?  How does it differ from the
> current phishing-enabling TLS usage of "connect to anything listening on port
> 443, then hand over your password in the clear (inside the TLS tunnel)"?
> 
> (You're assuming that people check SSH key fingerprints.  Please cite a real-
> world usability study supporting this assumption.  NB: That's a booby-trapped
> question :-).

Nope.  SSH automatically verifies the peers public key for your for EVERY
but the first connect.

You may use other out-of-band means to distribute the hosts SSH key
besides answering the "do you confirm the fingerprint" on a first
connect to a host.

IMHO, one should only do the leap-of-faith if oneself has decided
to perform an initial connect, and one should probably not do it
when being asked by someone else to do it (to connect now).

If you use PK-based instead of password-based client authentication
with SSH, then you will at least to "disclose" a password accidentally.

The underlying problem of bootstrapping the authentication process
can not be avoided, independent of whether the authentication uses
asymmetric crypto, symmetric crypto, or is a disclosing authentication.

Using a pre-shared secret (like a password) to bootstrap a stronger
PK-based authentication such as that from SSH is a possibility.
In this scenario, however, the encrypted SSH tunnel is not magic
Pixie dust that can fixed the security problem of that pre-shared
authentication scheme that is being used to bootstrap.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls