Re: [TLS] Implementation survey: Client Certificate URL extension

<Pasi.Eronen@nokia.com> Mon, 07 April 2008 07: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 C2F6128C2F9; Mon, 7 Apr 2008 00:35:56 -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 ADC4728C3B1 for <tls@core3.amsl.com>; Mon, 7 Apr 2008 00:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.085
X-Spam-Level:
X-Spam-Status: No, score=-5.085 tagged_above=-999 required=5 tests=[AWL=1.514, BAYES_00=-2.599, 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 bk9BKw50HlL3 for <tls@core3.amsl.com>; Mon, 7 Apr 2008 00:35:54 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1D51A28C2F8 for <tls@ietf.org>; Mon, 7 Apr 2008 00:34:58 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m377YwvO019178; Mon, 7 Apr 2008 10:35:09 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:35:06 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:35:06 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 07 Apr 2008 10:35:07 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com>
In-Reply-To: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Implementation survey: Client Certificate URL extension
thread-index: AciWUwAVQQUeJB9vTBmkZIhYwJ0XKgCLn6Qg
References: <1696498986EFEC4D9153717DA325CB7247EFE3@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Apr 4, 8 11:24:30 am <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp>
From: Pasi.Eronen@nokia.com
To: martin.rex@sap.com
X-OriginalArrivalTime: 07 Apr 2008 07:35:06.0544 (UTC) FILETIME=[E6807300:01C89881]
X-Nokia-AV: Clean
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

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?

Best regards,
Pasi
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls