Subject: [TLS] A new TLS version negotiation mechanism

From: Dave Garrett <[email-masked]>
Date: Sun, 8 Mar 2015 12:39:47 -0500

A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+. It'll be needed to handle draft implementations, if desired, and I think it might just be wanted for all negotiation. TLS 1.3 version intolerance is currently surveyed to be in the ~1.5% range [1]. The simplest method is to do so via a new mandatory extension, as has been suggested by people before. Here's a straightforward outline to get the ball rolling.

Versions would be negotiated with a new "Extended TLS Version Negotiation" extension with the following contents:

struct {
  uint8 versions<0..2^8-1>;
} SupportedVersions;

where versions contains an ordered list of the supported TLS minor versions. A block of numbers would be reserved for draft versions. (e.g. ID 32+ for drafts)

ClientHello would include the extension with its supported versions list. IFF a server receives the extension, then it would include its corresponding set in its ServerHello. (if no version is negotiated, this would make error reporting/diagnosis much better) The ServerHello.version would still be set to the version picked by the server, now the highest supported version from the client's set that the server supports. The ClientHello.version in this negotiation mechanism would be frozen to {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2. Clients could set this to {0,0} to force only the new mechanism with no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are all undesirable). The set of valid values for this field would be limited to exactly 5.

Additionally, I propose dropping the TLSCiphertext.version field entirely. (needs PR #51 [2] or similar; PR #51 primarily proposes encrypting ContentType, also a good idea) It's a waste of 2 bytes per record. TLSPlaintext.version would have to stay for backwards compatibility (see PR #51). Version handling would be restricted to just the hellos.

Why?
1) Too many implementations botched the existing version negotiation mechanism.
    This one requires nothing new for existing implementations to handle. (transparent fallback to TLS 1.2)
2) This method allows for non-continuous version support to be negotiated.
    (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4)
3) Draft implementations would be easily negotiable using the same method as release.
    (HTTP/2 benefited from widespread testing of drafts; doing so here could be helpful too)
4) Client implementations are not encouraged to go back to the old habit of insecure fallback, nor rely on SCSV for TLS 1.3+.
5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Microsoft could tolerate. They don't like SCSV as-is [3], and I tend to agree with their sentiment.
6) In the event of handshake failure due to an unsuitable version selected by the server, the client will have received a SupportedVersions set from the server to know exactly what is and is not supported.

Why not?
1) Kinda ugly to freeze a hello field and hack in a new negotiation method.
2) Some people don't like advertising all supported versions openly.
    (TLS 1.0-1.2 could be left out of the list to force only old implementations to consider them)
3) Failing to connect to the broken ~1.5% of servers that can't negotiate correctly is the "Right Thing To Do".
4) A few extra bytes in the hello messages. (though, far fewer overall if record layer is changed as proposed)

I would prefer to get PR #107 [4] committed prior to a brand new mechanism, if possible.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg15141.html
[2] https://github.com/tlswg/tls13-spec/pull/51
[3] http://www.ietf.org/mail-archive/web/tls/current/msg15391.html
[4] https://github.com/tlswg/tls13-spec/pull/107

Comments?

Dave

---

From: Brian Smith <[email-masked]>
Date: Tue, 10 Mar 2015 07:08:27 -0700

Dave Garrett <[email-masked]> wrote:
> A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+. It'll be needed to handle draft implementations, if desired, and I think it might just be wanted for all negotiation. TLS 1.3 version intolerance is currently surveyed to be in the ~1.5% range [1]. The simplest method is to do so via a new mandatory extension, as has been suggested by people before.

I agree that that seems like the best way forward.

> where versions contains an ordered list of the supported TLS minor versions.

1. Nit: It seems unnecessary to wrap a single data item in a struct.

2. I don't see why, for non-draft versions at least, the client needs
to tell the server about any version it supports other than the newest
version. It is not good to indicate support for older (worse) versions
unnecessarily. Particularly for clients that support non-secure
fallback, it is not good to tell the MitM the weakest version that the
client would fall back to.

