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

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 1 Oct 2009 07:44:20 -0400

I support option (2) and am against option(1), for reasons expressed in earlier emails.

Tnx!

----- Original Message -----
From: Simon Josefsson <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Blumenthal, Uri; [email-masked] <[email-masked]>
Sent: Thu Oct 01 07:00:34 2009
Subject: Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Martin Rex <[email-masked]> 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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 1 Oct 2009 09:17:02 -0700

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Blumenthal, Uri
> Sent: Thursday, October 01, 2009 4:44 AM
> To: [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis 
> (Transport Layer
> 
> enforced 
> >> by the server.
> freeware 
> >> product it is included in, so I can avoid buying or using 
> it in the 
> >> future.
> >
> application 
> > protocol.  The hostname conveyed by the TLS extension server name 
> > indication (SNI) happens at a competely different protocol layer.
> >
> into the 
> > picture (those which terminate the TLS wrapping).
> >
> 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 went for 2) assuming that the text above was intentional, 
> but I share your arguments for going with approach 1).
> 
> /Simon
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Oct 2009 10:28:51 -0600

> although I could be convinced otherwise because I don't think the SHOULD

I now agree that we need to say something about this in the TLS spec.

> not present a different name in the application protocol." 

+1

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 01 Oct 2009 18:49:32 +0200

> not present a different name in the application protocol." 

I believe that would resolve my concern.

Thanks,
/Simon

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Oct 2009 21:08:04 +0200 (MEST)

> not present a different name in the application protocol." 

OK.  +1

-Martin