search

ircv3 / ircv3-specifications

IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
http://ircv3.net/
777 stars 79 forks source link

OOB distribution of cert fingerprints #210

Open attilamolnar opened 8 years ago

attilamolnar commented 8 years ago

One idea: as a network generate a CA, include the fingerprint of it in the irc:// link and sign the certs of all your servers certs with the CA.

Clients can possibly preload the fingerprint of a network's CA.

nomis commented 8 years ago

Any CA must have either very short certificate lifetimes or a revocation mechanism (CRL/OCSP) and you'd also need a way to change the network CA.

You don't need a network CA to meet this requirement, it's already supported by the DNS: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

_6697._tcp.irc.example.com. 60 IN TLSA 3 1 2 (
                                  316E3DDAD4AF309C8FA0479277E31FCAE7BC1819AA80
                                  16C3BA5CD7E6634297380281143301406ECA847251B8
                                  74E914BA800A6DBC98450920EFEA7BE6B12D21EF )

The only missing part is currently practical support in TLS libraries to allow clients to use it: https://github.com/weechat/weechat/pull/121

This can also be used by clients connecting to plaintext ports. If there are any TLSA records for port 6667 then it must require STARTTLS to continue.

dequis commented 8 years ago

Clients could always implement DANE/DNSSEC, that's nothing new and that's not what this ticket is about. Some people dislike the centralized model of the standard root CAs, and, without getting into details, the same kind of people argue that DANE isn't any better regarding centralization.

This is about pushing the fingerprints elsewhere, like the website of the irc network. That website might have a proper certificate signed by a standard root CA (it's slightly easier to set up for web servers), or it might use pgp or whatever else.