Subject: [TLS] Renego Indication RI patch interaction with TLS major version interop

From: Marsh Ray <[email-masked]>
Date: Tue, 15 Jun 2010 11:30:01 -0500

WTF?

Article from Yngve:
http://my.opera.com/yngve/blog/2010/06/02/renego-patched-servers-a-long-term-interoperability-time-bomb-brewing

http://www.links.org/?p=943

I haven't finished reading the full article yet, but I thought others
would be interested:
> In the past few weeks, as many as 80-90% of the newly patched servers
> have refused to negotiate with our tester (the TLS Prober) when it
> claimed to support the hypothetical v4.1 TLS protocol version (or, as
> I call it, "TLS NG"). This is much higher than the 69% of all servers
> that generally exhibit the same problem.

- Marsh

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 15 Jun 2010 11:46:11 -0500

> I haven't finished reading the full article yet, but I thought others
would be
> interested:

NSS has an explicit check that the first byte of every version number is
0x03. I imagine other implementations have a similar check. Version handling
in NSS will be revamped sometime before TLS 1.1 and TLS 1.2 support are
added to it, and  the patches for that work already remove the check for
0x03.

His test would probably be much more successful if he used 0x03FF as the
version number. I don't think it is a big deal; the main consequence is that
all TLS version numbers should continue to start with 0x03. 

Regards,
Brian

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 15 Jun 2010 10:06:06 -0700

There is an even bigger problem.  Both www.microsoft.com and www.ibm.com
abort an attempt at connecting to them using TLS 1.2 or even 1.1!  I have
not done more extensive testing to see how much of the Internet suffers
from this, but if these "big guys" can't get it right....

   ./TlsTest
   > tls12
   > www.microsoft.com
   TLS negotiation failed: TLS version mismatch
   > tls11
   > www.microsoft.com
   TLS negotiation failed: TLS version mismatch
   > tls10
   > www.microsoft.com
   Domain name match
   Finished message approved
   > tls12
   > www.ibm.com
   TLS negotiation failed: TLS version mismatch
   > tls11
   > www.ibm.com
   TLS negotiation failed: TLS version mismatch
   > tls10
   > www.ibm.com
   Domain name match
   Finished message approved
   > quit

A "version mismatch" error implies a protocol_version alert was received.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Tue, 15 Jun 2010 12:26:33 -0500

On 6/15/2010 11:46 AM, Brian Smith wrote:
> 
> NSS has an explicit check that the first byte of every version number
> is 0x03. I imagine other implementations have a similar check.
> 
> Version handling in NSS will be revamped sometime before TLS 1.1 and
>  TLS 1.2 support are added to it, and  the patches for that work 
> already remove the check for 0x03.

It's no excuse, but NSS is mainly used on the client side so it doesn't
cause an interop problem.

> His test would probably be much more successful if he used 0x03FF as
>  the version number.

Perhaps, but the point of the test is to find out what fails.

> I don't think it is a big deal; the main consequence is that all TLS 
> version numbers should continue to start with 0x03.

That's not something compliant servers are allowed to decide. The power
to set protocol version numbering policy belongs to the IETF and IANA
for good reason.

As an app-layer developer I usually assert that either endpoint has the
right to terminate the connection at any time for any or no reason. But
the exception is for proposed protocol versions and extensions. As the
specs say, they need to be simply ignored by the servers to prevent
problems with forward compatibility.

On 6/15/2010 12:06 PM, Michael D'Errico wrote:
> There is an even bigger problem.  Both www.microsoft.com and 
> www.ibm.com abort an attempt at connecting to them using TLS 1.2 or 
> even 1.1!

That's really lame.

> I have not done more extensive testing to see how much of the 
> Internet suffers from this, but if these "big guys" can't get it
> right....

A bit ironic, eh? Chances are they outsource their static content
hosting to the same providers or use the same offload accelerators as
everybody else. It'd probably be more significant if it were amazon.com
or google.com.

- Marsh

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Jun 2010 23:16:17 +0200

> from this, but if these "big guys" can't get it right....

Same for www.paypal.com.  Sigh.

