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

Simon Josefsson <simon@josefsson.org> Thu, 01 October 2009 16:48 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 0037628C120 for <tls@core3.amsl.com>; Thu, 1 Oct 2009 09:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 QHnL4SMkY-7f for <tls@core3.amsl.com>; Thu, 1 Oct 2009 09:48:15 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id ADB6628C125 for <tls@ietf.org>; Thu, 1 Oct 2009 09:48:14 -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 n91GnWnv015080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Oct 2009 18:49:34 +0200
From: Simon Josefsson <simon@josefsson.org>
To: "Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local> <AC1CFD94F59A264488DC2BEC3E890DE508D3C853@xmb-sjc-225.amer.cisco.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:091001:martin.rex@sap.com::2pfiYREofjnyZKSn:42Ym
X-Hashcash: 1:22:091001:jsalowey@cisco.com:://mC6gSyRdrqvc86:X0X1
X-Hashcash: 1:22:091001:tls@ietf.org::R9BBLBTBvnGF1/5y:Vg1e
X-Hashcash: 1:22:091001:uri@ll.mit.edu::V7pcIZ7TrUrw0GY0:wbQV
Date: Thu, 01 Oct 2009 18:49:32 +0200
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE508D3C853@xmb-sjc-225.amer.cisco.com> (Joseph Salowey's message of "Thu, 1 Oct 2009 09:17:02 -0700")
Message-ID: <87r5tnt5yb.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
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:48:16 -0000

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

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

I believe that would resolve my concern.

Thanks,
/Simon

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