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 >>
- [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Tran… The IESG
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Simon Josefsson
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Dean Anderson
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Eric Rescorla
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Pasi.Eronen
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Peter Sylvester
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Martin Rex
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Michael D'Errico
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Martin Rex
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Michael D'Errico
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Joseph Salowey (jsalowey)
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Simon Josefsson
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Joseph Salowey (jsalowey)
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Peter Saint-Andre
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Blumenthal, Uri