3 ms·

I think it would be acceptable if it's automated at the DNS level. You need to have a trust hierarchy anyway to resolve a name, so you can piggyback the same tr

by yholio 5y ago

I think it would be acceptable if it's automated at the DNS level. You need to have a trust hierarchy anyway to resolve a name, so you can piggyback the same trust hierarchy to encrypt and secure all communications. In the fee paid for the domain name, the owner should get perpetual free secure DNS and certificates for any purpose and sub-domain. The current issuance of (non-EV) certificates is an unsecure hack over DNS anyway[1], so why not merge certificate issuance at the protocol level? [1] https://en.wikipedia.org/wiki/Domain-validated_certificate https://en.wikipedia.org/wiki/Domain-validated_certificate

necovek 5y ago
I do agree in principle regarding trust level, and regarding pricing. But that can quickly become impractical. I run a bunch of small personal web sites (different domains) on a single IP, which a certificate is tied to (since HTTP "Host" negotiation only happens after the encrypted connection is established). I think there were changes to allow this negotiation to happen before encryption, but that loses some privacy. I also use a couple of registrars, so coming up with a solution to this existing complexity is extra hard. Maybe with IPv6 where I can cheaply use a bunch of fixed IPs instead.
- yholio 5y ago
  Yes, there is vhost negotiation happening in TLS before session is setup, and the webserver selects the apropriate certificate. The loss of privacy is minimal, since without this system you would be forced to use one IP per TLS host (or disable TLS), and DNS binding those IPs to websites are public. For the second concern, it can be in principle automated to the point where you only need to inform the webserver of its hostname(s). If the DNS A records are correctly configured, it's trivial for the DNS server to verify the IP address and sign the CRL generated by the webserver on the fly. Like a letsencrypt operated by your DNS provider that simply works.

by yholio 5y ago

necovek 5y ago

I do agree in principle regarding trust level, and regarding pricing. But that can quickly become impractical. I run a bunch of small personal web sites (different domains) on a single IP, which a certificate is tied to (since HTTP "Host" negotiation only happens after the encrypted connection is established). I think there were changes to allow this negotiation to happen before encryption, but that loses some privacy. I also use a couple of registrars, so coming up with a solution to this existing complexity is extra hard. Maybe with IPv6 where I can cheaply use a bunch of fixed IPs instead.

yholio 5y ago
Yes, there is vhost negotiation happening in TLS before session is setup, and the webserver selects the apropriate certificate. The loss of privacy is minimal, since without this system you would be forced to use one IP per TLS host (or disable TLS), and DNS binding those IPs to websites are public. For the second concern, it can be in principle automated to the point where you only need to inform the webserver of its hostname(s). If the DNS A records are correctly configured, it's trivial for the DNS server to verify the IP address and sign the CRL generated by the webserver on the fly. Like a letsencrypt operated by your DNS provider that simply works.