I have compatibility concerns about this. Just looking at certificates in the certificate transparency log, many signatures use sha-512 (and unfortunately we don't have telemetry data like we do with p521). I understand that the p521 implementation was potentially problematic, but are there similar concerns with sha-512? In other words, what's the win here?

(In reply to David Keeler [:keeler] (use needinfo?) from comment #2)
> I have compatibility concerns about this. Just looking at certificates in
> the certificate transparency log, many signatures use sha-512 (and
> unfortunately we don't have telemetry data like we do with p521). I
> understand that the p521 implementation was potentially problematic, but are
> there similar concerns with sha-512? In other words, what's the win here?
1. I explained some of the reasoning in bug 1130580. Basically, it doesn't make sense to use a SHA-512 and P-384 together, nor does it make sense to use SHA-384 or SHA-512 and P-256 together, and I'd like to avoid any potential (unknown) problems caused by that nonsense. This only applies to ECDSA though, not RSA.
2. Like I mentioned above, Firefox's TLS handshake doesn't advertise support for SHA-512 signatures, only SHA-384, SHA-256, and SHA-1 signatures. MSIE and Chrome do the same. I'd like to make the values in TLS supported curves extension match what is actually supported, if reasonable.
3. Note that in bug 610162, in November *2010*, I fixed a bug in NSS where NSS was calculating SHA-512 (and SHA-384) digests incorrectly. That's some evidence that the "limitation of attach surface" argument applies here, too, though it's not a very strong argument since SHA-384 uses the same code.
An alternative course of action would be, for example, to stop supporting SHA-512 signatures for ECDSA and to change Gecko's TLS handshake to advertise support for RSA-SHA512. Other courses of action are also possible.
In the data you looked at, how many of the SHA-512 signatures were ECDSA and how many were RSA? And, how many is "many"?

I found around 2800 certificates signed with SHA512WithRSA, but when filtering on certificates that are likely to validate correctly with Mozilla's roots, the number dropped to 12. I found 0 certificates signed with ECDSAWithSHA512. I found 11 certificates signed with ECDSAWithSHA384 that are likely to validate correctly with Mozilla's roots. As an aside, I found 14 certificates that appeared to have P-521 keys that are likely to validate under Mozilla's roots.
(These numbers aren't exactly definitive - certificate transparency is unfortunately a small subset of what's actually in the ecosystem.)

David, did you build a web interface for searching the CT data? If so, can I get access to it?
And/or, can you attach the list of SHA-512-using certificates (or just the domain names) from the CT database to this bug? It would be useful for me to understand this issue.
Thanks!

Unfortunately there's not a generic web interface for the CT data yet. It is something I've been thinking about, though.
Here's the list of common names (looks like there are two duplicates):
*.clintwilson.technology
*.clintwilson.technology
ajax.deskapi.com
*.assistly.com
*.desk.com
homsar.uvt.nl
www.thinklamar.com
chart.myunitypoint.org
carelink.unitypoint.org
*.wilsonovi.com
*.wilsonovi.com
sunapsis.byuh.edu
I found live SHA-512 certs at all of them except the first. They appear to be issued by DigiCert, so maybe we could reach out to them.

I would ask that not only should SHA512 support not be removed since it is part of the spec and as there are those who use it for (large) internal CA structures, but that Firefox be updated for interoperability purposes. I've been having an ongoing dialog with Microsoft SCHannel developers as to why Microsoft IIS + Firefox 38 trips over the TLS downgrade block when using a certificate chain with SHA512 structures. What appears to be the case is that Microsoft is very strictly interpreting RFC5246 7.4.2 and refusing to use a compatible signature for its cipher selection if the certificates are using SHA512withRSA. Firefox, in its ClientHello message, is not explicitly listing SHA512 in the signature_algorithms section of the request. IIS is then acting as if it cannot properly negotiate a cipher switch and sends back an RST to force another negotiation attempt. This is causing the client to downgrade to TLS 1.1 or TLS 1.0 (I've seen both and haven't figured out what conditions cause which) upon which the same cipher that should have been chosen/negotiated in the TLS 1.2 is being selected. Microsoft claims this is due to signature_algorithms not advertising explicit support for SHA512/{RSA,ECDSA,DCA}. Contrast this behavior with Apache which will choose the use of SHA256 even in the presence of a SHA512 certificate.
If this isn't the right bug to request proper announcement of the signature_algorithms supported in the ClientHello packet, please let me know and I'll file a different bugzilla request.

Oh, I forgot to mention that IE does in fact advertise SHA512 for both RSA and ECDSA in the signature_algorithms section of the ClientHello, at least in IE11. It was mentioned above that IE was omitting it.

(In reply to jasonmc from comment #11)
> I would ask that not only should SHA512 support not be removed since it is
> part of the spec and as there are those who use it for (large) internal CA
> structures, but that Firefox be updated for interoperability purposes. I've
> been having an ongoing dialog with Microsoft SCHannel developers as to why
> Microsoft IIS + Firefox 38 trips over the TLS downgrade block when using a
> certificate chain with SHA512 structures. What appears to be the case is
> that Microsoft is very strictly interpreting RFC5246 7.4.2 and refusing to
> use a compatible signature for its cipher selection if the certificates are
> using SHA512withRSA. Firefox, in its ClientHello message, is not explicitly
> listing SHA512 in the signature_algorithms section of the request. IIS is
> then acting as if it cannot properly negotiate a cipher switch and sends
> back an RST to force another negotiation attempt. This is causing the client
> to downgrade to TLS 1.1 or TLS 1.0 (I've seen both and haven't figured out
> what conditions cause which) upon which the same cipher that should have
> been chosen/negotiated in the TLS 1.2 is being selected. Microsoft claims
> this is due to signature_algorithms not advertising explicit support for
> SHA512/{RSA,ECDSA,DCA}. Contrast this behavior with Apache which will choose
> the use of SHA256 even in the presence of a SHA512 certificate.
>
> If this isn't the right bug to request proper announcement of the
> signature_algorithms supported in the ClientHello packet, please let me know
> and I'll file a different bugzilla request.
FWIW, this is fixed on Firefox 39 and above - see Bug 1155932 comment 4.

(In reply to Cykesiopka from comment #13)
> (In reply to jasonmc from comment #11)
> FWIW, this is fixed on Firefox 39 and above - see Bug 1155932 comment 4.
This is great news, thanks. Solves a major headache we've been having as well as other people. I think this is one of the problems that InCommon had with their SHA-512 intermediate so hopefully some of these interop issues are being put to bed as people seek to use strong certificates with TLS 1.2.