[apps-discuss] draft-hoffman-server-has-tls-03.txt

[Simon Josefsson <[e-mail]>]

I believe the goal of this document is great and I would like to see it
happen in one form or the other.

Diving into some details...  It says:

      Secure Only (SSO) -- The server responds using TLS on the TLS-
      specific port for the application.  For example, a host for a web
      server only responds to HTTP requests on port 443.  Alternately,
      if the application supports in-band security update (such as
      STARTTTLS for SMTP), the server responds on the normal port, tries
      to establish a TLS session, and does not proceed with the protocol
      if a TLS session cannot be established.

The distinction between STARTTLS-capable protocols and
non-STARTTLS-capable protocols is not as clear as you might think here.
There is RFC 2817 for STARTTLS over HTTP, which is run over port 80.

In general, I think the document is confusing "secure" form with
non-STARTTLS TLS-wrapped form.  For example:

   Given a particular client application configuration, there are three
   interesting types of clients:

      Insecure Only (CIO) -- The client is configured to only attempt
      communication for the application in its insecure form.  For
      example, a POP client might be configured to only try insecure POP
      on port 110.

      Secure Only (CSO) -- The client is configured to only attempt
      communication for the application in its secure, TLS-wrapped form.
      For example, a POP client might be configured to only try secure
      POP on port 995.

      Allows Fallback From Secure to Insecure (CFB) -- The client is
      configured to attempt communication for the application in its
      secure, TLS-wrapped form, but if it fails to set up a TLS session,
      the client will attempt to attempt communication to the same
      server using the insecure form.

This doesn't match existing clients since it doesn't acknowledge
STARTTLS heuristics.  A classification that better matches existing
clients would be this one:

   Given a particular client application configuration, there are five
   interesting types of clients:

   Insecure only - the client doesn't use TLS at all.

   Insecure upgrade - the client connects without TLS and upgrades to
   TLS using a STARTTLS mechanism if it is available.  If STARTTLS is
   not available, it proceeds insecurely.

   Fall-back - the client first attempts to connect on the TLS-wrapped
   port (non-STARTTLS) and on failures reverts back to the insecure port
   and becomes a Insecure only, Insecure upgrade or Secure Upgrade
   client.

   Secure Only - the client only connects to the TLS-wrapped port, and
   on failures gives up.

   Secure Upgrade - the client connects without TLS and upgrades to TLS
   using a STARTTLS mechanism.  If STARTTLS is unavailable, connection
   fails.

Thoughts?

/Simon