Re: [TLS] AIA cert fetching seen as harmful
Eric Rescorla <ekr@networkresonance.com> Fri, 11 April 2008 02:13 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 C54803A6A66; Thu, 10 Apr 2008 19:13:26 -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 7EDBA3A69FB for <tls@core3.amsl.com>; Thu, 10 Apr 2008 19:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level:
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 VOBVsCZSJqnx for <tls@core3.amsl.com>; Thu, 10 Apr 2008 19:13:24 -0700 (PDT)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id AF38D28C138 for <tls@ietf.org>; Thu, 10 Apr 2008 19:13:24 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7C6B55085A; Thu, 10 Apr 2008 19:15:37 -0700 (PDT)
Date: Thu, 10 Apr 2008 19:15:37 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Nelson B Bolyard <nelson@bolyard.com>
In-Reply-To: <47FEBED6.7040105@bolyard.com>
References: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp> <47FE39E7.2020209@pobox.com> <47FEB492.6020209@bolyard.com> <20080411010825.8E41750854@romeo.rtfm.com> <47FEBED6.7040105@bolyard.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080411021537.7C6B55085A@romeo.rtfm.com>
Cc: tls@ietf.org
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org
At Thu, 10 Apr 2008 18:28:54 -0700, Nelson B Bolyard wrote: > > Eric Rescorla wrote, On 2008-04-10 18:08: > > At Thu, 10 Apr 2008 17:45:06 -0700, > > Nelson B Bolyard wrote: > >> Mike wrote, On 2008-04-10 09:01: > >> > >>> This could be made safe with some help from PKIX (if X.509 doesn't > >>> already support it -- I haven't read RFC 3280 or -bis in a while). > >>> If root certificates listed constraints on what constitutes a valid > >>> URL for retrieving issued certificates, then a server could scan > >>> the combined list from each trusted root to determine if it is safe > >>> to fetch a client certificate. > >> Are you all aware of this paper, now making a stir? > >> > >> https://www.cynops.de/techzone/http_over_x509.html > > > > Yes, Martin cited this paper a few weeks ago. > > > > > >> It claims that fetching CA certs from URLs found in AIA extensions in certs > >> that have not yet been validated is a vulnerability. At least one browser > >> organization known to me agrees. > > > > How does that organization feel about inline images in HTML pages? > > The problem isn't so much when browsers initiate fetches for certs from > servers. The major concerns are: > a) servers fetching URLs from unvetted client auth certs, and > b) mail clients fetching certs to verify signatures in emails from strangers. > > Some email clients, in particular, are good at not fetching remote content > from html emails, which confirms email addresses to spammers. AIA cert > fetching weakens their ability to defend against such attempts to validate > email addresses. > > Servers see them selves as similarly weakened. > > I'm receiving inquiries about white listing CA URLs for AIA fetching. :( I assume these people are up in arms about DKIM, then? -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] Implementation survey: Client Certificate U… Pasi.Eronen
- Re: [TLS] Implementation survey: Client Certifica… Rob Dugal
- Re: [TLS] Implementation survey: Client Certifica… Dieter Bratko
- Re: [TLS] Implementation survey: Client Certifica… Martin Rex
- Re: [TLS] Implementation survey: Client Certifica… Peter Gutmann
- Re: [TLS] Implementation survey: Client Certifica… Pasi.Eronen
- Re: [TLS] Implementation survey: Client Certifica… Martin Rex
- Re: [TLS] Implementation survey: Client Certifica… Peter Gutmann
- Re: [TLS] Implementation survey: Client Certifica… Nelson B Bolyard
- Re: [TLS] Implementation survey: Client Certifica… Pasi.Eronen
- Re: [TLS] Implementation survey: Client Certifica… Martin Rex
- Re: [TLS] Implementation survey: Client Certifica… Mike
- Re: [TLS] Implementation survey: Client Certifica… Eric Rescorla
- [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Eric Rescorla
- Re: [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Eric Rescorla
- Re: [TLS] AIA cert fetching seen as harmful Mike
- Re: [TLS] Implementation survey: Client Certifica… Florian Weimer
- Re: [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Mike