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

Simon Josefsson <simon@josefsson.org> Wed, 30 September 2009 05:18 UTC

Return-Path: <simon@josefsson.org>
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 870CC3A67F5; Tue, 29 Sep 2009 22:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level:
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599]
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 Ek64Mvcih7Cl; Tue, 29 Sep 2009 22:18:50 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CC1A63A683A; Tue, 29 Sep 2009 22:18:48 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n8U5Jmav027676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Sep 2009 07:19:54 +0200
From: Simon Josefsson <simon@josefsson.org>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <200909292149.n8TLnLpA006226@fs4113.wdf.sap.corp> <4AC29CC6.4080204@pobox.com> <AC1CFD94F59A264488DC2BEC3E890DE508D3C156@xmb-sjc-225.amer.cisco.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090930:ietf@ietf.org::S00+6yT3ovlgKhXp:2pYd
X-Hashcash: 1:22:090930:mike-list@pobox.com::tCDC+CbAuV1vA1bW:5SuR
X-Hashcash: 1:22:090930:tls@ietf.org::EzQwZ7aJGHTiji80:6e9I
X-Hashcash: 1:22:090930:jsalowey@cisco.com::D7J60r7gDmTFAwGA:AvYe
X-Hashcash: 1:22:090930:martin.rex@sap.com::k+LTXUhL0s9Euahj:dcXj
Date: Wed, 30 Sep 2009 07:19:48 +0200
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE508D3C156@xmb-sjc-225.amer.cisco.com> (Joseph Salowey's message of "Tue, 29 Sep 2009 17:01:55 -0700")
Message-ID: <87y6nx57rf.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Cc: tls@ietf.org, ietf@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 05:18:51 -0000

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> writes:

> 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.   

I would agree if the draft wouldn't prevent clients from requesting a
different server name at the application layer:

   negotiated in the application protocol. If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.

At least that is how I read it.

/Simon

>
>> -----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
>>