Re: [TLS] AIA cert fetching seen as harmful
pgut001@cs.auckland.ac.nz (Peter Gutmann) Mon, 14 April 2008 13:35 UTC
Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82043A6D4F; Mon, 14 Apr 2008 06:35:45 -0700 (PDT)
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 48C1F3A6BD2 for <tls@core3.amsl.com>; Mon, 14 Apr 2008 06:35:45 -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=[AWL=0.000, 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 CD0BcI4i0N8b for <tls@core3.amsl.com>; Mon, 14 Apr 2008 06:35:44 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 7DBEF3A6E95 for <tls@ietf.org>; Mon, 14 Apr 2008 06:35:12 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9079F186DC for <tls@ietf.org>; Tue, 15 Apr 2008 01:35:42 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oi-MOpyl5CV for <tls@ietf.org>; Tue, 15 Apr 2008 01:35:42 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 77B95186D6 for <tls@ietf.org>; Tue, 15 Apr 2008 01:35:42 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2471E19EC0B9 for <tls@ietf.org>; Tue, 15 Apr 2008 01:35:42 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1JlOqU-000695-1U for tls@ietf.org; Tue, 15 Apr 2008 01:35:42 +1200
From: pgut001@cs.auckland.ac.nz
To: tls@ietf.org
Message-Id: <E1JlOqU-000695-1U@wintermute01.cs.auckland.ac.nz>
Date: Tue, 15 Apr 2008 01:35:42 +1200
Subject: Re: [TLS] AIA cert fetching seen as harmful
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-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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org
Mike <mike-list@pobox.com> writes: >What I suggested is that the information about which URL's are safe for the >client certificate URL extension could be embedded in the -root- certificate, >which you trust. And then you look up that URL in your trusted DNS... oops. (This also ignores the fact that you have to reissue your root cert every time some random server moves around, which I can't see any CA doing. Root certs are issued once, given a lifetime of 20-40 years, and then never touched again for fear of breaking things). The real problem here is that a server should never, ever initiate outgoing connections under the control of an external agent, which is what a lot of the PKIX protocols expect them to do. Other examples (just off the top of my head) are the logotypes and qualified certs/biometrics RFCs, which define an extension containing a URI that you're supposed to go to for further information. So a server, when seeing one of these certs, is supposed to go to whatever arbitrary location and port is specified and poke around there (I'm not sure what would happen if you entered, for example, an SSH URI instead of the more obvious HTTP one, but if the implementation is general enough you could use it for password-guessing attacks on internal SSH servers). It's just a really, really bad idea to build a capability for HTTP bounce scans into a (supposedly) passive protocol mechanism, and in particular turning a system that's supposed to provide security into a security hole just doesn't seem a winning long-term strategy to me. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] AIA cert fetching seen as harmful Peter Gutmann
- Re: [TLS] AIA cert fetching seen as harmful Mike
- Re: [TLS] AIA cert fetching seen as harmful Mike
- Re: [TLS] AIA cert fetching seen as harmful Nicolas Williams
- Re: [TLS] AIA cert fetching seen as harmful Peter Gutmann