On Fri, Oct 20, 2006 at 03:26:12PM +0300, Pasi.Eronen@nokia.com wrote:
> Bodo Moeller wrote:

>> What remains is my main conclusion that the language in the
>> specification in this regards is a total mess, and that we can't just
>> look what we would *like* the specification to be, but mostly at what
>> will work best with the implementations that are actually out there.

> I agree. Here's some suggested text; let's see if we can improve on
> it somehow...

Your suggestion looks quite good!  There are just two things I'd like
to change:

> E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
> 
>    For historical reasons and in order to avoid a profligate
>    consumption of reserved port numbers, application protocols which
>    are secured by various versions of TLS (1.0, 1.1, and 1.2) and SSL
>    (2.0 and 3.0) all frequently share the same connection port: for
>    example, the https protocol (HTTP secured by SSL or TLS) uses port
>    443 regardless of which security protocol it is using. Thus, some
>    mechanism must be determined to distinguish and negotiate among the
>    various protocols.
> 
>    TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and
>    use compatible ClientHello messages; thus, supporting all of them
>    is relatively easy.
> 
>    [...]

I'd remove the discussion of ports.  If we really want to explain why
the TLS protocol has to do version negotiation, then for completeness
we'd also have to mention the various mechanisms of the STARTTLS
variety.  But I think all this distracts from what the TLS
specification is about; I think that the basic concept of version
negotiation is obvious enough that we don't have to explain the
background it detail.  Here's my proposal:

E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0

   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
   future versions) and SSL (2.0 and 3.0), means are needed to
   negotiate the specific protocol version to use.  The TLS protocol
   provides a built-in mechanism for version negotiation so as not to
   bother other protocol components with the complexities of version
   selection.

   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and
   use compatible ClientHello messages; thus, supporting all of them
   is relatively easy.

   [...]


My second change request is to specifically mention future protocol
versions, since mishandling of these is a frequent cause of problems.
So let's reword the second paragraph quoted above:

   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and
   use compatible ClientHello messages; thus, supporting all of them
   is relatively easy.  Similarly, servers can easily handle clients
   trying to use future versions of TLS as long as the clients still
   support the highest protocol version available in the server.

   [...]

Bodo


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls