Subject: [TLS] Open issue: Record Version Numbers

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Oct 2006 12:38:11 -0700

Yngve Petterson has pointed out [0] that there is some confusion
in how to interpret what version numbers ought to appear in
the ClientHello record in TLS handshakes. The issue is that
there are two numbers:

- the record version number
- the client hello version number

The text is quite clear that the second of these should be the
highest version you support. However, the text for the secodn
reads:

   "TLS clients who wish
   to negotiate with SSL 3.0 servers should send client hello messages
   using the SSL 3.0 record format and client hello structure, sending
   {3, 1} for the version field to note that they support TLS 1.0".	

I read this text as saying that if you are a client who supports TLS 1.0
and SSLv3, you should in general send the following values:

- record version number           {3, 0} (SSLv3)
- client hello version number     {3, 1} (TLSv1)

If the server decides to accept TLS 1.0, it should respond with the
following values:

- record version number           {3, 1} (TLSv1)
- client hello version number     {3, 1} (TLSv1)

Pettersen reports that in some cases this causes errors because servers
(inexplicably) use the record version in the negotiation.  However, I
think at the end of the day, that's a clear implementation error
and the spec should just clarify that the above behavior is what's
expected.

Comments?

-Ekr

[0] draft-ietf-pettersen-tls-interop-experience-00 (soon to
    be a TLS-WG draft but not published that way yet).

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Oct 2006 14:24:21 -0700

> highest version you support. However, the text for the secodn

I had it pointed out to me in private that these are contradictory.
This should read:

  The text is quite clear that the second of these should be the
  highest version you support. However, the text for the first

-Ekr

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 18 Oct 2006 14:02:55 +0200

>> the ClientHello record in TLS handshakes. [...]
>>    "TLS clients who wish

I agree that, by the wording of the specification, clients in this
setting should send {3, 0} as record version number and {3, 1} as
client hello version number, and that it is a clear implementation
error if servers do not properly handle this.  However, since there
*are* servers showing this bug, it is reasonable for clients to send
{3, 1} for both the record version number and the client hello version
number.  (The specification text only says "should", not "MUST".)

I don't agree that the RFCs are totally clear about the situation: for
example, RFC 2246 says "a TLS server which wishes to interoperate with
SSL 3.0 clients should accept SSL 3.0 client hello messages", but does
not say that TLS servers who do *not* wish to interoperate with TLS
3.0 clients should accept SSL 3.0 client hello messages anyway (since
the actual client hello protocol version may be TLS 1.0).  This
requirement is a logical consequence if we want the protocol to work,
but this is something that should be worked out in the specification
and not left for implementors to derive.  The wording in RFC 4346
(TLS 1.1) is even less clear because it does not mention the TLS 1.0
backwards compatibility case.

The proper way to resolve the situation appears to be:

- Clients MAY (not "should") use the lowest supported protocol version
  for the record version number, and must use the highest supported
  protocol version for the client hello version number.

- Servers MUST accept any {3, ??} record version number for the client
  hello and interpret the client hello message according to their
  supported protocol versions.  If the client hello version number
  denotes a protocol version supported by the server, use this
  version.  Otherwise, if the client hello version number is higher
  than any protocol version supported by the server, use the maximum
  protocol version supported by the server.  In this case, if the
  client hello version number is different from the client's record
  version number, then the server MAY send a fatal protocol_version
  alert if this server protocol version is below both the client hello
  version number and the client's record version number.

With this rule, servers can use the information conveyed in the record
version number / client hello version number combination if there is
some useful information (i.e. if the client is using the record
version number to provide the least protocol version supported), but
still no harm is done if clients send the client hello version number
as record version number to avoid confusing buggy servers.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Oct 2006 20:48:29 +0200 (MET DST)

Bodo Moeller wrote:
> Eric wrote: 

I fully agree with Eric.  This is the correct and most reasonable approach.

> number.  (The specification text only says "should", not "MUST".)

I violently disagree.

Although there are broken servers out there, the bug seems to result
in the negotiation of SSLv3 {3,0} instead of TLSv1 {3,1} if the
client uses the correct behaviour and places {3,0} in the record
protocol for backwards compatibility.  Although this might be
an undesirable result, it is neither a serious interoperability
problem nor a direct security vulnerability by itself.