I suggest that you change the definition of the client extension value
to be just:

    ProtocolVersion client_version;

which would be specified exactly like ClientHello.client_version is specified.

> A block of numbers would be reserved for draft versions. (e.g. ID 32+ for drafts)

I don't think it is worth making the main version negotiation
mechanism more complicated and error-prone just to support advertising
draft versions. There could be a draft_subversion extension that could
be used to indicate support for a draft revision of the version
indicated in the client_version extension instead.

> The ClientHello.version in this negotiation mechanism would be frozen to {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2.

I suggest also renaming ClientHello.client_version to
ClientHello.always_0x03_0x03 to avoid confusion.

> Clients could set this to {0,0} to force only the new mechanism with
> no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are
> all undesirable).

{ 0, 0 } would probably have even more issues with TLS intolerance
than we've historically experienced. AFAICT, this "forcing" feature is
not necessary so I suggest you just drop it.

> Additionally, I propose dropping the TLSCiphertext.version field entirely.

I suggest doing that separately as its own proposal.

>     (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4)

We don't need this.

> 3) Draft implementations would be easily negotiable using the same method as release.

That is a plus, but the added complexity on non-draft implementations
is worse than the benefit.

> 4) Client implementations are not encouraged to go back to the old habit of insecure fallback, nor rely on SCSV for TLS 1.3+.

Right. This is the primary motivation for moving
ClientHello.client_version to an extension.

> 5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Microsoft could tolerate. They don't like SCSV as-is [3], and I tend to agree with their sentiment.

It doesn't seem worth making the protocol more complicated to
facilitate performance optimizations of bad behavior.

> 6) In the event of handshake failure due to an unsuitable version selected by the server, the client will have received a SupportedVersions set from the server to know exactly what is and is not su…

Only if the client is negotiating TLS 1.4 or later and the server
supports at least TLS 1.3. IMO, not worth it.

Anyway, I support your proposal, if it is simplified.

Cheers,
Brian

---

From: Dave Garrett <[email-masked]>
Date: Tue, 10 Mar 2015 13:27:23 -0400

Thanks for the feedback.

> 1. Nit: It seems unnecessary to wrap a single data item in a struct.

Just following the general style of some other extensions. Technically, each index of extension_data itself could be used as-is without wrapping, but specifying it generically seems best.

> client would fall back to.

I did list that as one reason to consider against this.

My argument is that:
1) If we're replacing the version negotiation, we should make it better instead of merely kludging around intolerance.
2) No TLS 1.3+ client should be supporting insecure fallback AT ALL. This is a hard requirement for this.
3) Using an entirely different mechanism for draft and release could be prone to mistake. Better to test early.

> indicated in the client_version extension instead.

My initial idea was to have two essentially identical extensions, but with a different ID for release and draft. However, as I said above, this feels more complicated than needed and I'd rather just use one consistent mechanism for everything. Reserving part of the ID space for draft is not that complicated. It'd just be essentially turning the field into an enum value.

> ClientHello.always_0x03_0x03 to avoid confusion.

Renaming fields for clarity makes sense.

> not necessary so I suggest you just drop it.

It's to deal with a specific issue I thought of just before sending the email. If a client considers TLS 1.0-1.2 to be unsafe and attempts a connection of TLS 1.3+, then TLS 1.2 servers will still respond with ServerHellos due to the frozen field. Clients would have to essentially fake offers and abort on TLS 1.2. Any new mechanism should not have oddities like this that can't be resolved properly.

Server TLS version intolerance is essentially fine in the TLS 1.3+ only case. An abort instead of reject is fine. There could be issues with crap in the middle, though, yes.

This is essentially just a contingency that I think needs to be stated, but might never be needed.

> I suggest doing that separately as its own proposal.

Yep. Just bringing it up here too.

