Re: [TLS] Implementation survey: Client Certificate URL extension
Eric Rescorla <ekr@networkresonance.com> Thu, 10 April 2008 16:04 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 688CC3A6D17; Thu, 10 Apr 2008 09:04:33 -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 D7C993A6D3A for <tls@core3.amsl.com>; Thu, 10 Apr 2008 09:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level:
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.034, 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 jHdY4ixE2XVp for <tls@core3.amsl.com>; Thu, 10 Apr 2008 09:04:25 -0700 (PDT)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 74F613A6D82 for <tls@ietf.org>; Thu, 10 Apr 2008 09:04:25 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E330C5085A; Thu, 10 Apr 2008 09:06:36 -0700 (PDT)
Date: Thu, 10 Apr 2008 09:06:36 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: martin.rex@sap.com
In-Reply-To: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp>
References: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.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: <20080410160636.E330C5085A@romeo.rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Implementation survey: Client Certificate URL extension
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 17:49:17 +0200 (MEST), Martin Rex wrote: > > Pasi.Eronen@nokia.com wrote: > > > > Martin Rex wrote: > > > Pasi.Eronen@nokia.com wrote: > > > > > > > > This vulnerability of Client Certificate URL is already described in > > > > the Security Considerations text in RFC 4366, so it isn't anything > > > > particularly new. > > > > > > > > In the context of web browsing over TLS, it isn't really different > > > > than, say, the ability to include IMG URLs pointing to arbitrary > > > > hosts (not just the one the HTML page came from). > > > > > > It is completely different! > > > > > > The regular HTTP/HTML based attacks attack the client/browser. > > > > > > The certificate extensions and the client-cert-URL extension for TLS > > > attack the server, and there is no "must visit a hostile website" > > > involved at all, the server is guaranteed to fall prey to every > > > attack automatically if it supports/implements such a feature (or > > > "inherits" this feature from the underlying middleware). > > > > You're quite right, I wasn't thinking clearly -- this is indeed > > quite different, since it targets the server. > > > > Nevertheless, it is described in RFC 4366 already; do you think > > there's something more we should add in 4366bis? > > Security Considerations, section 6.3 of rfc4366 already describes the > problems and implications in quite detail (I wasn't aware of that). > But maybe that isn't scary enough? Personally, I feel quite uncomfortable > with such a dangerous extension in an IETF standard. *I* can NOT think > of a safe mode of operation for the client certificate URL extension. > As soon as the admins enables it, his server is toast. Do we really need > to standardize something that is so extremely dangerous? Too late for that. Plus, it's not like this is the only place this kind of thing is standardized. Cf. web pages. > Btw. why should rfc4346bis (TLS 1.2) obsolete rfc4366 (TLS extensions)? > draft-ietf-tls-rfc4346-bis-09.txt has this in the second line: > Obsoletes (if approved): RFC 3268, 4346, 4366 > > None of the vital Security Considerations from rfc4366 was merged into > rfc4346bis, so this appears to be an error. > There is a fairly fresh rfc4366bis I-D claiming to obsolete rfc4366. Together 4346-bis and 4366 bis obsolete 4366. As far as I know the security considerations in 4346-bis do cover the security considerations for the extensions mechanism itself and the extensions described in the document. -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