However, the approach of the client using {3,1} in the record protocol
will rightfully cause some SSLv3-only Server to abort the handshake,
which amounts to a real interoperability problem, so clients ought
to be strongly discouraged from taking that approach.

Changing a spec to break interoperability with perfectly correct
(server) implementations (of SSLv3) is a pretty bad idea.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 18 Oct 2006 22:18:43 +0200

> problem nor a direct security vulnerability by itself.

Well, SSL 3.0 does have more severe security vulnerabilities than
TLS 1.0 (http://www.imc.org/ietf-tls/mail-archive/msg03983.html),
although these shouldn't be too significant for typical use.  Also,
in some cases draft-pettersen-tls-interop-experience-00.txt does
report connection abortions due to this bug that could be avoided
by sending {3,1} in both version fields.

My impression was that sending {3,1} in both fields is less
problematic in practice than sending {3,0} as the record version
number and {3,1} as the client hello version number.  However, this
may be based on an incomplete assessment of what servers are out
there, and more importantly, how current servers will react
to similar situations involving newer and future protocol versions,
such as {3,2} (TLS 1.1), {3,3} (TLS 1.2), and {3,42} (a made-up future
protocol version that should cause servers to negotiate an existing
version).

> (server) implementations (of SSLv3) is a pretty bad idea.

In my view the main problem is that the speficification never clearly
and fully described how implementations should behave to guarantee
interoperability.  Just like the SSL 3.0 specification does not
require servers (SSL 3.0-only servers, that is) to accept {03, 01} in
the record version number, the TLS 1.0 specification does not require
servers (TLS 1.0-only servers) to accept {03, 00}.  In both cases, it
is to be hoped that implementors are wise enough to accept any version
that looks reasonably close, because the worst thing that can happen
is a connection failure, which isn't much worse than what you'd get if
you straightly reject the connection attempt after seeing the version
number: either way, this would be a connection failure, but servers
that are tolerant about the version number also may actually see the
connection succeed using the negotiated version number (based on the
client hello version number and the server's capabilities).

Bodo

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 16:24:12 +0300

Martin Rex wrote:

> However, the approach of the client using {3,1} in the record
> protocol will rightfully cause some SSLv3-only Server to abort the
> handshake, which amounts to a real interoperability problem, so
> clients ought to be strongly discouraged from taking that approach.

On the other hand, using {3,0} in the record protocol will cause 
some TLS 1.0 servers to abort the handshake (or fail it some way). 
Yngve's draft shows such servers do exist.

I don't think arguing which of them does it "rightfully" is very
useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS
1.0-only servers should accept {3,0} in the record version);
we should be arguing about which approach will cause the least
amount of interop problems.

To this question, we don't seem to have a definitive answer yet.

> (server) implementations (of SSLv3) is a pretty bad idea.

As basically all current TLS implementations send {3,1} in the 
record version (when configured to support both SSLv3 and TLS 1.0),
interoperability with servers that reject this is already broken
in real world.

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Oct 2006 15:59:53 +0200 (MET DST)

> Yngve's draft shows such servers do exist.

There is not problem with requiring broken servers to be fixed.
There is a serious problem with requiring perfectly correct
implementations to be fixed to cater much newer broken implementations.

The availability of patches is likely better for newer implementations
(broken TLSv1) than for older implementations (correct SSLv3).

> 1.0-only servers should accept {3,0} in the record version);

On the contrary.  The version on the record protocol is a PDU encoding,
and TLS was specifically designed to reuse most of SSLv3.

There is no requirement for a TLSv1 server to agree to talking
SSLv3 {3,1}, but it certainly is required to parse the SSLv3
record procotol without hitches!

> interoperability with servers that reject this is already broken

Only the (TLSv1) servers that require this hack are broken, and
they're broken in a real stupid fashion.  Clients that are sending
{3,1} even with SSLv3 enabled are technically not broken, but they're
not doing what is recommended.  Only clients that do not offer the
user a switch to make them behave in the recommended fashion are
broken with regards to the spirit of the spec.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 19 Oct 2006 18:17:06 +0200

