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

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
> 