Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Thu, 01 October 2009 16:15 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 29F5D3A68CE for <tls@core3.amsl.com>; Thu, 1 Oct 2009 09:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.581
X-Spam-Level:
X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 QWgvaSZaooC0 for <tls@core3.amsl.com>; Thu, 1 Oct 2009 09:15:37 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E707D3A6898 for <tls@ietf.org>; Thu, 1 Oct 2009 09:15:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3917; q=dns/txt; s=sjiport01001; t=1254413824; x=1255623424; 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:=20Thu,=201=20 Oct=202009=2009:17:02=20-0700|Message-ID:=20<AC1CFD94F59A 264488DC2BEC3E890DE508D3C853@xmb-sjc-225.amer.cisco.com> |To:=20"Blumenthal,=20Uri"=20<uri@ll.mit.edu>,=20<simon@j osefsson.org>,=0D=0A=20=20=20=20=20=20=20=20<martin.rex@s ap.com>|Cc:=20<tls@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6B A5@LLE2K7-BE01.mitll.ad.local>|References:=20<90E934FC4BB C1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.loca l>; bh=yqsG0zLR3bl1AlhQqwC+OHg8aE1VPGeCpYznwd97+BU=; b=AwMUark6ELs/igeJeEGCKt47RCQus5FTK5ptJWZuvQWdXkCBAns27+tC pNizadt8bRLFAig4NuTKxqZRBoETfUNb4m8V6ehz1MJJibJahhgfn/R9u N1cHucG0v2PGcFWq2qJ8FlYgnf3XP+UxjR+1gdygWW67GgLCAOo4Y/Q1G U=;
Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jsalowey@cisco.com
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEABdzxEqrR7MV/2dsb2JhbAC/WIhbAY9QBoQpig4
X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="249705998"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2009 16:17:03 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91GH3Dc008852; Thu, 1 Oct 2009 09:17:03 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n91GH3iF001309; Thu, 1 Oct 2009 16:17:03 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); Thu, 1 Oct 2009 09:17:03 -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: Thu, 01 Oct 2009 09:17:02 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE508D3C853@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
Thread-Index: AcpChmwiemOoDs36RvChbb13kLtWqQABhv2iAAkJAoA=
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Blumenthal, Uri" <uri@ll.mit.edu>, simon@josefsson.org, martin.rex@sap.com
X-OriginalArrivalTime: 01 Oct 2009 16:17:03.0297 (UTC) FILETIME=[9CA23B10:01CA42B2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3917; t=1254413823; x=1255277823; 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=yqsG0zLR3bl1AlhQqwC+OHg8aE1VPGeCpYznwd97+BU=; b=UTtGYgb1YUsHqLy0tEiYxkXt1umlVqHqj/qONtTVBIXfmosEDSbQijxNWI USnQVYEgYn167eZ038wgjjMctLvz0X46vbbEpDDD5ToOpq56Tj7KfeUGA/Cb T+NMYc4fS4WrQDRB3yWxTPC+K06EtrRfdctMyIGTS2xz6n7TEb5yk=;
Cc: 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: Thu, 01 Oct 2009 16:15:39 -0000
I don't think option 1 is an appropriate change for this document, although I could be convinced otherwise because I don't think the SHOULD is very enlightening. For option 2 I would prefer text that explains the SHOULD, maybe something like: "Since it is possible for a client to present a different server_name in the application protocol, application server implementations that rely upon these names being the same MUST check to make sure the client did not present a different name in the application protocol." Joe > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > Behalf Of Blumenthal, Uri > Sent: Thursday, October 01, 2009 4:44 AM > To: 'simon@josefsson.org'; 'martin.rex@sap.com' > Cc: 'tls@ietf.org' > Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis > (Transport Layer > > I support option (2) and am against option(1), for reasons > expressed in earlier emails. > > Tnx! > > > ----- Original Message ----- > From: Simon Josefsson <simon@josefsson.org> > To: martin.rex@sap.com <martin.rex@sap.com> > Cc: Blumenthal, Uri; tls@ietf.org <tls@ietf.org> > Sent: Thu Oct 01 07:00:34 2009 > Subject: Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer > > Martin Rex <Martin.Rex@sap.com> writes: > > > Blumenthal, Uri wrote: > >> > >> In my understanding, TLS-established server_name should be > enforced > >> by the server. > >> > >> And Martin - I couldn't disagree more with you. The whole point of > >> using TLS is to enforce who can access what. So the client > makes sure > >> he accesses the right server, the server makes sure he > grants access > >> to the right pages on the right virtual host. And if your server > >> doesn't do that - please kindly tell me what commercial or > freeware > >> product it is included in, so I can avoid buying or using > it in the > >> future. > > > > There seems to be a significant misunderstanding. > > > > The Host header field of an HTTP request is a detail of an > application > > protocol. The hostname conveyed by the TLS extension server name > > indication (SNI) happens at a competely different protocol layer. > > > > The difference becomes obvious when you add reverse proxies > into the > > picture (those which terminate the TLS wrapping). > > > > Conceptually, the Host: header field of a HTTP request is > part of the > > URL. If a reverse proxy perform URL rewriting, it may as > well have to > > rewrite Host: header fields. That depends entirely on the backend > > architecture of each particular software installation. > > > > > > Whether or not an application may want to make consistency checks > > between a Host: Header field and a hostname received via SNI at the > > specific point of the backend architecture where TLS was terminated > > depends entirely on the backend architecture, and is an application > > issue. > > I believe this wording in RFC 4366bis makes it a TLS issue: > > 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. > > I believe there are two options: > > 1) Either remove all requirements on application behaviour > from 4366bis > (including the text above) and explicitly defer such discussions to > other documents. > > 2) Add the text I proposed to make servers actually validate proper > client behaviour. > > I went for 2) assuming that the text above was intentional, > but I share your arguments for going with approach 1). > > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Blumenthal, Uri
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Blumenthal, Uri
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Martin Rex
- 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 (… Simon Josefsson
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Blumenthal, Uri
- Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (… Martin Rex