> and TLS was specifically designed to reuse most of SSLv3.

Just like TLS 1.0 was designed to reuse most of SSL 3.0, SSL 3.0 was
designed to allow reuse in future protocol versions, and server
implementations of the SSL 3.0 specification should tolerate seeing
{3, 1} or later in the record version number used for the client
hello.  If implementations don't tolerate this, it is a deficiency,
just like it is a deficiency if TLS 1.0 implementations don't tolerate
{3, 0} in the record version number.  In neither case, it necessarily
deserves to be called a bug in the implementation since the actual bug
is the unclear language in the specifications.

Note that the SSL 3.0 specification (draft-freier-ssl-version3-02.txt)
can be read as implying that the record version number field will
contain the highest version of the protocol supported by the client,
not the fixed value {3, 0}.  Appendix E.1 (on the version 2 client
hello) has the following description:

     version           The highest version of the protocol supported
                       by the client (equals ProtocolVersion.version,
                       see Appendix A.1.1).

Appendix A.1.1 is on the record layer, not on the client hello;
App. E.1 could have said "equals ClientHello.client_version, see
Appendix A.4.1", but doesn't.  (The language that suggests that
TLS 1.0 servers may be doing better by sending {3, 0} in the record
version number, in contradiction to what is implied by E.1 and
A.1[.1], was only added with the TLS 1.0 specification, and only with
a fuzzy "should".)

> record procotol without hitches!

This certainly would be a very reasonable requirement (as in the
reverse case of SSL 3.0 servers when faced with the TLS 1.0 record
protocol).  One problem is that the specification does not say that it
is a requirement.  The more important problem is that various fielded
servers don't behave as well as we would like them to (i.e. don't
handle {3, 0} cleanly), whereas SSL 3.0-only servers showing the
reverse problem (not handling {3, 1} cleanly) appear to be rather
rare.  Now it appears to be the case that most client implementations
offering both SSL 3.0 and TLS 1.0 do send {3, 1} as both the record
version number and the client hello version number, and appear to get
along quite well.  You could say that these clients focus on their
role as TLS 1.0 clients (trying to interoperate with buggy TLS 1.0
servers as well), and try to *also* be SSL 3.0 clients (but without
extra effort for interoperating with deficient servers).

Thinking of it, it might actually be best if some clients use the
highest supported version for the record version number, and others
use the lowest supported version there, because this diversity
increases the probability that server problems about not tolerating
"strange" record version numbers will be found and fixed.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Oct 2006 18:44:21 +0200 (MET DST)

Bodo Moeller wrote:
> hello.

I totally disagree.  An Implementation of SSLv3 knows at best
all PDUs up to and including {3,0}.  It does NOT know whether there
are any changes in the {3,1} record protocol, and by design, it
should NOT try to parse records tagged with {3,1}.

Existing patches to SSLv3 only server do not claim to parse the
{3,1} record protocol, they try to parse inappropriately tagged
{3,0} records instead.

Similarly as a simple X.509 certificate that doesn't contain any
X.509v3 attributes ought to be tagged as X.509v1.  Implementations
that do otherwise are broken.

The original TLSv1 spec didn't contain a MUST, but rather a SHOULD,
so we ought to retain a SHOULD, and not contort it to a MAY to
cater the installed base of broken TLSv1 server implementations.

The client should use the lowest protocol version it is willing to
negotiate on the record protocol of the client hello, and the
desired protocol version (per default the highest it implements)
in the client protocol version field of the client hello.

Technically, if a client would agree to either SSLv3 or TLSv1.1,
but NOT TLSv1.0, then having a recommendation for sending {3,1}
in the record protocol would be quite weird (I don't want to
discuss whether such a combination makes sense).

Anyway -- a reliable indicator for the server that the client
is going to agree to a SSLv3 handshake is the presence of
{3,0} in the record protocol of the client hello message.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 19 Oct 2006 19:16:44 +0200

> that do otherwise are broken.

TLS 1.0 vs. SSL 3.0 is different than X.509v3 vs. X509v1 because it is
interactive: Faced with {3,1} records, a server that picks the SSL 3.0
protocol allows the client, in turn, to give the "You can't say we
never tried / ain't it time we said goodbye" fatal alert.  Oops,
sorry, wrong song, make that "protocol_version".

