Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the rationale for allowing handshake failure when no anchors match? #63

Open
bwesterb opened this issue Jul 29, 2024 · 3 comments

Comments

@bwesterb
Copy link

If no certification paths satisfy either extension, the subscriber MAY return a handshake_failure alert

An alternative would be to mandate that the subscriber always needs to respond with some certificate and its trust anchors as described in §4.3. What is the advantage of the former? There is a clear disadvantage: a client might actually support a trust anchor that the subscriber has available, but it might not have sent it, due to size or privacy constraints.

@davidben
Copy link
Collaborator

Sending something requires an explicit choice of fallback certificate somewhere, and the server might not have configured one. The intention was that, whether you send a handshake_failure or a certificate, the EncryptedExtensions message still comes in and triggers the retry.

(This will be moot if we do #53)

@bwesterb
Copy link
Author

The intention was that, whether you send a handshake_failure or a certificate, the EncryptedExtensions message still comes in and triggers the retry.

That intention would work. I don't see that in the text now, and I could imagine an implementor just failing early with handshake_failure without sending EncryptedExtensions.

Sending something requires an explicit choice of fallback certificate somewhere, and the server might not have configured one.

When would this happen? That means the server also doesn't know what to send if the client doesn't send any trust anchors.

@davidben
Copy link
Collaborator

That intention would work. I don't see that in the text now, and I could imagine an implementor just failing early with handshake_failure without sending EncryptedExtensions.

Hmm. I went to write this down, but it's actually kinda tricky. In fact the natural way to implement this in BoringSSL would actually fail to send EncryptedExtensions because we don't proceed with the handshake until we know which credential we're acting as.

This may require some more thought. Or perhaps we end up with #53 and it doesn't matter. Or maybe we just say you really gotta pick a fallback credential. (Provided you have some credential that satisfies sigalgs and other rules. If you don't, a fatal error without retry is fine because no trust anchors would have worked anyway.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants