RE: [TLS] Record layer corner cases

pgut001@cs.auckland.ac.nz (Peter Gutmann) Tue, 28 November 2006 01:54 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosAu-00052Q-GN; Mon, 27 Nov 2006 20:54:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosAs-00052J-Um for tls@ietf.org; Mon, 27 Nov 2006 20:54:18 -0500
Received: from mailhost.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GosAr-0008WD-HO for tls@ietf.org; Mon, 27 Nov 2006 20:54:18 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 527CD359F2; Tue, 28 Nov 2006 14:54:12 +1300 (NZDT)
Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26101-09; Tue, 28 Nov 2006 14:54:12 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id D8CA536065; Tue, 28 Nov 2006 14:54:11 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7A27F37742; Tue, 28 Nov 2006 14:54:10 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GosAo-0002xR-00; Tue, 28 Nov 2006 14:54:14 +1300
From: pgut001@cs.auckland.ac.nz
To: DPKemp@missi.ncsc.mil, martin.rex@sap.com, pgut001@cs.auckland.ac.nz
Subject: RE: [TLS] Record layer corner cases
In-Reply-To: <FA998122A677CF4390C1E291BFCF5989060658B9@EXCH.missi.ncsc.mil>
Message-Id: <E1GosAo-0002xR-00@medusa01.cs.auckland.ac.nz>
Date: Tue, 28 Nov 2006 14:54:14 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

"Kemp, David P." <DPKemp@missi.ncsc.mil> writes:

>RFC 3280 (and draft 3280bis-05) clearly specify that trust anchors are
>maintained out of band, and that trust anchor information does not include a
>validity period any other certificate fields except the four listed:

At the time this first appeared (in X.509v4 drafts) I did an informal survey
of PKI implementors, and exactly *zero* implementors were aware of this sudden
change retroactively hacked onto X.509's behaviour.  It may be in the spec
now, but how many existing implementations do you think will handle this as
required?  To handle this complete reversal of root cert handling you'd have
to more or less tear down everything built in the last 10-15 years and start
again.  I wonder what the chances of that happening are?

(The correct way to handle this change would have been to stipulate the pre-
 X.509v4 behaviour by default, and then require the presence of some special
 critical extension to denote the new behaviour.  As it stands, the text is
 little better than random noise for all the effect it'll have on
 implementors.  The horse not only bolted on this one 15 years ago, it's had
 time to raise entire herds of new horses who aren't going to go back in the
 barn no matter how hard you slam the door).

Peter.

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