> >     (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4)

If TLS actually puts out more iterations, then we do, and this could make negotiating more frequent iterations easier. If TLS 1.3 or 1.4 is the final version, then we don't.

For draft versions, though, it could really be useful. Think ALPN/NPN; HTTP/2 draft negotiation would not have worked very well without the ability to list multiple specific versions at once.

> is worse than the benefit.

Again, it depends on how long until TLS ends. If TLS intends to go up to 1.9+, then I think it's quite worth it. If TLS ends soon and everyone transitions to a TCP-replacement with a new security layer, then no, this could be too complex. To start, though, I decided to propose the full generic route.

> supports at least TLS 1.3. IMO, not worth it.

Again, it depends on how much further TLS actually goes. Draft versions could also benefit more.

> Anyway, I support your proposal, if it is simplified.

If simplified to just a move of the field, I'd be more likely to propose just coordinating a block of the ~1.6% of the Internet that can't negotiate properly and keep the old mechanism. The only reason I agree a simplified version of this could be needed is that I don't believe implementers have the guts to do this properly. :/

A notable part of the Web really does warrant breaking, but nobody wants to do it.

Dave

---

From: Stephen Checkoway <[email-masked]>
Date: Wed, 11 Mar 2015 12:23:10 -0400

>  uint8 versions<0..2^8-1>;

I think this is a bad idea for two main reasons.

1. As soon as we have multiple mechanisms for signaling versions, implementations are going to have (more) bugs. I suspect bugs will arise for ClientHello.version set to something other than 1.2 with this extension present.

2. It's not clear that adding a second mechanism would actually improve the situation. If implementors aren't handling a very simple version negotiation correctly, then they are almost certainly not going to handle a more complex version negotiation correctly. So why would we suspect this won't lead to a new type of version intolerance?

Version-intolerance became an issue because there were not all that many versions. As protocol and performance issues have driven demand for TLS > 1.0, version intolerance has dropped dramatically (although it clearly still exists given the fallbacks some clients do).

I expect this problem to get better over time and do not see a need to add more complexity to solve what I hope will soon become a nonissue.

Now it may be the case later down the road that with n versions of TLS, implementors might choose to skip versions. Until that's a real concern, I don't think we should add complexity to  support what may not ever become a real use case.

-- 
Stephen Checkoway

---

From: Dave Garrett <[email-masked]>
Date: Wed, 11 Mar 2015 12:52:23 -0400

> 2. It's not clear that adding a second mechanism would actually improve the situation. If implementors aren't handling a very simple version negotiation correctly, then they are almost certainly no…

The primary source of TLS version intolerance is the small portion of the Internet running junk they haven't upgraded in a decade and a half. Non-ancient implementations are generally fine in this area, and I (possibly naively) expect TLS 1.3 implementations to be notably better in dealing with this sort of thing.

The primary reason why TLS version intolerance became a problem at all is that all browser vendors started doing insecure fallback and letting it slide. I am (possibly naively) expecting this to not be a bit of history we're likely to repeat as easily. An extension to systematically work around the existing junk makes this more likely to not regress into "yeah, sure, whatever" security again.

Mandating SCSV support in the TLS 1.3 spec could be a band-aid to deal with this, but some have noted that they really dislike it (for valid reasons).

> I expect this problem to get better over time and do not see a need to add more complexity to solve what I hope will soon become a nonissue.

If no strict coordination is done for TLS 1.3, it will stop getting better. TLS 1.3 intolerance is in the 1.5% range. (though, I suspect real-world testing might show that inability to deal with a TLS 1.3 handshake might be higher) Insecure fallbacks will be the norm again.

-----

I'm going to reiterate, though: I would MUCH rather use the existing version negotiation method and have all vendors agree to completely forbid all insecure fallback in all browsers on the same day, in unison. (to the hour, preferably) A coordinated "Break the Web" day where all vendors cease support for this crap would be the correct solution. However, I have no confidence that this is capable of being organized and completed without a last minute bail by someone. I don't even think everyone could agree to coordinate an interstitial warning for this first.

