Re: [TLS] TLS, PKI,

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 14 July 2010 11:56 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDFF3A696E for <tls@core3.amsl.com>; Wed, 14 Jul 2010 04:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3bT1Z8jPlo7 for <tls@core3.amsl.com>; Wed, 14 Jul 2010 04:56:25 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 49E703A688C for <tls@ietf.org>; Wed, 14 Jul 2010 04:56:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1279108596; x=1310644596; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20Bruno.Harbulot@manchester.ac.uk,=20tls@ietf.org |Subject:=20Re:=20[TLS]=20TLS,=20PKI,|In-Reply-To:=20<4C3 DA1C5.1030406@manchester.ac.uk>|Message-Id:=20<E1OZ0Zf-00 02L6-Uj@wintermute02.cs.auckland.ac.nz>|Date:=20Wed,=2014 =20Jul=202010=2023:56:27=20+1200; bh=ziEacEBCCOmvmxnemG8KWeSYRHZGLzLFpED4o4ColjU=; b=KaYCSvVrGnPtZHJ5CiNps9bWd1QRe+9MnX06eJWpL1Suer4dbfidf21Q EiTjwwlbieN2Wvd4HcLdZMYoX4ng15Bt5X9teKbLuNHSxACfbUqAV33Ad yGfTSIN65bxQ5MtswzQ6UdgmzWtF3F05AqjWE47cMW6s3/iWqpbzykyN8 Y=;
X-IronPort-AV: E=Sophos;i="4.55,201,1278244800"; d="scan'208";a="15517360"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing
Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jul 2010 23:56:28 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1OZ0Zf-0002L6-Uj; Wed, 14 Jul 2010 23:56:27 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Bruno.Harbulot@manchester.ac.uk, tls@ietf.org
In-Reply-To: <4C3DA1C5.1030406@manchester.ac.uk>
Message-Id: <E1OZ0Zf-0002L6-Uj@wintermute02.cs.auckland.ac.nz>
Date: Wed, 14 Jul 2010 23:56:27 +1200
Subject: Re: [TLS] TLS, PKI,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2010 11:56:29 -0000

Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> writes:

>I wonder how many people really check the fingerprint of the SSH server key
>when they connect to a server they haven't connected to before.

I don't know about connecting to new servers, but if the fingerprint changes
when connecting to an existing server then the same number check it as the
number who perform out-of-band verification of certs when they change: Zero.

(I did a survey of two large .edus as groundwork for a paper I was thinking of
writing and needed to know the base rate for a fuzzy-fingerprint attack, which
allows you to spoof SSH server fingerprints unless the user methodically
verifies all 160 bits of the fingerprint.  It was zero, which meant that the
fuzzy-fingerprint attack couldn't be any worse than that.  This lead to a
proposed paper with the title "Do users check SSH fingerprints to defeat MITM
attacks?" and an abstract of "No", which I felt was brief and to the point).

This result represents good news for both the SSL/TLS PKI camps and the SSH
key-continuity camps, since SSH advocates can rejoice over the fact that the
expensive PKI-based approach is no better than the SSH one, while PKI
advocates can rest assured that their solution is no less secure than the SSH
one.

Peter.