4 ms·

Such a system would require either centralized trust anchors, massive preload lists, or be trust-on-first-use. In other words, you're just reinventing variants

by pfg 10y ago

Such a system would require either centralized trust anchors, massive preload lists, or be trust-on-first-use. In other words, you're just reinventing variants (and combinations) of DANE or HPKP.

0x0 10y ago
At least we'd get rid of the silly and fragile "domain ownership verification", which is often email based and therefore dependent on DNS MX record security - or in the case of ACME/LetsEncrypt usually DNS A records for HTTP, which is a totally ridiculous exercise since the registrar already knows you are the owner of the domain.
- tptacek 10y ago
  Your suggestion doesn't get rid of any current problems, and adds the new problem that you're chained to one authority for your TLD. If Google comes to distrust the COM operators, what does it do? Switch to GOOGLE.ZA?
  - 0x0 10y ago
    There are many .COM registrars so I'm not sure what you're getting at. Obviously we are trusting the .COM TLD operators to have implemented appropriate ACLs in the .COM database so that registrars can't meddle with other registrars' domains. And if they haven't, well, we're back to square one: External CAs use DNS to verify domain ownership, which is silly and insecure; meanwhile the .COM zone knows who is the registrar for any given domain, and the registrars know who is the owner of a given domain. If we can't trust the .COM operators to manage their accredited registrars properly then YES we need to distrust all of .COM, because then anyone could get a cert for any .COM by way of a single shady registrar. This trust is already a prerequisite for today's CA system. I am simply suggesting putting additional limits in place so that instead of trusting the .com TLD ops AND the relevant registrar AND all of the CAs in the world, we merely need to trust the .com TLD ops and the relevant registrar. It is strictly a subset of today's trust circle. Edit to add: today we are paying and trusting CAs to verify domain ownership by way of insecure DNS lookups (and then email tokens or http challenges). This is absurd because domain ownership is already positively definitively proven in the registrars' customer databases and the TLD's registrar database Edit2 to add more: The entire SSL CA ecosystem security hinges on the single web form for modifying NS records for a given domain at a given registrar for a given TLD. If you have access to modify the NS records you have all you need to get a certificate. So: This particular web form is where we should put a button to download SSL certificates. And, we should engineer clients to verify that certificates are issued only from that particular source (registrar at a registry). And get rid of external CAs.

by pfg 10y ago

Such a system would require either centralized trust anchors, massive preload lists, or be trust-on-first-use. In other words, you're just reinventing variants (and combinations) of DANE or HPKP.

0x0 10y ago

At least we'd get rid of the silly and fragile "domain ownership verification", which is often email based and therefore dependent on DNS MX record security - or in the case of ACME/LetsEncrypt usually DNS A records for HTTP, which is a totally ridiculous exercise since the registrar already knows you are the owner of the domain.

tptacek 10y ago
Your suggestion doesn't get rid of any current problems, and adds the new problem that you're chained to one authority for your TLD. If Google comes to distrust the COM operators, what does it do? Switch to GOOGLE.ZA?
- 0x0 10y ago
  There are many .COM registrars so I'm not sure what you're getting at. Obviously we are trusting the .COM TLD operators to have implemented appropriate ACLs in the .COM database so that registrars can't meddle with other registrars' domains. And if they haven't, well, we're back to square one: External CAs use DNS to verify domain ownership, which is silly and insecure; meanwhile the .COM zone knows who is the registrar for any given domain, and the registrars know who is the owner of a given domain. If we can't trust the .COM operators to manage their accredited registrars properly then YES we need to distrust all of .COM, because then anyone could get a cert for any .COM by way of a single shady registrar. This trust is already a prerequisite for today's CA system. I am simply suggesting putting additional limits in place so that instead of trusting the .com TLD ops AND the relevant registrar AND all of the CAs in the world, we merely need to trust the .com TLD ops and the relevant registrar. It is strictly a subset of today's trust circle. Edit to add: today we are paying and trusting CAs to verify domain ownership by way of insecure DNS lookups (and then email tokens or http challenges). This is absurd because domain ownership is already positively definitively proven in the registrars' customer databases and the TLD's registrar database Edit2 to add more: The entire SSL CA ecosystem security hinges on the single web form for modifying NS records for a given domain at a given registrar for a given TLD. If you have access to modify the NS records you have all you need to get a certificate. So: This particular web form is where we should put a button to download SSL certificates. And, we should engineer clients to verify that certificates are issued only from that particular source (registrar at a registry). And get rid of external CAs.