Side note: removing support for DHE because some folks are using 1024 bit dhparam is like removing support for RSA signatures, because some folks are using 1024 bit RSA signing keys. Insecure algorithms and insufficient key sizes are two separate issues. And DHE with proper dhparam (2048 and bigger) is still secure, so far as I know.

1) We do not have plans to support P-521
2) We do not have plans to support DHE, because it cannot be supported safely at a strong level.
3) We do not have plans to have Chrome clients cause additional load to servers by probing their configuration.

DHE in TLS has serious negotiation problems that make it impractical to deploy securely. It is impractical for the client to require DHE groups larger than 1024-bit and it is impractical for the server to deploy DHE groups larger than that too.

See https://groups.google.com/a/chromium.org/d/msg/security-dev/AAdv838-koo/1Z0LfNgXCwAJ which expands on this in more detail.

Note that Chrome supports X25519 which is a very nice and modern curve. We also support P-256 which is pretty common and has fast implementations in OpenSSL and probably other widely-used libraries.

Ryan:
I understand your plans. I understand you want (or need) to reject strong crypto like ECDHE w/ P-521 or DHE w/ 4096 bit dhparam (they're not on the NSA Suite B list), too. But calling is obsolete is wrong. Unless you can show any paper describing successful attacks against them - and then all the other browsers and crypto libraries could agree it's reasonable and would follow your decisions.

David:
I've noticed added support for X25519 - which is great. But OpenSSL 1.1.0 is still in RC stage, and it will take some time until it lands as stable on the server side. So what we really have now, is PFS key exchange limited to ECDHE w/ P-256 and P-384 - which are good for NSA and folks on their payroll (secret attacks mentioned by DJB in https://safecurves.cr.yp.to/rigid.html would nicely fit NOBUS rule), but not necessarily for the rest of the world (at least those caring a bit about their privacy).

OpenSSL since May 2015 (Logjam) generates 2048-bit dhparam by default, and it's perfectly practical to use it. If it was my call I'd be simply rejecting dhparam under 2048 bit on the client side, with ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY message. It's as good as rejecting dhparam smaller than 768 bit, which was commonly used approach in the past.

I just hope that when TLSv1.3 is finished (w/ DHE groups negotiation improved) BoringSSL and Chrome will support both ECDHE w/ X25519 and X448, and DHE w/ ffdhe2048+, so both ECC lovers and haters could sleep well.

Please refrain from throwing out random implications about the motivations of various changes. It's getting rather tiring.

P-521 is no more rigid than P-256 or P-384. It's simply not listed in djb's page, so he doesn't say anything about it either way. Note that E-521 is, of course, not the same as P-521.

Setting a minimum dhparam at 2048-bit is a non-starter. Again, please read the linked thread which spells out the issues quite clearly. The only way to get to 2048-bit is to scrap it completely (what we are doing) and start over a new set of ciphers with negotiated groups.

That, in turn, is a waste of time something better is already widely deployed. Ciphers are not like Pokemon. The goal is not to catch them all. Maintaining each one takes continuous work and overhead. Security is better-served by having only a few good ones that we can put the time into making fast and solid.

For the same reason, there are no plans to implement FFDHE as part of TLS 1.3. X25519 is, of course, supported today, and that won't change when we get to TLS 1.3.

David: 
I've read the linked thread. My thoughts:
1. Secure DHE group negotiation for TLSv1.0 and newer is possible using RFC 7919.
2. Software that supports PFS only via DHE exists - look at MySQL CE (yaSSL) or pure-ftpd prior to 1.0.38. Irrelevant to the browsers world, but it happens here and there.
3. Some cryptography experts (like DJB or Bruce Schneier) indicated weaknesses of NIST curves. Results of P-256 and P-384 analysis were published. That's why some people might want to stay away from ECC until more secure curves (like X25519 and X448) are widely adopted.
4. Only way to have PFS without using uncertain ECC is to use DHE (w/ 2048+ bit dhparam).

To sum it up:
1. Supporting small set of future-proofed key exchange parameters present in TLSv1.3 draft (section A.3.1.3, https://tools.ietf.org/html/draft-ietf-tls-tls13-15#appendix-A.3.1.3) sounds pretty reasonable to me, nowhere near catch-em-all style.
2. Supporting PFS-compatible ECC-free cipher suite also looks like a good idea, in case of discovering ECC-related attacks in future (to avoid cryptographic single point of failure).
3. Mentioned key exchange parameters (ECDHE w/ P-521, DHE w/ 2048+ bit dhparam):
  1) have no known weakness,
  2) are supported in major TLS libraries (OpenSSL, GnuTLS, NSS),
  3) were supported in Chrome in the past,
  4) result in ERR_SSL_OBSOLETE_CIPHER in Chrome 53.