Remember that the SSL 3.0 specification and RFC 2426 and RFC 4346 all
imply that the record version number field is the "highest version of
the protocol supported by the client" (E.1 read in conjunction with
A.1.1 or A.1).  The language about "should send client hello messages
using the SSL 3.0 record format and client hello structure" could
reasonably be read as merely indicating that you can't send anything
that can't be parsed by following the SSL 3.0 specification and still
expect an SSL 3.0 handshake to succeed, in particular given that
RFC 2246 doesn't explicitly require TLS 1.0-only servers to tolerate
{3,0} in record version numbers.

> in the record protocol would be quite weird

Absolutely, but protocol versions that the client would agree to use
make some sense for the record version number field.

> {3,0} in the record protocol of the client hello message.

Agreed.  It just doesn't work the other way around, in practice: an
SSL 3.0 handshake may be possible even though the client did not
mention {3,0} anywhere.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Oct 2006 20:11:33 +0200 (MET DST)

Bodo Moeller wrote:
> A.1.1 or A.1).

Quite to the contrary.

There is one missing word in RFC-2246 Appendix E, but I argue that
it is a poor excuse for ignoring the quite clear comments on the
purpose of the two seperate version foelds (client version and
protocol version) where the actual data elements are defined.

As I wrote in early July, rfc 2246 Appendix E reads:

>    TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
>    is easy. TLS clients who wish to negotiate with SSL 3.0 servers
>    should send client hello messages using the SSL 3.0 record format and
>    client hello structure, sending {3, 1} for the version field to note
>    that they support TLS 1.0. If the server supports only SSL 3.0, it
>    will respond with an SSL 3.0 server hello; if it supports TLS, with a
>    TLS server hello. The negotiation then proceeds as appropriate for
>    the negotiated protocol.
 
the missing word is here:

    sending {3, 1} for the client_version field to note
                           ^^^^^^^
>
> The language about "should send client hello messages

I'm sorry, but if interoperability with SSLv3 is desired, this is
a very obvious implication.  And if "should send client hello messages
using the SSL 3.0 record format and client hello structure" isn't
clear, then I don't know what is clear.

Most, if not all protocol specs have defects or ambiguities.
The alleged ambiguity in Appendix E is fairly easy to figure by
doing a consistency check on the descriptions of the three
variants of version fiels "version, client_version, server_version"
throughout the document plus a grain of common sense.

The wording in rfc-2246 Appendix E suggests that this appendix was
written before TLSv1.0 was finalized, because it is vague in two
respects: it doesn't tell you wether the {3,1} record protocol differs
somehow from the {3,0} record protocol, and it doesn't tell you whether
the {3,1} ClientHello message differs from the {3,0} ClientHello
_structure_.

The record protocol NEVER EVER had a field to indicate the client_protocol
version in any version of the spec.  There are exactly two structures
to carry the client_version, the ClientHello and the PreMasterSecret.
And then there is the ServerHello structure which carries the
server(-selected/negotiated) protocol version.

This dicussion doesn't get us anywhere.  My proposal is to fix
the longstanding typo in Appendix E and to insert "client_"
where it has been missing.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 20 Oct 2006 09:03:58 +0200

> Quite to the contrary.

I am fully aware that language has been added in RFC 2426 and RFC 4346
that indicates that the record version number field should be be
{3, 0} for backwards compatibility.  However, here I was explicitly
referring to Appendix E.1, which consistently has said something else;
look at the SSL 3.0 specification, or at RFC 2426, or at RFC 4346.

Yes, perfect specifications probably would always have said that the
record version number field should use the lowest protocol version
supported by the client.  Well, but the SSL 3.0 specification didn't
do this, the TLS 1.0 specification arguably tried to do it, and the
TLS 1.1 specification again failed to do so!

If as a client you want to offer the choice between TLS 1.0 and
TLS 1.1, then according to RFC 4346 you should ("SHOULD", even) use
the SSL 3.0 record format, which would imply sending {3, 0} as the
record version number even though {3, 0} does not designate a protocol
version supported by the client!

