Re: [TLS] Thoughts on Version Intolerance

[Yuhong Bao <[e-mail]>]

I don't have access unfortunately, but I wonder which companies on this mailing list are using the affected APC devices.

________________________________
From: Peter Gutmann <[e-mail]>
Sent: Sunday, July 24, 2016 5:01:42 AM
To: Yuhong Bao
Subject: RE: [TLS] Thoughts on Version Intolerance

Do you have access to a device running that software, or are you just passing on the info?  I'd like to run some test messages against it...

Peter.

________________________________
From: TLS [[e-mail]] on behalf of Yuhong Bao [[e-mail]]
Sent: Saturday, 23 July 2016 19:16
To: David Benjamin; Benjamin Kaduk; Hanno Böck; [e-mail]
Subject: Re: [TLS] Thoughts on Version Intolerance


I should also mention the APC fiasco:

http://www.apc.com/us/en/faqs/FA238115/

UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) enabled device via HTTPS (SSL/TLS)<http://www.apc.com/us/en/faqs/FA238115/>
www.apc.com
UPDATED MARCH-2016: Unable to access my APC Network Management Card (NMC) enabled device via HTTPS (SSL/TLS)

I wonder if anyone has tested the TLS 1.2 implementation they did later not only for version intolerance but also for other bugs like GCM nonce reuse.

________________________________
From: TLS <[e-mail]> on behalf of David Benjamin <[e-mail]>
Sent: Thursday, July 21, 2016 3:19:34 AM
To: Benjamin Kaduk; Hanno Böck; [e-mail]
Subject: Re: [TLS] Thoughts on Version Intolerance

On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk <[e-mail]<mailto:[e-mail]>> wrote:
On 07/20/2016 05:01 AM, Hanno Böck wrote:
> On Wed, 20 Jul 2016 11:20:46 +0200
> Hubert Kario <[e-mail]<mailto:[e-mail]>> wrote:
>
>> so it looks to me like while we may gain a bit of compatibility by
>> using extension based mechanism to indicate TLSv1.3,
> Just quick: This was discussed yesterday, David Benjamin had an
> interesting proposal, but it was largely met with resistance. So from

I had some follow-up discussion with David and a few others later in the
day.  One point that I think was not clear during the WG session was
whether the check for whether a server's version negotiation is
futureproof could be done in the hot path, so that it is impossible to
implement a server that works in a major browser and is (e.g., 1.4)
version-intolerant.

Right now, if a browser wants to probe for (e.g., 1.3) version
intolerance, it essentially has to treat it as a data-collection step,
either doing the fallback dance on failure or just doing the probe in
parallel with a 1.2 clienthello that is actually used for the
connection, since we know that 1.3-intolerance exists.  With David's
proposal (and potentially variants of the other ones), browsers could
implement a check that sends nonexistent versions in their clienthello,
so that once a server implements 1.3, it would not be 1.4-intolerant.

If we just keep with the current version negotiation scheme, we'll
always be stuck in the "data-collecting" mode and won't be able to
strictly enforce the future-proofing, since there are existing servers
that are intolerant to the current scheme, and the browsers will be
blamed for breaking sites on those servers if the browsers try to
introduce strict enforcement of version negotiation future-proofing.

[Credit where credit is due, I was not the first to propose the version list. I don't know who was first, but Dave Garrett had proposed the same thing. The TLS 1.3 implementors effectively did so too with the draft version extension. Though I think the fake versions idea is new?]

I should also add that, even if we ever got to our prerequisite quiet point, this scheme is still problematic. If we had a list, all clients could participate in this fuzzing and we have a shot at vaccinating the ecosystem. This one violates the specification, so only clients which can rapidly deploy changes can safely do it. (Some sort of field trial mechanism, for instance.) And it requires manual work to sustain: I would probably only do it for, say, 3 months at a time and manually extend so long as TLS 1.4 does not exist. I would not want to cause problems by forgetting to turn it off.

And as Hubert notes, there may well be other intolerance triggers to clear through. 1.3 has a larger ClientHello. We have also never added a new signature algorithm before. But I think that just means we have more rusted protocol joints fix rather than just the one.

Fortunately, most of our other joints admit this kind of fuzzing. It's just the versioning scheme (fixable with a list), and large ClientHellos. I don't have a good answer to the second one, but I would be very happy if it were our only problem. It's much easier to understand. The version one is surprisingly difficult. The conversations usually go like this:

"Hi, your server software appears to have a bug where you reject TLS 1.2 ClientHellos rather than implementing the version negotiation right."
"Okay, we will deploy TLS 1.2."
"No, please don't fix this with 1.2. That's a different problem."
"You don't want us to add 1.2?"
"No no no. Please do switch to 1.2. I mean... oh, nevermind. I'll just email you later for 1.3."

I am obviously exaggerating for humor, but it's a very common confusion and I think is part of why version intolerance keeps on existing.

If you implement the latest version of TLS but are intolerant to N+1, even if no clients did fallbacks, your bug will not be noticed and you'll thrive in the ecosystem. Then when we go to deploy N+1, we have problems. We want, as much as possible, turn tomorrow's interop failures into today's interop failures so the bugs are caught before software ships.

David

-Ben

> the WG discussion yesterday I had the impression that we will most
> likely stay with the existing clienthello version mechanism. While that
> will cause us more trouble, it's probably the cleaner option anyway. So
> we definitely should continue investigating version intolerance and
> tell people to fix their stuff.
>

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls