Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard

[Simon Josefsson <[e-mail]>]

I am aware that the IETF-wide last call has ended, but Daniel Black
provided a suggestion (posted on the gnutls-devel list) for the Security
Considerations that I agree with and believe can be important.  Quoting
him, slightly reworded:

  also maybe 11.1. could say, in response to the last paragraph of
  section 3, + "Server applications SHOULD validate server_name against
  any application layer equivalent field."

The last paragraph of section 3 reads:

   If an application negotiates a server name using an application
   protocol and then upgrades to TLS, and if a server_name extension is
   sent, then the extension SHOULD contain the same name that was
   negotiated in the application protocol. 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.

It appears security relevant for the server to actual verify that the
client do not use another server name at the application layer to
circumvent authorization decisions.  I cannot find any MUST/SHOULD
requirement in the document for servers to test this right now.

One attack could works like this:

1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.

2) The server TLS code authenticate and authorize the client (using the
certificate) for use with the blog.example.org domain.  The server HTTP
code serves the internal-website.example.org web page to the client.

This system would be insecure but still compliant with RFC 4366bis as
far as I can tell, which seems suboptimal.  Adding a requirement for
servers to check for this attack would solve the problem.

/Simon