Closed Bug 1335069 Opened 4 years ago Closed 4 years ago
Go test Client Auth-SHA1-Fallback-ECDSA fails
Working on ECDSA key import, I noticed that ClientAuth-SHA1-Fallback-ECDSA fails. It expects us to fall back to ECDSA/SHA-1 when the server sends an empty `supported_signature_algorithms` field in the CertificateRequest message. That seems like an appropriate thing to do, the 1.2 spec seems a little ambiguous  about whether this field is required to be non-empty.  https://tools.ietf.org/html/rfc5246#section-7.4.4
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.30
Tim, this commit resulted in a regression report, see bug 1412829. Could you please comment in that bug? It's being argued that the fallback on an empty list is incorrect behavior, and rather the certificate request should fail. Thanks.
I'm not sure what you expect me to add to the discussion in bug 1412829. It's very clear that we shouldn't accept an empty list of sig_algs. Not clear is how exactly to handle that. I'm not going to reiterate what Ekr already said, he knows the spec best.
(In reply to Tim Taubert [:ttaubert] from comment #5) > I'm not sure what you expect me to add to the discussion in bug 1412829. > It's very clear that we shouldn't accept an empty list of sig_algs. Not > clear is how exactly to handle that. I'm not going to reiterate what Ekr > already said, he knows the spec best. Tim, I'd like to point you to bug 1412829 comment 3. EKR said: (In reply to Eric Rescorla (:ekr) from comment #3) > I agree with Hubert that this behavior is wrong: if the server provides an > empty list, the client should not supply something not on the list. I'm > actually surprised to see this because IIRC I noted this bug on a previous > CL, though I'm too lazy to go back and try to find it. > > I disagree with Hubert that the client needs to send decode_error. I think > it would also be acceptable to simply act as if no common algorithm exists. > The specification never says that every decoding failure needs to elicit an > alert. I conclude that the existing code is incorrect, and should be changed to NOT fall back to SHA-1. I understand EKR's recommendation as: If no common algorithms exists, you shouldn't do client authentication with SHA-1, you should not authenticate at all.
I've asked EKR in bug 1412829 to confirm my understanding. I suggest we continue the discussion in bug 1412829, I only commented here for reference purposes.
You need to log in before you can comment on or make changes to this bug.