So, after all, the presence of {3, 0} in the record protocol of the
client hello message is *not* a reliable indicator for the server that
the client is going to agree to a SSL 3.0 handshake ...  This is
something we had agreed upon before, but I have to take this back, at
least if implementors take this part of RFC 4346 that seriously.

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.

>                                          My proposal is to fix

I totally agree to this.  It is absolutely clear that Appendix E
should mention client_version explicitly when saying where the client
must put the highest supported version to be used for key agreement.

Bodo

---

From: <[email-masked]>
Date: Fri, 20 Oct 2006 15:26:12 +0300

> 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...

In Section 6.2.1, when describing the version field, add the 
following text:

   "Note that a client that supports multiple versions of TLS may not
   know what version will be employed before it receives ServerHello.
   See Appendix E for discussion about what record layer version
   number should be employed for ClientHello."

And rewrite 

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.

   A TLS 1.2 client who wishes to negotiate with such older servers
   will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS
   1.2) in ClientHello.client_version. If the server does not support
   this version, it will respond with ServerHello containing an older
   version number. If the client agrees to use this version, the 
   negotiation will proceed as appropriate for the negotiated protocol.

   If the version chosen by the server is not supported by the client 
   (or not acceptable), the client MUST send a "protocol_version" alert 
   message and close the connection.

   If a TLS server receives a ClientHello containing a version number
   greater than the highest version supported by the server, it MUST
   reply according to the highest version supported by the server.

   A TLS server can also receive a ClientHello containing version
   number smaller than the highest supported version. If the server
   wishes to negotiate with old clients, it will proceed as
   appropriate for the highest version supported by the server that 
   is not greater than ClientHello.client_version. For example, if 
   the server supports TLS 1.0, 1.1, and 1.2, and client_version is
   TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If 
   server supports (or is willing to use) only versions greater 
   than client_version, it MUST send a "protocol_version" alert 
   message and close the connection.

   Whenever a client already knows the highest protocol known to a
   server (for example, when resuming a session), it SHOULD initiate
   the connection in that native protocol.

      Note: some server implementations are known to implement version
      negotiation incorrectly. For example, there are buggy TLS 1.0
      servers that simply close the connection when the client offers
      a version newer than TLS 1.0. Also, it is known that some
      servers will refuse connection if any TLS extensions are
      included in ClientHello.

      Interoperability with such buggy servers is a complex topic
      beyond the scope of this document, and may require multiple
      connection attempts by the client.

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed). Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number. Typical values
   would be {03,00}, the lowest version number supported by the
   client, and the value of ClientHello.client_version. No single
   value will guarantee interoperability with all old servers, 
   but this is a complex topic beyond the scope of this document.

(and move all discussion of SSL 2.0 discussion to separate section,
appendix E.2)

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 23 Oct 2006 11:07:57 +0200

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

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

>    [...]

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:

   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.

   [...]

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

---

From: Jan Nordqvist <[email-masked]>
Date: Tue, 24 Oct 2006 10:04:11 -0700

Hi All,

We have an implementation of a TLS 1.0/1.1 stack for which we are 
seeking candidates for interoperability testing. None of the publicly 
available implementations that we have found implements TLS1.1 and we 
are therefore interested in getting access to a TLS implementation that 
does both TLS1.0 and TLS1.1 for interoperability testing and preferably 
also for regression testing.
Ideally we would like access to a trusted public domain implementation,
but as an alternative we could either consider access over the public
Internet or exchange a bundled test-suite with some other vendor under
an NDA.

Apart from the 1.1 support, an issue that surprises me somewhat is that
the static DH cipher suites, i.e. the TLS_DH_DSA and TLS_DH_RSA suites
rarely seems to be supported.
None of the TLS RFC's makes any statement, perhaps rightly, about
the AlgorithmIdentifier to use for DH keys in certificates. At the
same time it seems that X.509 DH certificates are somewhat arcane and I
have seen certificates using both 1.2.840.10046.2.1 (the X.509 suggested
dhpublicnumber) and  1.2.840.113549.1.3.1 (RSA/DH) as the
AlgorithmIdentifier as well as 1.2.840.113549.1.3.1 or
1.2.840.113549.1.5.16.1 (PKCS-8) for the private key id in the key-file.
Could it be that the lack of consistency here has something to do with
the lack of support for static DH in TLS?
Any comments or clarification here would be appreciated.

