-
Notifications
You must be signed in to change notification settings - Fork 637
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
DNS-Based Authentication of Named Entities (DANE) #816
Comments
What exactly do you think we should implement to enable DANE support? As far as I can tell you could use |
As far as I could tell, there's no way to hand arbitrary data to verify_server_cert. That means to verify DANE during the handshake, it would require using a separate instance of a ServerCertVerifier implementation for each connection, which AFAICT means having separate ClientConfigs which is not the goal of ClientConfig. Of course, I could do the verification after the handshake, but that seems a bit dangerous. I think what this boils down to is that the I can't think of a good design off the top of my head for that though :) Edit: Full disclosure: I'm working on a rust-based network backend for a thing where Zash is a main developer, so we'll probably be intermixing our participation here somewhat :). |
On current main, |
Thanks for the reply. It does not fit the That obviously only works as long as each ServeName variant on its own is strong enough to verify a server's identity, otherwise a verifier which is unable to handle a specific (but crucial hypothetic) ServerName variant could cause a security issue. Am I making sense here? |
I think you should come up with a |
Sounds reasonable. Presumably such a variant would consist of at least a list of TLSA records and an optional server name. |
I'm taking a run at implementing this. My game plan is:
struct TLSARecord {
cert_usage: CertUsage,
selector: Selector,
matching: Matching,
cert_data: Vec<u8>,
}
enum ServerName {
...
Dane {
dns_name: DnsName,
tlsa: Vec<TLSARecord>,
}
}
|
This seems mostly sane from a practical architecture perspective, though others might come along who have opinions about the security/desirability of it all. Some suggestions to make an eventual review go more smoothly:
(Maybe it would simplify things a little to just stuff the |
I'm not sure about this because the name is to be set in the SNI extension, but if there are multiple names that allows for the possibility of having varying names (which isn't really in the source data from DNS), and if that was really a thing, how should you reconcile which one is returned for SNI? My initial sense, before diving into the webpki part of this, is that it feels simpler to keep that separate. |
I guess I have some more fundamental questions about this -- do people actually use DANE to achieve a meaningful security goal, given it is predicated on DNSSEC a) actually working reliably, b) being deployed widely, c) domain registrars having an economic reason to be competent, and d) reaching a decent cryptographic security level as a whole. AIUI the answers to those are a) sometimes it does, b) nope, c) lol, d) 1024-bit RSA. |
For the trend as it applies to SMTP: https://list.sys4.de/hyperkitty/list/[email protected]/thread/CLLDBG3UYPRXZPG33BLDZ3NR3G2TNNM5/ has the latest batch of stats. There are currently 3.9 million domains that have correctly deployed DANE, and the trend is growing, especially in Europe: https://github.com/baknu/DANE-for-SMTP/wiki/5.-Government-and-registry-policy |
How about a more general extension point:
That can be used with a custom |
I'm open to that; rustls/webpki#174 feels necessary to facilitate that. I took a quick stab at pulling that branch into rustls but there are quite a few things that need to be reconciled with the other changes there before I can make progress on that. |
Support for RFC 6698 would be nice to have. It has some usage in email and XMPP.
This would require a way to validate certificates against some bytes retrieved securely from DNS (this retrieval would be out of scope). Usually those bytes are a hash of the certificate public key (
SubjectPublicKeyInfo
structure).The text was updated successfully, but these errors were encountered: