Re: [TLS] TLS, PKI,

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 16 July 2010 04:08 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 5DADA3A6452 for <tls@core3.amsl.com>; Thu, 15 Jul 2010 21:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.306
X-Spam-Level:
X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_40=-0.185]
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 teWPTDzigjAB for <tls@core3.amsl.com>; Thu, 15 Jul 2010 21:08:18 -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 D79063A6405 for <tls@ietf.org>; Thu, 15 Jul 2010 21:08:17 -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=1279253309; x=1310789309; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20aerowolf@gmail.com,=20tls@ietf.org|Subject:=20Re: =20[TLS]=20TLS,=20PKI,|In-Reply-To:=20<4C3FBB5C.2020401@g mail.com>|Message-Id:=20<E1OZcDn-0004x5-Pa@wintermute02.c s.auckland.ac.nz>|Date:=20Fri,=2016=20Jul=202010=2016:08: 23=20+1200; bh=ffj0jlw2l8CAbk5PMqcC2WZF82N4e+dlqcpQ8Chf72U=; b=KHUE4gr+e2eCa9T70w7zGE2/bE+iM/6m6RZKiKhOz5zn/pGfBpm1mBx8 tfu4tTCDOdjU0QBp8h7Fa3TGyOl6x4hqOQNaK4xGZpfy4Y2MiefADrmWV 2Gii006LYMRbsrF7Hpm7abqFjEJtNyTKWnzDcJdrELKvaZmfgff8AigpL w=;
X-IronPort-AV: E=Sophos;i="4.55,212,1278244800"; d="scan'208";a="15814227"
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; 16 Jul 2010 16:08:23 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1OZcDn-0004x5-Pa; Fri, 16 Jul 2010 16:08:23 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: aerowolf@gmail.com, tls@ietf.org
In-Reply-To: <4C3FBB5C.2020401@gmail.com>
Message-Id: <E1OZcDn-0004x5-Pa@wintermute02.cs.auckland.ac.nz>
Date: Fri, 16 Jul 2010 16:08:23 +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: Fri, 16 Jul 2010 04:08:19 -0000

Kyle Hamilton <aerowolf@gmail.com> writes:
>TLS has several modes which are unsupported by the members of this list:
>
>1) A supported (by the standard) mode of "unauthenticated TLS" (neither
>the server nor the client offer or demand certificates).
>2) Mutual Authentication -- it's supported by this group in the
>protocol, *except* that very few clients who actually have certificates
>typically don't have the marketing acumen to show just why they might be
>useful.
>3) The classic "server authenticates, client doesn't" issue 

Just to be pedantic, what you're describing in (2) isn't mutual authentication 
but unilateral authentication in both directions, which is just as phishable 
as (3) is.  Real mutual authentication is TLS-PSK and TLS-PSK.

>X.509:08/2005 is 174 pages long, including 39 pages of text that is not
>characterized as being contained within any RFC ('non-normative annexes'
>and the roman-numeral pages at the beginning, a blank page, and the
>title page).  That's 135 pages of actual normative content.
>
>RFC 5280, on the other hand, is 152 pages.  This means... THE NORMATIVE
>INTERNET PROFILE FOR X.509 IS LARGER THAN NORMATIVE X.509 ITSELF.  This
>is as close to 'insane' as I can find myself thinking about standards
>bodies (in this case, the PKIX WG).

Not only that, but the PKIX standing committee has so far produced one 
thousand seven hundred pages of PKI standards with a further five hundred 
pages of additional draft standards waiting in the wings. Just to put that 
into perspective, this means that one single PKI committee's standards and 
drafts are more than twice as voluminous as all three volumes of Stevens' 
TCP/IP Illustrated, which covers not only all of the core protocols used on 
the Internet (in far more detail than the RFCs do) but contains a complete 
implementation of a TCP/IP protocol stack to boot.

(I'm sure there's some sort of standardisation variant of "a country was never 
taxed into prosperity" lurking in there, but the few variants I can think of 
don't sound like much).

Peter.