If anyone is interested in engaging in a mutual test setup, our interest
would involve testing out all of the RFC-4346 mandated cipher suites,
except the export suites, the Kerberos suites and the IDEA suite, with
and without client authentication, with and without "standard" stateful
session resumption and potentially stateful resumption per RFC-4507.

Thank you,

Jan Nordqvist
Software Architect
Lucent VitalAAA product group

---

From: "Pasi Eronen" <[email-masked]>
Date: Wed, 25 Oct 2006 09:56:36 +0300

Jan Nordqvist wrote:
> seeking candidates for interoperability testing. None of the
> publicly available implementations that we have found implements
> TLS1.1 and we are therefore interested in getting access to a TLS
> implementation that does both TLS1.0 and TLS1.1 for interoperability
> testing and preferably also for regression testing.  

Of the open source libraries, at least GnuTLS, TLS Lite, and Cryptlib
implement TLS 1.1. Opera web browser also has it, as does Certicom's
SSL-C library. (I'm not sure if any of those implement the static DH 
suites, though.)

Best regards,
Pasi

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 25 Oct 2006 21:51:43 +1300

"Pasi Eronen" <[email-masked]> writes:

>implement TLS 1.1. Opera web browser also has it, as does Certicom's SSL-C
>library. (I'm not sure if any of those implement the static DH suites,
>though.)

cryptlib definitely doesn't do static DH... in fact does anything?  Why would
anyone do it at all, for that matter?

Peter.

---

From: <[email-masked]>
Date: Wed, 25 Oct 2006 13:28:53 +0300

[email-masked] wrote:

> cryptlib definitely doesn't do static DH... in fact does anything?
> Why would anyone do it at all, for that matter?

Based on a quick look at the source code, at least OpenSSL, Mozilla
NSS, and PureTLS appear to support static DH. 

But I don't know why they do it either (or whether that part of the
code has actually ever been used or tested :-)

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Oct 2006 13:22:38 +0200

> code has actually ever been used or tested :-)

OpenSSL doesn't support static DH, actually.  There's anonymous and
non-anonymous ephemeral DH, there's static and ephemeral ECDH, but no
static DH with DH certificates.  (There's also some code that doesn't
totally neglect the possibility of having DH certificates, but this
doesn't mean it is actually used anywhere.)

Bodo

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 25 Oct 2006 12:36:23 +0100

> NSS, and PureTLS appear to support static DH. 

There is some code related to this in the SSL source but the relevant DH
certificate support was never implemented.

Well actually it is possible that PKCS#3 DH certificate support is
present in OpenSSL 0.9.9 but that is as an indirect result of other
changes. The PKCS#3 DH certificate request generation code isn't present
though.

I was at one point some years ago planning to add X9.42 DH support to
OpenSSL for S/MIME v3 but I only received one comment asking me *not* to
support it.

Finding test vectors for the parameter generation algorithm was also a
problem. The only ones I saw were either compatible with the DSA
algorithm or clearly broken. Various calls in public mailing lists
giving details about why I thought the existing ones were wrong met with
silence. I ended up concluding that if no one else was implementing it,
why should I?

> code has actually ever been used or tested :-)

Just about the only reason I can think of is a lower connection overhead.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: <[email-masked]>
Date: Wed, 25 Oct 2006 16:26:15 +0300

Hi Bodo,

Thanks for your comments. I agree about the first change;
the second change I would reword slightly...

>    support the highest protocol version available in the server.

This assumes the ClientHello format remains the same; perhaps this
is worth mentioning explicitly:

    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 ClientHello
    format remains compatible, and the client support the highest
    protocol version available in the server.

And here's the slightly cleaned text about SSL 2.0 compatibility:

