Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 30 September 2009 00:00 UTC

Return-Path: <jsalowey@cisco.com>
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 A46493A6981; Tue, 29 Sep 2009 17:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level:
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 0kcO1GmCjPnj; Tue, 29 Sep 2009 17:00:35 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 84E723A68F3; Tue, 29 Sep 2009 17:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3967; q=dns/txt; s=sjiport06001; t=1254268917; x=1255478517; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20<jsalowey@cisc o.com>|Subject:=20RE:=20[TLS]=20Last=20Call:=20draft-ietf -tls-rfc4366-bis=20(Transport=20Layer|Date:=20Tue,=2029 =20Sep=202009=2017:01:55=20-0700|Message-ID:=20<AC1CFD94F 59A264488DC2BEC3E890DE508D3C156@xmb-sjc-225.amer.cisco.co m>|To:=20"Michael=20D'Errico"=20<mike-list@pobox.com>,=20 <martin.rex@sap.com>|Cc:=20<simon@josefsson.org>,=20<ietf @ietf.org>,=20<tls@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AC29CC6.4080204@pobox.com>|References: =20<200909292149.n8TLnLpA006226@fs4113.wdf.sap.corp>=20<4 AC29CC6.4080204@pobox.com>; bh=Di3A8x+j8QQFHDTOVhgM4BWpjXwOK/5z/3vTBnNuK6Q=; b=SrUobxpV8xeH+iJLJf7GoWdJ0BH7m6vl/J7hEKTqcu27O9iC6N0tRSxN 9rxvQi0r28JLy7pDm50X1Az6d7nPpolDTumoUtHChRNKRJYbzxmN0UwRD 3IKETznSD99c708GQCw1uNt5x7JxuSXG+mHeURb9BWMp3bkGRaHjnN9Zu c=;
Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=jsalowey@cisco.com
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAF88wkqrR7MV/2dsb2JhbAC/DYhTAZAUBYQe
X-IronPort-AV: E=Sophos;i="4.44,475,1249257600"; d="scan'208";a="398906656"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Sep 2009 00:01:57 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8U01v8I012663; Tue, 29 Sep 2009 17:01:57 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8U01vrT026514; Wed, 30 Sep 2009 00:01:57 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 17:01:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Sep 2009 17:01:55 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE508D3C156@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <4AC29CC6.4080204@pobox.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
Thread-Index: AcpBX12mv4AknHqZSAqnG/V4IjsT6QAANbgQ
References: <200909292149.n8TLnLpA006226@fs4113.wdf.sap.corp> <4AC29CC6.4080204@pobox.com>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Michael D'Errico" <mike-list@pobox.com>, <martin.rex@sap.com>
X-OriginalArrivalTime: 30 Sep 2009 00:01:56.0881 (UTC) FILETIME=[39ADE010:01CA4161]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3967; t=1254268917; x=1255132917; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20RE=3A=20[TLS]=20Last=20Call=3A=20draft-ietf-tls -rfc4366-bis=20(Transport=20Layer |Sender:=20; bh=Di3A8x+j8QQFHDTOVhgM4BWpjXwOK/5z/3vTBnNuK6Q=; b=QB4SJ3DoRT62o4B6mE/DyJ9xNftyq8KGS3nLeOAQbS5wrTuitbQPL9hwlH hT2hEXTPWQflsajT9150wPXTEJb0oYpsh8DMW3di/J9nG8uPpiJUrJIhhzEy xL42W+dJ6/DIyVvJsOMs+w+PY7Meh+k7nDGHRaUoB7vRyoB8fmshQ=;
Cc: simon@josefsson.org, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
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-Archive: <http://www.ietf.org/mail-archive/web/tls>
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>
X-List-Received-Date: Wed, 30 Sep 2009 00:00:36 -0000

It seems that this is really up to the application.  Both server names
are authenticated under the same session.  It seems an application
server may require them to be the same or allow them to be different.   

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of Michael D'Errico
> Sent: Tuesday, September 29, 2009 4:48 PM
> To: martin.rex@sap.com
> Cc: simon@josefsson.org; ietf@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis 
> (Transport Layer
> 
> >>> I do not see why you consider this a vulnerability in the 
> _server_!
> >>
> >> Because a malicious client could theoretically establish a secure 
> >> connection using one server domain and then ask for pages from a 
> >> different domain.  If the server does not check for this, it could 
> >> potentially leak sensitive information.
> > 
> > You're barking up the wrong tree.  If the client did not 
> use TLS, the 
> > server wouldn't even know that.
> 
> You must be talking about a particular server implementation 
> that has this shortcomings.  There is nothing inherent in TLS 
> that prevents a server from knowing when it is used.  Your 
> library and/ or use of that library is the problem.
> 
> > It is inappropriate to assume that virtual hosting provides 
> seperation 
> > of content and draw a conclusion that, when accesses via 
> HTTPS, will 
> > provide a secure seperation of content instead.
> 
> I'm not assuming anything; I have written a TLS library and 
> an HTTP server that provides the separation of content that 
> you deny is possible.
> 
> > If the lack of such a server-side check is a problem for 
> your server, 
> > then your server problably has a severe design flaw in its session 
> > management.
> 
> I never said my server suffered from this problem....
> 
> >> And I'm curious: why do you call matching the commonName weak?
> > 
> > Because in the vast majority of situatins it is the last step in a 
> > long row of flawed assumptions.
> 
> OK, so you are complaining about the entirety of e-commerce 
> on the web.  Do you have any proposed solutions to these problems?
> 
> Mike
> 
> 
> > Security is only as strong as its weakest link.  The authentication 
> > process based on a DNSName involves a number of very weak 
> authentications.
> > 
> > DNS domain names are not very genuine, and it is very non-obvious 
> > which domain names are used by the business or peer someone 
> is looking 
> > for and which are used by others (different businesses with 
> the same 
> > name, cybersquatters or attackers).  Most HTTPS-URLs opened by Web 
> > Browsers are served through plaintext HTTP pages.
> > 
> > Then most Browser PKIs come with a hundred or more trusted CAs 
> > preconfigured, and browsers trust them equally.  Whether or 
> how secure 
> > the authentication is that the CA performs before issuing a 
> > certificate is another flawed assumption that weakens the
> > rfc-2818 server endpoint authentication.
> > 
> > A final flaw that is still present in most browsers is the lack of 
> > memory.  Not memorizing the certificate that a server 
> presented on the 
> > last contact perpetuates the weakness of the original 
> authentication.
> > 
> > Personally, I think that deriving a server endpoint 
> identifier from a 
> > network address is the most flawed assumption of all.
> > 
> > That is like asserting that if someone opens on a random 
> door on which 
> > you knock, and shows you an ID card with the correct street 
> address -- 
> > then he must be a GOOD guy.
> > 
> > 
> > -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>