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