E.2 Compatibility with SSL 2.0

   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message
   MUST contain the same version number as would be used for ordinary
   ClientHello, MUST use CHALLENGE-LENGTH of 32, and MUST encode the
   supported TLS ciphersuites in the CIPHER-SPECS-DATA field as
   described below.
  
      Warning: The ability to send version 2.0 CLIENT-HELLO messages
      will be phased out with all due haste, since the newer
      ClientHello format provides better mechanisms for moving to
      newer versions and negotiating extensions.  TLS 1.2 clients
      SHOULD NOT support SSL 2.0.

   However, even TLS servers that do not support SSL 2.0 SHOULD accept
   version 2.0 CLIENT-HELLO messages. The message is presented below
   in sufficient detail for TLS server implementors; the true definition
   is still assumed to be [SSL2].

   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
   way as a ClientHello with a "null" compression method and no
   extensions. Note that this message MUST be sent directly on the
   wire, not wrapped as a TLS record. For the purposes of calculating
   Finished and CertificateVerify, the msg_length field is not
   considered to be a part of the handshake message.

       uint8 V2CipherSpec[3];

       struct {
           uint16 msg_length;
           uint8 msg_type;
           ProtocolVersion version;
           uint16 cipher_spec_length;
           uint16 session_id_length;
           uint16 challenge_length;
           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
           opaque session_id[V2ClientHello.session_id_length];
           opaque challenge[V2ClientHello.challenge_length;
       } V2ClientHello;

   msg_length
       The highest bit MUST be 1; the remaining bits contain the 
       length of the following data in bytes. 

   msg_type
       The message type for V2ClientHello is one (1).

   version
       Equal to ClientHello.client_version.

   cipher_spec_length
       This field is the total length of the field cipher_specs. It
       cannot be zero and MUST be a multiple of the V2CipherSpec 
       length (3).

   session_id_length
       The length of the session_id field in bytes; MUST be zero
       for a client that claims to support TLS 1.2.

   challenge_length 
       The length of the challenge field in bytes; MUST be 32 for 
       a client that claims to support TLS 1.2.

   cipher_specs
       This is a list of all CipherSpecs the client is willing and
       able to use. In addition to the 2.0 cipher specs defined in
       [SSL2], this includes the TLS cipher suites normally sent in
       ClientHello.cipher_suites, each cipher suite prefixed by a zero
       byte. For example, TLS ciphersuite {0x00,0x0A} would be sent
       as {0x00,0x00,0x0A}.

   session_id
       This field MUST be empty.

   challenge
       Equal to ClientHello.random.

   Note: Requests to resume a TLS session MUST use a TLS client hello.

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Oct 2006 15:55:44 +0200

> This assumes the ClientHello format remains the same;

This is true, but intentional.  If the ClientHello format is ever
changed in an incompatible way such that existing servers cannot
handle it, then a client using this new format cannot support the
highest protocol version available in such servers.  (Unless they use
some kind of future backwards-compatible ClientHello, in which case
servers *can* easily handle such clients, after all.)  Well, and if a
client cannot support the highest protocol version available in the
server, then the above "as long as"-clause does not pretend to apply.

But I guess it still can't hurt to mention the format compatibility
requirement, and use your proposed wording:

>                                                       perhaps this

Bodo

---

From: EKR <[email-masked]>
Date: Wed, 25 Oct 2006 09:05:34 -0700

> NSS, and PureTLS appear to support static DH. 

I'm pretty sure that it hasn't been tested in PureTLS.

-Ekr

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 26 Oct 2006 05:07:55 +1300

>And here's the slightly cleaned text about SSL 2.0 compatibility:

I know I've said this before, but can't we finally kill SSLv2?  Both MSIE 7
and Firefox (Mozilla/whatever) have now removed support for it, which means
that it's finally dead no matter what the spec still says about it.

Peter.

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 25 Oct 2006 09:18:16 -0700

Bodo Moeller wrote:
> OpenSSL doesn't support static DH, actually.  

Neither does NSS.  The static DH cipher suites are explicitly disabled,
although much of the code necessary to support them is present in NSS.

> There's anonymous and

Likewise, NSS has code to parse (and even create) DH certificates, but
it is untested and unused because in the 10 years I've worked on NSS,
I've never seen a DH cert from any CA.  The Fortezza certs were DH certs,
but they were a rather special case, and the special case Fortezza code
is no longer supported in NSS.

-- 
Nelson B

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 25 Oct 2006 09:22:36 -0700

(My apologies if you receive two copies of this email.)

-- 
Nelson B

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 25 Oct 2006 09:31:49 -0700

> that it's finally dead no matter what the spec still says about it.

Not quite.  When FireFox 2 encounters a "TLS intolerant" server (one that
fails to negotiate a handshake properly when the client hello specifies
version 3,1) it reverts to a backward compatible mode in which it sends
SSL2 format client hellos bearing version 3,0, just as it has done for
over a decade.  Yes, this appears to be necessary with some servers,
and maximum interoperability is still the name of the browser game.

-- 
Nelson B

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 26 Oct 2006 05:40:47 +1300

Dr Stephen Henson <[email-masked]> writes:

>problem. The only ones I saw were either compatible with the DSA algorithm or
>clearly broken. Various calls in public mailing lists giving details about
>why I thought the existing ones were wrong met with silence. I ended up
>concluding that if no one else was implementing it, why should I?

I think this confusion over X9.42 details is pretty much universal, there's
been the ongoing saga of the S/MIME test vectors where as soon as someone
published vectors, someone else pointed out that they were wrong for one
reason or another.  Given their history, it's quite possible that they still
have errors, but people gave up looking (actually looking at RFC 4134 I can't
see any DH vectors in there at all, so I guess they used the ostrich algorithm
to solve the problem :-).

A related problem is that the X9.42 spec was never really a going concern in
the first place, it more or less sleep-walked into becoming a standard after
years in the doldrums when the contributors lost interest in it.  As a result
there are implementations based on all sorts of buggy drafts out there, in
fact for most of the time when it was still being pushed all you could get
were buggy drafts.

So perhaps the best option for TLS is to deprecate the static DH suites.  They
seem to be pretty much entirely unsupported, and even if you did want to
support them you'd end up in a quagmire from which extrication would prove
difficult.

Peter.

---

From: "tom.petch" <[email-masked]>
Date: Thu, 26 Oct 2006 11:18:59 +0200

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 25, 2006 6:07 PM
Subject: RE: [TLS] Open issue: Record Version Numbers

> I know I've said this before, but can't we finally kill SSLv2?  Both MSIE 7

Probably, but I am on MSIE6, because MSIE7 will not run on my OS and the
relevant OS will not run on my hardware without an expensive upgrade so no IE7;
and what is true for me at a personal level is true for many I work with.

I do have SSLv2 support disabled, offering a choice of SSLv3 or TLS 1.0, and am
not aware of any connection failures as a result but would not trust MS to tell
me in an intelligible form:-(  I will, soon, try disabling SSLv3 and see what
happens.

Tom Petch

---

From: <[email-masked]>
Date: Fri, 27 Oct 2006 12:30:31 +0300

Peter Gutmann wrote:

> So perhaps the best option for TLS is to deprecate the static DH
> suites.  They seem to be pretty much entirely unsupported, and even
> if you did want to support them you'd end up in a quagmire from
> which extrication would prove difficult.

This question may become important if we want to progress TLS 1.2 to
Draft Standard, where we need two interoperable implementations for
every feature.

Based on the discussion so far, it looks like static DH suites might
be one feature where meeting that bar could be difficult.

Any opinions from the WG about this? Should we e.g. remove static 
DH suites from TLS 1.2, move them to a separate document, or
something else?

Best regards,
Pasi

---

From: Rob Dugal <[email-masked]>
Date: Fri, 27 Oct 2006 09:28:03 -0400

The Certicom SSL-C product does contain implementations of static DH 
ciphersuites. 
We don't currently have a public server available for testing this 
implementation.
If there is enough interest we can add these ciphersuites to tls.secg.org

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [email-masked]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

---

From: Jan Nordqvist <[email-masked]>
Date: Fri, 27 Oct 2006 14:57:46 -0700

Well, since at least we went through the effort of implementing them it 
would be nice to test them out too...
OTOH, if no one else implements or uses them, they may be of little use 
in the real world. In any case, we are interested to get through 
testing, preferably both client and server side.

Jan Nordqvist
Lucent Technologies

Rob Dugal wrote:
> ------------------------------------------------------------------------
>