jas@mocca:~$ gnutls-cli -p 443 www.paypal.com
Resolving 'www.paypal.com'...
Connecting to '64.4.241.49:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.
jas@mocca:~$ 

/Simon

---

From: Adam Langley <[email-masked]>
Date: Tue, 15 Jun 2010 17:31:58 -0400

> GNUTLS ERROR: A TLS packet with unexpected length was received.

Although I can confirm the brain damage exhibited by www.microsoft.com
and www.ibm.com, www.paypal.com doesn't have an issue with a
ClientHello advertising TLS version 1.2. It might have other problems,
but see the attached handshake.

AGL

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Jun 2010 23:53:22 +0200

Adam Langley <[email-masked]> writes:

> but see the attached handshake.

After some debugging, I can confirm that TLS 1.1/1.2 is not the problem.
The aspect causing problems with www.paypal.com is record padding,
because this works:

gnutls-cli -p 443 www.paypal.com --priority NORMAL:%COMPAT

Random record padding has been part of TLS since a long time.  Alas,
GnuTLS appears to be the only implementation making use of this.  It has
to be supported, though, even RFC 2246 contained this wording:

   padding
       Padding that is added to force the length of the plaintext to be
       an integral multiple of the block cipher's block length. The
       padding may be any length up to 255 bytes long, as long as it
       results in the TLSCiphertext.length being an integral multiple of
       the block length. Lengths longer than necessary might be
       desirable to frustrate attacks on a protocol based on analysis of
       the lengths of exchanged messages. Each uint8 in the padding data
       vector must be filled with the padding length value.

We've seen many implementations that barf on random record padding.

/Simon

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 15 Jun 2010 17:12:30 -0500

Marsh Ray wrote:
> That's not something compliant servers are allowed to decide. The power to
set
> protocol version numbering policy belongs to the IETF and IANA for good
reason.

Marsh,

I just mean that the article is misleading in that it implies that the vast
majority of servers are implementing the renegotiation protection draft
incorrectly, when really they are implementing something else wrongly that
doesn't have a *practical* effect on renegotiation protection. If the test
fails for 0x03FF then, yes, there may be something to worry about. But I
think we would all be quite relieved if supporting versions >= 0x0400 was
one of the top 10 (or 100) most pressing issues regarding TLS. 

Regarding NSS on servers: I think it will become increasingly common due to
initiatives like the following
http://fedoraproject.org/wiki/FedoraCryptoConsolidation
http://en.opensuse.org/SharedCertStore

Regards,
Brian

---

From: Marsh Ray <[email-masked]>
Date: Tue, 15 Jun 2010 18:10:26 -0500

> doesn't have a *practical* effect on renegotiation protection.

I agree. Still it seems weird though that patching for RI would
introduce new breakage systematically across multiple implementations or
distributions, which is why I brought it to this list. No evidence of a
spec bug yet it seems.

Given the adoption rate (0 to 12% increase in time period of graph) I
would have thought the "all servers" (red) line would have shown a
little of the wild variation from the "renego patched" (blue) line.
Perhaps it's not all servers, but non-patched servers on the red line.

> If the test

Still, we need to be aware of it. As we've seen, this class of issue can
just as easily be a problem with clients advertising version 1.1. Thank
you Yngve and Opera for compiling and publishing this info!

> http://en.opensuse.org/SharedCertStore

Those are interesting projects. Though I'm not sure I'm ready to unify
my web browser and SSH server under a single trust model yet. :-)

- Marsh

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 16 Jun 2010 01:50:12 +0200

> but see the attached handshake.

For reference, my prober utility (which is not testing everything, yet ;),  
like not checking record padding variation ) diagnoses www.paypal.com with  
the following:

   - Not renego patched
   - Version intolerant (refuses to negotiate with client specifying TLS  
NG, v4.x)
   - No version checking of RSA Client Key Exchange (CKE)
   - Does not support AES

www.microsoft.com and www.ibm.com results:

   - Not renego patched
   - Version intolerant (refuses to negotiate with client specifying TLS  
1.1 or higher)

