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, 1 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'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
>