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

"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'; '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
>> 