For those interested, at present

   - 3.4% of 383531 probed servers are intolerant in the 3.x range (69%  
including the 4.x range, 83% of renego patched server also in the v4.x  
range)
   - 0.4% require RSA CKE version field to match negotiated version
   - 31.6% does not check the RSA CKE version field
   - 43 of 383531 servers mirror the client hello version back to the client
   - 990 of 383531 server use the record protocol field instead of the  
client hello version when negotiating
   - 99 of 383531 support TLS 1.1
   - 2 of 383531 support TLS 1.2 (both are known test servers)

Among renego patched servers, while virtually all are tolerant in the v3.x  
range, recently some that are version intolerant in the v3.x range has  
started to show up. From this week's run:

    live.rapidswholesale.com
    pazion.nl
    hypotheek-aanvragen.nl
    droog.com
    sso.u-bordeaux3.fr
    www.seekame.com

None of these six servers tolerate v3.4, "TLS 1.3" (multiple tests  
performed), TLS 1.2 was accepted. Most of them identify as Apache, but  
there is no commonality in version numbers, and I suspect that the block  
is done by a server or firewall in front of the servers.

There were also two other servers that showed up in this weeks run, but  
those detections may be false positives due to other issues.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Jun 2010 02:00:39 +0200 (MEST)

Brian Smith wrote:
> 0x03. I imagine other implementations have a similar check.

Our OEM implementation restricts the version_minor range besides
requiring 0x03 for the version_major. (I added version_minor range
check several years ago when I noticed interop problems with TLSv1.1).

OpenSSL 0.9.8 seems to require a version_major of 0x03 as well.

One version_major value was already re-purposed for DTLS.
IMHO, the assumption that protocol version negotiation would work
for completely arbitrary protocol versions is flawed.

If Yngve was to collect any meaningful data on version negotiation
capabilities, he should test with version 0x03,0x03 (TLSv1.2)
and 0x03,x04 (not yet defined).

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 15 Jun 2010 17:07:25 -0700

> - 43 of 383531 servers mirror the client hello version back to the client

Yngve,

Can you please explain what you mean by a server mirroring the client
hello version back to the client?  That sounds like the correct thing
to do, unless they don't actually support that version.

Thanks,

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Jun 2010 02:37:00 +0200 (MEST)

> including the 4.x range, 83% of renego patched server also in the v4.x  

Which means that the few renego patched implementations that have
been installed are those that are intolerant to protocol version v4.x

>    - 31.6% does not check the RSA CKE version field

There had been defective clients sending incorrect RSA CKE versions,
and a change from non-checking to checking the value in a server
implementation would suddenly break interop with those (old) clients.

Checking of the RSA CKE version field is only for the situation that
your server (a) allows extremely weak cipher suites and the client
offers nothing but extremely weak cipher suites.

> client hello version when negotiating

I assume that by "client hello version" you are actually refering
to the "client_version" field of the ClientHello handshake message?

>    - 2 of 383531 support TLS 1.2 (both are known test servers)

That's even less than what I would have expected.

How many of these 383531 servers are still at SSLv3?

> performed), TLS 1.2 was accepted.

There is no such thing as TLS 1.3 and given the adoption rate of
TLSv1.1 and TLSv1.2, the message from implementors seems clear:
fancy features for which there is no pressing need for a significant
fraction of the installed base should be implemented and negotiated
through a TLS extension rather than a new TLS protocol revision.

Looking at the GOST cipher suites for TLS, implementations are doing
the TLSv1.2-style replacement of the PRF while still running at TLSv1.0,
and it works (and is MUCH less work than having to implement full
TLSv1.1 and v1.2 first).

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 16 Jun 2010 08:08:49 +0200

> to do, unless they don't actually support that version.

What I mean by "mirroring" is that the server will respond with TLS 1.2  
(3.3) if the client sends it, even if the server only support SSL v3 or  
TLS 1.0, eventually causing a handshake failure. Similarly the server will  
respond with 3.4 or 4.1 if the client sends those.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 16 Jun 2010 08:08:32 +0200

> been installed are those that are intolerant to protocol version v4.x

No, the number was above 60% before renego patching started (the renego  
patched servers are 13% of the total)

> implementation would suddenly break interop with those (old) clients.

As you can see, ~68% of servers seem to have no problem checking it.