Anything I say in the context of proposing an alternate version negotiation mechanism should please be taken in the context that I agree with you that it's not the right way to do things. Any solution is better than no solution, though. :|

Dave

---

From: Stephen Checkoway <[email-masked]>
Date: Wed, 11 Mar 2015 14:13:56 -0400

> The primary source of TLS version intolerance is the small portion of the Internet running junk they haven't upgraded in a decade and a half. Non-ancient implementations are generally fine in this…

I'm not sure how this proposal helps here. Do you expect that there's a significant fraction of servers that (a) tolerate 1.2; (b) don't tolerate > 1.2; and (c) aren't maintained or can't be upgraded? I'd be surprised by data showing this. I imagine that any server satisfying (b) and (c), probably doesn't satisfy (a) so this proposal doesn't help.

> Any solution is better than no solution, though. :|

I don't agree. This is the "something must be done; this is something; therefore it must be done" argument.

-- 
Stephen Checkoway

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 11 Mar 2015 19:43:20 +0100

Hi,

On Wed, 11 Mar 2015 17:52:23 +0100, Dave Garrett <[email-masked]>  
wrote:

>> 1. As soon as we have multiple mechanisms for signaling versions,  
>> implementations are going to have (more) bugs. I suspect bugs will  
>> arise for ClientHello.version set to something other than 1.2 with this  
>> extension present.

I agree that this is likely.

>> 2. It's not clear that adding a second mechanism would actually improve  
>> the situation. If implementors aren't handling a very simple version  
>> negotiation correctly, then they are almost certainly not going to  
>> handle a more complex version negotiation correctly. So why would we  
>> suspect this won't lead to a new type of version intolerance?
>
> The primary source of TLS version intolerance is the small portion of  
> the Internet running junk they haven't upgraded in a decade and a half.

At present, in my 530K server sample, 2.25% of servers are registered as  
failing if the Client Hello indicates 3.4 (TLS 1.3) as the version.

0.8% of servers are 3.4 intolerant and *not* patched for Renego, meaning  
1.4% are renego patched (meaning that 60+% were updated in the last _5_  
years, at least). And just to make the picture complete, 4.6% of servers  
are renego patched and intolerant for the 4.1 version indication, and  
11.5% of all servers are intolerant for the 4.1 version.

I'll note that The Renego spec reiterated the version negotiation  
requirements, and only 0.17% of servers are renego patched and intolerant  
in the 1.0-1.2 inclusive range.

Maybe I am being pessimistic, but frankly I don't think using an extension  
will work for very long. If it doesn't break already when we deploy TLS   
1.3, I would be highly, but pleasantly surprised if we have less than 0.1%  
of server intolerant for TLS 1.4 when it gets deployed. In fact, I doubt  
it will be less than 3%.

BTW, 15.74% of servers are intolerant for the FALLBACK SCSV, 15.7%  at the  
front, 11.1% at the end. Admittedly, only 0.01% are intolerant for both  
3.4 and the SCSV, but if a 1.3 client have to rollback (e.g. due to a  
problem with an intermediate) and sends an SCSV, it is currently going to  
run into trouble with 1 out of every 9 servers. Keep in mind that direct  
intolerance is "just" 2.25%.

Additionally, 0.6% of the servers were extension intolerant in the TLS  
1.0-TLS 1.2 range, 65% of which are renego patched, and 2.7% of all  
servers are extension intolerant for TLS 1.3

> Non-ancient implementations are generally fine in this area, and I  
> (possibly naively) expect TLS 1.3 implementations to be notably better  
> in dealing with this sort of thing.

At this time, it is not the TLS 1.3 server implementations we have to be  
worried about, it is the currently deployed servers.

