RE: WG Last Call: HTTP over TLS (draft-ietf-tls-https-02.txt)

Hi

Below a few comments to draft-ietf-tls-https-02.txt.

2.2 Connection closure
  1. The closure behavior is already described in RFC2246.
     I'd only refer to the appropriate section in RFC2246.
     Definitions such as "premature close" are welcome.

  2. >As specified in [TLS], any implementation which receives a connection
     >close without first receiving a valid closure alert (a "premature
     >close") MUST NOT reuse that session.
     It is unclear whether the "Connection: close" as defined in RFC2068 or
     a connection termination is considered. The question is whether a
'close'
     could be received. In my opinion a HTTP client/server can detect a
close
     but not receive.
     

2.2.1. Client Behavior
  1. > Because HTTP uses connection closure to signal end of server data,...
     'HTTP' refers to RFC2068. The default behavior of HTTP/1.1 is keep
alive. 
     Otherwise a 'Connection: Close' header must be added.
  
  2. > client implementations MUST treat any premature closes as errors and
     > the data received as potentially truncated.
     That means that a HTTP client behaves different using TCP or TLS. 
     That's contrariety to section '2. HTTP Over TLS'.
     In general a HTTP client using TCP can not detect a premature close 
     without having the content length info.

  3. > Clients MUST send a closure alert before closing the connection.
     It's up to the TLS layer whether it sends a close_notify message 
     or not. For the HTTP client the underlying layer should be transparent
and
     thus a closure call to that layer looks equal either using TCP or TLS. 
     Of course a TLS layer should send the close_notify message before
closing 
     its underlying layer (TCP). But this can not be forced especially for
HTTP 
     clients.

2.4. URI Format
  In the real world this example always fails. Why don't we 
  use something like https://abc.com/~smith/home.html or
  https://abc.com:7443/~smith/home.html?


3.2. Client Identity
  The server identity is well defined. We have to consider that, in general,
  the purpose of identifying a server is different than identifying a
client.
  Client identifying is used to identify a person while server identifying
  is used to identify a machine. Thus the matching rules as described in 3.1

  are not applicable.


Proposal: Introduction of TLS related HTTP variables.
-----------------------------------------------------
  This draft is very useful to combine HTTP and TLS. HTTP is an 
  application-level protocol independent of the underlying
  transport layer. Nevertheless it could be useful for applications
  (e.g. servlet, cgi-bin, application server, ...) to gather TLS 
  related information to behave accordingly. Using such a mechanism
  client authentication could be done over TLS and could be used on 
  application level. 

  Operational area:
  1. A TLS HTTP gateway could add TLS related variables 
     into the HTTP stream which is passed to a server behind.
  2. A TLS HTTP server could add TLS related variables 
     into the environment which is passed to an application (e.g. cgi).
  
  To illustrate the idea a few examples below. Of course this idea needs 
  further discussions. The variables are encoded as described in RFC2068 
  section 2.2.
  
  - TLS_SERVER_CERT_ISSUER_DN:
/C=CH/SP=Zurich/L=Wallisellen/O=TheO/OU=TheOU/CN=TheIssuerCN
  - TLS_SERVER_CERT_SUBJECT_DN:
/C=CH/SP=Zurich/L=Wallisellen/O=TheO/OU=TheOU/CN=www.server.xx
  - TLS_CLIENT_CERT_ISSUER_DN:
/C=CH/SP=Zurich/L=Wallisellen/O=TheO/OU=TheOU/CN=TheIssuerCN
  - TLS_CLIENT_CERT_SUBJECT_DN:
/C=CH/SP=Zurich/L=Wallisellen/O=TheO/OU=TheOU/CN=Rene Eberhard
  - TLS_SERVER_CERT_PEM_ENCODED: PEM encoded server cert
  - TLS_CLIENT_CERT_PEM_ENCODED: PEM encoded client cert
  - TLS_SERVER_CERT_TYPE: RSA_RSA
  - TLS_CLIENT_CERT_TYPE: DSA_RSA
  - TLS_SERVER_KEYEXCHANGE_LENGTH: 1024
  - TLS_CIPHERSUITE: TLS_RSA_WITH_IDEA_CBC_SHA
  - TLS_IS_EXPORTABLE: FALSE
  - TLS_IS_CLIENT_AUTHENTICATED: TRUE


Regards Rene