> offers nothing but extremely weak cipher suites.

It is also for the case in which a weakness is discovered in an old  
version that enable an attacker to perform a version rollback attack.

Although, considering that this check is only performed in RSA, not DH  
type key exhange, one can wonder if it is at all needed.

> to the "client_version" field of the ClientHello handshake message?

Yes,

> How many of these 383531 servers are still at SSLv3?

1.6% (~6000), but renego patched are actually at about 0.4%, so many are  
upgrading.

> There is no such thing as TLS 1.3 and given the adoption rate of

No there is not, but the specification is clear on this point: The server  
MUST send its highest supported version whenever the client indicates a  
higher version than it supports.

> through a TLS extension rather than a new TLS protocol revision.

Which would lead to a mess of extensions after a while for things that can  
be better indicated in a version field.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 16 Jun 2010 17:03:47 +0100

In case anyone is interested, I've just added a version intolerance
test to the online assessment tool at SSL Labs. For example:

   https://www.ssllabs.com/ssldb/analyze.html?d=ibm.com

Version intolerance results are at the bottom. I test for 0x0304,
0x0399 and 0x0499.

Suggestions welcome.

On Tue, Jun 15, 2010 at 5:30 PM, Marsh Ray <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Ivan Ristic
ModSecurity Handbook [http://www.modsecurityhandbook.com]
SSL Labs [https://www.ssllabs.com/ssldb/]

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Jun 2010 18:48:16 +1200

>0x03. I imagine other implementations have a similar check.

I do that too, and it's quite deliberate, we've been using 3.x for 15-odd
years and there's no sign, even with major incompatible protocol revisions,
that we're going to 4.x at any point.  Any change to 4.x is therefore going to
either never happen or will be something so major, probably a complete break
of the entire protocol, that I want to force users to upgrade to a completely
new release.

>version number.

That's the other thing, if 4.x does ever appear then servers can use the SSH
2.x trick of advertising version 'next-version - 1' (in SSH it was 1.99, in
TLS it'd presumably be 3.255 or at least 3.99) to indicate a backwards and
forwards-compatible server.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Jun 2010 18:58:03 +1200

>   - 0.4% require RSA CKE version field to match negotiated version

This is because of a bug in MSIE, but the logic for checking for the bug is a
bit convoluted:

	/* Older versions of MSIE send the wrong version number for the premaster
	   secret (making it look like a rollback attack) so if we're expecting
	   3.1 from the client and get 3.0 in the premaster secret then it's MSIE
	   screwing up.  Note that this bug-check is only applied for SSL and TLS
	   1.0, for TLS 1.1 and later the check of the version is mandatory */

Presumably you're checking for 3.1 vs. 3.0, thereby triggering the MSIE bug-
workaround.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Jun 2010 06:56:37 -0500

On 6/17/2010 1:48 AM, Peter Gutmann wrote:
>> NSS has an explicit check that the first byte of every version 
>> number is 0x03. I imagine other implementations have a similar 
>> check.
> 
> I do that too, and it's quite deliberate, we've been using 3.x for 
> 15-odd years and there's no sign, even with major incompatible 
> protocol revisions, that we're going to 4.x at any point.

But this is the part of the handshake where the protocol version hasn't
actually been agreed on yet. Some future TLS may, in fact, be a big
protocol change but a server is still wrong to refuse to interoperate on
the basis that the client merely proposed a higher protocol version.

For testing purposes, a client which specified a client_version of
0xFFFF should be able to successfully handshake using the highest
version the server supports. This works with some implementations today.

> Any change to 4.x is therefore going to either never happen or will 
> be something so major, probably a complete break of the entire 
> protocol, that I want to force users to upgrade to a completely new 
> release.

A. We don't know anything about future protocols yet, other than that
the client hello message will probably try to maintain compatibility
back to 1.0 and IANA-assigned identifiers won't collide. If, after all,
TLS version 1.2 is 0x0303 then who can say what 0x0404 will mean?

B. What if every protocol implementer and application developer acted
this way? What if they applied predictive numerology on reserved values
and decided to break compatibility in order to "force users to upgrade"?
Big vendors can have legal concerns which discourage that sort of thing
but unfortunately it seems common among smaller ones.

If a significant percentage of client-version-intolerant servers are
allowed to pollute the ecosystem, clients implementing some future TLS
(or TLS-compatible) protocol with a version number encoding other than
0x03xx will experience problems. They will be slowed down by failed
handshakes. Application code will be forced to implement complex
fallback reconnection schemes that are subject to downgrade attacks.

The net effect will be to simply slow the adoption of future protocol
versions and make it more difficult to evolve TLS without compatibility
problems. For example, fixing the renegotiation auth gap would have been
easier if actual servers consistently ignored hello extensions that they
didn't care about.

It may end up that it's just impractical for a client to ever advertise
a version number that doesn't look like 0x03xx. If that is the case,
then there's a wasted byte in the protocol header.

Here are my take-aways (from this and some other experiences):

* Protocols are hard, extensible ones moreso. Even for seemingly simple
stuff like version agreement, the default state seems to be
non-interoperability. This makes it interesting.

* Don't encode a version as separate components unless there are useful
distinctions between each component. In the absence of defined semantics
people will interpret their own.

* If an optional protocol feature has no implementations that are
available and widely used for testing, it can be relied on not to work.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Jun 2010 00:26:51 +1200

Marsh Ray <[email-masked]> writes:

>* If an optional protocol feature has no implementations that are available
>and widely used for testing, it can be relied on not to work.

And that's exactly why I reject major versions other than 3, I have no idea
what version 4 will be or require, and I also have no way of checking that I'm
not subject to some sort of rollback attack or who knows what if I include
handling for a 4.x version.  So in order to force users to get a version that
deals with whatever security catastrophe 4.x is meant to address, I want to
make sure that they're forced to upgrade.

This was a problem with PGP 2.x, there was never any strong reason for people
to upgrade, and it took forever to get people to move off it (some are still
using it).  Someone (from memory it was Jon Callas) has complained that PGP
2.x needed some fatal flaw found in it to force people to finally move to
OpenPGP.  So having a fall-over-and-die trigger can be a good thing, not a
flaw.

In any case though since no-one has any idea what 4.x will be, or why we'd
need to move to it, or whether it will ever appear, this is all just
speculation, it's like arguing over what clothes work best for interstellar
travel.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Jun 2010 09:01:34 -0500

On 6/17/2010 7:26 AM, Peter Gutmann wrote:
> handling for a 4.x version.

Your implementation is saying to the remote endpoint: "Even though there
is a highest protocol version which we both support, and even though I
am willing to talk that version in general, I am not willing to
handshake you at all because you said you also supported some version
higher than that."

Again, nowhere in RFC 5246 does it say that a ClientHello
client_version.major other than 0x03 will equate to a "4.x" TLS version
or give any significance to 4 (other than that it is greater than 3).

Instead, it says:
> 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.

> So in order to force users to get a version that

I guess I see some kind of Kafakaesque logic in the idea of an paranoid
endpoint gaining security by refusing to interoperate with newer
implementations.

But why stop there? It would be even more effective for the compromised
implementation to delete itself from disk once a higher protocol version
is observed on the network. That would also be an elegant solution to
the problem of having to work around all those intolerant servers in the
fix for catastrophic break.

It should probably also trip fail-safe whenever a client proposes a
ciphersuite it hasn't seen before. Could be an indication that the one
it otherwise would have chosen has a major weakness. Don't forget
unexpected compression methods and unknown extensions either! After all,
the presence of the new ciphersuite value and/or RI extension is, in
fact, an indication that the original protocol had a major flaw.

Alternatively, you could log a warning message or find some other means
to get the point across.

> OpenPGP.  So having a fall-over-and-die trigger can be a good thing, not a

Cause enough pain for your users and I guess they'll switch to something
else. Did you consider that it also causes pain for those trying to fix
and extend the protocol using the methods defined in advance for that
purpose?

When updating the protocol we heard repeatedly that avoiding interop
problems with the installed base must be the number one requirement.
With the renegotiation bug people insisted it would take forever to get
everyone patched. But if the patch did not interop, no one would patch
at all.

Look back at the mailing list. We knew of a single server on the
internet that went into a slow fail condition when it received extension
data on a client hello. That was one server was taken seriously as a
significant factor in the adoption of the ugly kludge workaround for
intolerant.

So the effect of that "fall-over-and-die" approach is going to be far
more of a hindrance to the adoption of a fix to the protocol than it is
likely to protect anyone using such an implementation.

If the protocol really turns out to be broken in such a systemic way
that "4.x" is only solution, there's a good chance the attacker will be
able to undetectably modify the version number your endpoint sees anyway.

> speculation, it's like arguing over what clothes work best for interstellar

Hmm, I don't really think so. We're talking about specific behavior
mandated by the current RFCs and principles which have numerous examples
of actual use. It's similar to the warnings-as-errors discussion we were
having earlier.

Oh and it'll definitely be a silver lame' catsuit for me.   :-)

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Jun 2010 16:20:59 +0200 (MEST)

> version the server supports. This works with some implementations today.

Maybe you want to turn your attention to the DTLS spec
and reconsider your recommendation:

http://tools.ietf.org/html/rfc-4347#section-4

      version
       The version of the protocol being employed.  This document
       describes DTLS Version 1.0, which uses the version { 254, 255
       }.  The version value of 254.255 is the 1's complement of DTLS
       Version 1.0. This maximal spacing between TLS and DTLS version
       numbers ensures that records from the two protocols can be
       easily distinguished.  It should be noted that future on-the-wire
       version numbers of DTLS are decreasing in value (while the true
       version number is increasing in value.)

> TLS version 1.2 is 0x0303 then who can say what 0x0404 will mean?

TLS protocol_version numbers work differently.  The version negotiation
is not capable of dealing with "holes".  So the next version of TLS
should be using the protocol_version of { 0x03, 0x04 }, no matter how
much it differs from TLSv1.2 (protocol_version { 0x03, 0x03 }) and
even if we give it the "marketing name" TLSv2.0, it should use the
protocol_version { 0x03, 0x04 } on the wire.

But there is really a design problem in the "common version" negotiation
of TLS because of the implication that the client supports lower
protocol version than the one it proposes.

If we were to define a substantially different TLSv2.0, and a problem
would be found that needed fixing, the current versioning precludes
that a TLSv1.3 is defined _after_ a TLSv2.0.  -- which is why I
strongly prefer fancy new features to be added through TLS extensions
rather than a bump of the protocol version -- because it can be
more easily adopted by implementations and the installed base.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Jun 2010 10:26:50 -0500

>        version number is increasing in value.)

I'm happy to be proven wrong (if get educated in the bargain :-), but I
don't think that's quite it. That section is talking about the record
layer version field, I was talking about the version negotiation in the
Hello messages.

The DTLS ClientHello message appears to be incompatible with a TLS
ClientHello, a new field was added right in the middle. So that record
layer number would be needed to interpret them (assuming it would ever
make sense for them to be in a context together where they could be
confused).

If this record layer version field is, in practice, being overloaded to
work as some sort of protocol identifier it should probably be managed
properly by the IANA. OTOH, maybe this is just a hint for Wireshark.

The TLS RFCs do not cite the DTLS RFC, therefore DTLS is basically
considered different protocol, right? According to the TLS RFCs and
normative references I read, a TLS server MUST have the behavior I
described. That's based on my dim understanding, but surely others know
how to interpret these things better.

>> If, after all,

So what what we _can_ say about {0x04, 0x04} then is that it is the
257th version after TLSv1.2.

This might support my argument that we shouldn't think of them as
{major, minor} numbers at all, but as a simple unint16. Leave the "x.y"
version numbers to Marketing, unless there's some reason to define the
semantics that way.

> protocol version than the one it proposes.

If the server selects his highest version, and that turns out to be
lower than the client's lowest supported version, then they don't have
any version in common and wouldn't be able to successfully handshake anyway.

> more easily adopted by implementations and the installed base.

I guess, in theory, the client and/or server could support noncontiguous
ranges of versions (there are three or four of them now after all). If
that ever turns out to be needed, it seems like it could be supported in
a straightforward way with a Hello extension.

- Marsh