If one want to avoid such future interoperability concerns, the only way  
to avoid them is to create a exhaustive certification test suite that all  
implementations have to pass in order to call themselves TLS 1.3, 1.4, 1.5  
etc. server/client.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: [email-masked] (Martin Rex)
Date: Wed, 11 Mar 2015 19:46:03 +0100 (CET)

> the Internet running junk they haven't upgraded in a decade and a half.

Just FYI, all Servers that are running Microsoft Windows 2008R2, 2012& 2012R2
and have TLSv1.2 enabled, are de-facto version-intolerant to TLSv1.2
They will abort the connection when receiving an extension-less
ClientHello with ClientHello.client_version = (3,3), while the handshake
will succeed with ClientHello.client_version = (3,2) or when the
server has TLSv1.2 disabled (the latter is the default for Win7/2008R2).

>
> Non-ancient implementations are generally fine in this area

I'm not sure that everyone would agree to the determination
that Windows 8 & 8.1 are "ancient".

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Wed, 11 Mar 2015 14:56:37 -0400

On Wednesday, March 11, 2015 02:13:56 pm Stephen Checkoway wrote:
> Do you expect that there's a significant fraction of servers that (a) tolerate 1.2; (b) don't tolerate > 1.2; and (c) aren't maintained or can't be upgraded?

Yes.

> I'd be surprised by data showing this. I imagine that any server satisfying (b) and (c), probably doesn't satisfy (a) so this proposal doesn't help.

http://www.ietf.org/mail-archive/web/tls/current/msg15141.html
On Tuesday, January 20, 2015 11:01:31 pm Xiaoyin Liu wrote:
> For each site, I made at most four attempts with the following order to fallback:
> (TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS 1.0, TLS 1.0)
> where the first is TLS record layer version, and the second is Client Hello version.
>  
> Here is the result:
> (1) Number of sites scanned: 1,000,001
> (2) Number of DNS Error: 45,402
> (3) Number of sites that refuse TCP connection on port 443 (RST, timeout): 289,334
> (4) Number of sites that fail sending ServerHello in all 4 attempts: 238,846
> (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%)
> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)
> (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%)
> (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%)
> 
> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a lower record layer version does improve compatibility a lot. An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate certificates nor check the integrity of handshakes. I closed the connection immediately after receiving ServerHello.

Anecdotally, I am seeing TLS 1.3 intolerant servers that otherwise work popping up reports of servers breaking with the RC4 phase out.

An arbitrary and not scientific survey of the sites currently listed in the Mozilla RC4-Dependence meta-bug shows the following:

https://bugzilla.mozilla.org/show_bug.cgi?id=1138101
42 sites checked (popular enough to get reported there, at least)
of those, 5 have fixed their RC4 dependence; the others have not (as of this email)

5 are TLS 1.1-1.3 intolerant
1 is TLS 1.2-1.3 intolerant
8 are TLS 1.3 intolerant, but not 1.2 or less
3 are even tolerant to TLS 1.98 & 2.98 tests (the others are not)

(not bothering with percentages because the sample size is low and biased)

The rough things learned here are:
1) TLS 1.3 intolerance is more common than TLS 1.2 intolerance
2) TLS 1.2 intolerance without TLS 1.1 intolerance is actually a thing that happens
3) It is seemingly rare for any server to fully implement version negotiation properly
    (the domain that runs the test I use is even intolerant to TLS 2.98)
4) It appears that TLS 1.3 intolerance is more common with servers that have other problems that should've been fixed by now, but aren't

Again, this is anecdotal. I don't claim this is fully extrapolatable to the entire Internet, just that I'm seeing enough of it to be concerned.

I argue that TLS should never formally change its ClientHello version to anything greater than 1.x, though a spec name with yet another hacky numbering that doesn't match the official version number would be fine. (e.g. Call it TLS2 but number it {3,4} still)

I also argue that TLS 1.3 intolerance is something that must be addressed fully BEFORE attempting to get draft implementations out there and encouraging insecure fallback to deal with it.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 11 Mar 2015 14:57:49 -0400

