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

Martin Rex <Martin.Rex@sap.com> Fri, 27 July 2007 15:59 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESEK-0002Ie-93; Fri, 27 Jul 2007 11:59:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESEI-0002IU-Tu for tls@ietf.org; Fri, 27 Jul 2007 11:59:50 -0400
Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESEI-0007t7-90 for tls@ietf.org; Fri, 27 Jul 2007 11:59:50 -0400
Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA11594; Fri, 27 Jul 2007 17:59:22 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707271551.l6RFpb7W021006@fs4113.wdf.sap.corp>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
To: pgut001@cs.auckland.ac.nz
Date: Fri, 27 Jul 2007 17:51:37 +0200
In-Reply-To: <20070728032525.ziq6kvl6mk0sk0kg@webmail.cs.auckland.ac.nz> from "pgut001@cs.auckland.ac.nz" at Jul 28, 7 03:25:25 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

pgut001@cs.auckland.ac.nz wrote:
> 
> Jeffrey Altman <jaltman@secure-endpoints.com> writes:
> > Martin Rex wrote:
> >> If Public Key technology was more along the line of the original
> >> models of SSH and PGP, it would likely be used much more often.
> > You might want to read Alma Whitten's paper "Why Johnny Can't
> > Encrypt?".  Its a usability study that explains why PGP is not usable
> > for common folks.
> 
> If required I can add a shopping-list of other usability studies looking at
> why PKI in general is not usable for common folks.  There's a summary in the
> slides at http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf, and a
> really long analysis (100-odd pages total, although it covers lots of other
> areas as well) at
> http://www.cs.auckland.ac.nz/~pgut001/pubs/man_usability.pdf.
> 
> (Note that I'm not saying ditch PKI-based auth altogether, keep it if you
> want, but don't insist on making it a mandatory option in TLS if it doesn't
> work to protect users).

Joe Average also can not set up most things on his Windows PC,
but for the simpler tasks, people can help each other.
With PGP/SSH that has been possible and works fine.

A few years ago I tried to use S/Mime to have someone who had
S/Mime (but not PGP) configured send me stuff in an encrypted
fashion via Email.

I spent an hour until I gave up.  All implementations of S/Mime-capable
MUAs are so horribly broken that even someone with a technical
understanding runs into brick walls everywhere.

None of the MUAs (Outlook&Netscape Navigator) offered me to generate
a self-signed S/Mime capable certificate.
Trying to use existing or newly generated PKI-Credentials (which work
just fine with SSL and GSS-API) proved to be impossible because of the
braindead MUAs (it could be that it wasn't the MUAs fault but a
braindead S/Mime spec that was causing the headaches).


One of the problems with PKI that the technology is often
contorted to push CA business models.  And the other problem
is that it has overloaded "PK credentials" with bloat of the "policy"
category far beyond reason and is causing serious usability,
supportability and interoperability problems for everyone
who starts trying to use the technology for himself.


-Martin

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