I don't ask you to change your plans, as you probably won't. I am just saying you might have wrong error message that could be corrected. Throwing ERR_SSL_OBSOLETE_CIPHER when you meet key exchange parameters that are considered good enough for upcoming TLSv1.3 doesn't make much sense.

The messaging is inherent because of how TLS ciphersuite negotiation works, and my comment #3, Item 3, explains why we have no plans to change that messaging.

Calling it "mismatched cipher" or "no cipher overlap" (as it was in the past) doesn't reflect what the majority of our users see and encounter, and thus we chose to be inaccurate for the small percentage of users who have configured things overly-aggressively, in the face of the majority of servers that have misconfigured for legacy.

Also, your claim in Comment #7, #3 (that "ECDHE w/ P-521 has no known weaknesses") is incorrect, if you accept that P-256 and P-384 have also been shown to have weaknesses (please re-read comment #6 - it was omitted for brevity from the list of [non] safecurves, not because of inherent security)

It's also worth noting that, while you're right that RFC 7919 fixes the negotiation problems, it doesn't help your criteria. No server today implements RFC 7919. (RFC 7919 is also undeployable as a client because they use the same cipher numbers as legacy server-fiat DHE. This was brought up a couple times at the TLSWG but, sadly, never acted upon.)

Meanwhile, X25519, is already deployed in Chrome. I believe Mozilla have a bug open to add it to Firefox. OpenSSL 1.1.0, just released today supports it. I believe Microsoft are also expecting to support it. We'll get to X25519 before we get to RFC 7919.

Ryan: I consider P-521 as a bit safer than P-256 and P-384, because it is allowed to protect TOP SECRET data in the US - so even if it had cryptographic backdoor (BULLRUN program is a fact), then access to it would have to be strictly limited, even at the NSA.

Anyway - with the release of OpenSSL 1.1.0 mentioned by David trustworthy ECC becomes widely available, and my main concern about ECDHE is gone - we can start thinking about NIST curves as a legacy fallback (nginx 1.11+ allow to choose multiple curves via ssl_ecdh_curve, SChannel allows per-suite curve selection as well - so it's doable).

I still think it would be good to support securely negotiated ffdhe2048+ for TLSv1.3 (NSS already did that in 3.25) in case of attacks related to ECC-based algorithms appeared - but let it be new feature to be considered in future, not a bug report against existing DHE implementation.

Inaccurate ERR_SSL_OBSOLETE_CIPHER served by Chrome in case of strong dhparam still bugs me a bit, but let's call it lesser evil. As long as we have reasonable plans for the future, it's acceptable - just don't use the same message when you'll connect to TLSv1.3 servers using ffdhe2048+ groups.

There are no plans to implement FFDHE groups in TLS 1.3.

And, no, ERR_SSL_OBSOLETE_CIPHER is only triggered on the legacy server-fiat DHE ciphers that we outright had to remove. It's keyed on a throwaway probing fallback, like ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION was. The purpose is to have clearer error-reporting for a removal since otherwise we'll report a lot of ambiguous ERR_CONNECTION_CLOSEDs, etc.

A TLS 1.3 server which does not implement any of our chosen curves will fail with whatever error the server provides. If well-behaved, we'll get back ERR_SSL_VERSION_OR_CIPHER_MISMATCH. If not, we might get back unhelpful things like ERR_CONNECTION_CLOSED.

(Configuring multiple curves has been possible since OpenSSL 1.0.2, probably earlier if you tried hard enough. It's an incredibly basic feature. That any software wouldn't let you do that is completely nuts.)