> implementations have to pass in order to call themselves TLS 1.3, 1.4, 1.5  

YES

---

From: Stephen Checkoway <[email-masked]>
Date: Thu, 12 Mar 2015 01:01:27 -0400

On Mar 11, 2015, at 2:56 PM, Dave Garrett <[email-masked]> wrote:

>> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%.

Most of this is about the record layer version (which really seems silly to change given that the record layer isn't changing).

The real data here is that 1.5% of servers are intolerant of 1.3 but tolerate 1.2. So that was (a) and (b) in my list but it's pretty hard to measure (c): servers that aren't maintained or can't be upgraded.

I remain unconvinced, but others can weigh in.

-- 
Stephen Checkoway

---

From: Dave Garrett <[email-masked]>
Date: Thu, 12 Mar 2015 03:26:38 -0400

On Thursday, March 12, 2015 01:01:27 am Stephen Checkoway wrote:
> Most of this is about the record layer version

I just wanted to post the full data set here so it wasn't out of context.

> I remain unconvinced, but others can weigh in.

Let me put it to you this way: ~0.1% of servers are TLS 1.2 intolerant and browser vendors are STILL having trouble dropping insecure fallback, if they are attempting it at all. The TLS 1.3 intolerance problem is over an order of magnitude worse.

To be precise, most of these servers are likely considered maintained and can technically be upgraded, but that doesn't mean they actually will. Starting out with this untamed mess could discourage TLS 1.3 adoption and will encourage browsers to do insecure fallback for TLS 1.3.

For a marginally less hacky route, we could basically just make a better version of SCSV and mandate its use in the TLS 1.3 spec. Simply have a max supported version extension which has nothing other than the max client TLS version in it, include it in every ClientHello, and use the normal version negotiation. If a 1.3 ClientHello fails, an insecure fallback to 1.2 can be done, however a 1.3 server can doublecheck versions and know the first attempt merely failed and 1.3 can actually be negotiated instead. The client would get a 1.3 ServerHello and could continue the connection normally, but note an error somewhere. (whatever dubious security UI indicator the browser uses) This is essentially the existing system with an extension as a backup method, but it enshrines downgraded fallbacks as valid. (we might be ok with that if this is done properly) It does have the benefit of shining a spotlight on broken implementations, though.

Dave

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 12 Mar 2015 00:28:45 -0700

> To be precise, most of these servers are likely considered maintained and can technically be upgraded, but that doesn't mean they actually will. Starting out with this untamed mess could discourage…
Personally, I'd be actually fine with insecure fallback with a deadline (of maybe a year) to drop it.

Yuhong Bao

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 12 Mar 2015 01:25:32 -0700

> server has TLSv1.2 disabled (the latter is the default for Win7/2008R2).

As a side note, does the March updates includes any fixes to SChannel other than FREAK and the Cisco OneConnect bug?

Yuhong Bao

---

From: Hubert Kario <[email-masked]>
Date: Thu, 12 Mar 2015 11:44:57 +0100

> implementations have to pass in order to call themselves TLS 1.3, 1.4, 1.5

I'd say it's surprising that there isn't something like that yet.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 12 Mar 2015 16:58:35 -0700

> Let me put it to you this way: ~0.1% of servers are TLS 1.2 intolerant and browser vendors are STILL having trouble dropping insecure fallback, if they are attempting it at all.
Many of them seems to be caused by older versions of the Certicom TLS stack used in older versions of Oracle Application Server for example.
It seems that renego patched versions will tolerate TLS 1.2 if TLS 1.0 is used in the record layer:
https://www.ssllabs.com/ssltest/analyze.html?d=windecare.wind.it
https://www.ssllabs.com/ssltest/analyze.html?d=service.oneaccount.com
(Notice that IE/Java fails but Firefox/Chrome works)

Yuhong Bao