Re: [TLS] Implementation survey: Client Certificate URL extension
Martin Rex <Martin.Rex@sap.com> Thu, 10 April 2008 15:49 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 6AC813A6C75; Thu, 10 Apr 2008 08:49:43 -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 45E993A6B2A for <tls@core3.amsl.com>; Thu, 10 Apr 2008 08:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.384
X-Spam-Level:
X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 RWyjAre5qED7 for <tls@core3.amsl.com>; Thu, 10 Apr 2008 08:49:39 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 400C13A6C75 for <tls@ietf.org>; Thu, 10 Apr 2008 08:49:37 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m3AFnIo6005651; Thu, 10 Apr 2008 17:49:23 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200804101549.m3AFnH5T008818@fs4113.wdf.sap.corp>
To: Pasi.Eronen@nokia.com
Date: Thu, 10 Apr 2008 17:49:17 +0200
In-Reply-To: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Apr 7, 8 10:35:07 am
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
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
Reply-To: martin.rex@sap.com
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
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? 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. -Martin _______________________________________________ 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