The change is simple, but I figured a phab discussion might be warranted, or might make a good reference link later.

Basic Info

AES256 options comprise roughly half of our server-side ciphersuite list in: https://github.com/wikimedia/operations-puppet/blob/production/modules/wmflib/lib/puppet/parser/functions/ssl_ciphersuite.rb .

For all other dimensions (e.g. Kx, Auth, Mac), we always offer an AES128 equivalent for every AES256 option, and we always prefer the AES128 variant. Therefore AES128 is always selected by clients unless they've explicitly disabled all AES128 options, which is not the default for any known client implementation - it's something the user/administrator would have to force/customize. Stats for the past week show that AES256-forcing clients comprise approximately 0.0013% of all requests. I've actually watched realtime logs to try to pin down exactly what's generating these requests. I've only ever caught two distinct users of AES256, and their traffic rates seem to comprise the overwhelming majority of all AES256 hits we get:

1. afnoc.af.mil outbound proxies - These are all IPs of the form 138.3.x.x, with hostnames of the form SITE-pxyw[0-9]e.afnoc.af.mil, where SITE is one of several known names of US Air Force bases. This traffic only seems to happen on our upload (as opposed to text or mobile) clusters, and always choses a cipher of AES256-SHA256. I can't find any real whois information that would be specific enough to reach out to whoever runs these, I don't see a public whois server for subdomains of .mil. This traffic is on the order of ~0.5 reqs/sec in global daily averages. The traffic from here is fairly benign and looks like normal, expected patterns for an outbound proxy for general usage, other than the fact that it's only hitting the upload cluster and not text. Could be a case of re-using upload.wm.o commons images on an internal .mil wiki that causes these hits. They may have filtered out AES-128 choices due to some blanket application of some military "256-bit only because it's bigger" sort of rule that comes out of some NIST/DOD standard. They'll be affected by the change.
2. Some guy in France - 90.54.216.xx / xx.abo.wanadoo.fr - Seems to be using IE11 with all 128-bit options manually disabled, choosing ECDHE-ECDSA-AES256-GCM-SHA384 with us. This guy (and others like him I think) is most of the rest of AES256 traffic, at a somewhat lower average rate than afnoc.af.mil, and more-bursty. He wouldn't be affected by the change, as he's using an PFS+AEAD+AES256 choice. There are probably others like this guy on different days and time-windows, but average rates indicate there are very few of them (enough that they don't overlap much).

Why do we care?

Cutting out a large chunk of our active cipher list simplifies it for analysis and further updates since we're preferring AES-128 on the balance of perf/security anyways and no clients should be selecting these options by default.

Also, generally speaking the choice of AES256 over AES128 is probably more misguided than informed in most cases. This Crypto.StackExchange discussion covers a lot of the debate, especially if you read more than just the top response, and the various links within the responses. The net of it in my mind is this: AES-128 is more than secure enough into the foreseeable future in brute force terms, and is better-studied in cryptanalytic terms and has held up fairly well so far. AES-256 has some suspicions around its key schedule in general, and there is a known related-key attack already which, counter-intuitively, makes AES-256 slightly weaker than AES-128 (that specific attack may not apply to common TLS use-cases, though!).

It seems silly that someone would go through the trouble of disabling AES-128 and not go through the trouble of upgrading the software to support PFS+AEAD, which is far, far, more important than the AES key length regardless of your stance on the 128-vs-256 debate. Therefore, the proposal here is that we drop all AES256 options which are in the mid and compat lists, but leave it as a less-preferred option in the strong list of PFS+AEAD options for clients that feel AES256 is stronger, and are being smart about other ciphersuite options, and want to make that manual choice.