3 ms·

3. CT doesn't work if domain owners don't watch it.

tialaramex 5y ago
Nah. That's probably relevant for what Thomas imagines doing, but in reality what CT does is provide independent researchers with an easy way to see anomalies. I've done this a few times, academics have done it here and there, and when there are incidents everybody involved will be staring at crt.sh these days. There was a recent m.d.s.policy policy change idea about requiring CAs to publish the SHA256s of problem certificates, perhaps as crt.sh links because again, in practice people are going to look at them on crt.sh (but SHA256 because one day crt.sh will go away and it'd be a shame to have opaque database row numbers instead of SHA256) For example, suppose I find a certificate with a 1024-bit RSA public key issued last Thursday by a particular CA. Before CT if I told m.d.s.policy, you can be 100% sure the CA would say "Oops. But that's the only one, we know what happened and we've definitely fixed it". But with CT, they won't even bother with that lie, because they know a researcher is already running a crt.sh database query to find the others they probably issued. They're going to need to actually find and fix the problem. Ugh. Work. This was a much bigger problem for the Web PKI than it is for DNS today, which is why CT was built. Why? Because of "private" systems. For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers (but when pointed out this actually makes HN readers angry!) so we don't fret about it. But for the Web PKI "private" systems are a big problem. We don't want a CA selling you a certificate for *.ad-network.example so that you can block their ads "just on your private network". Because we don't trust that it'll stay on your network. Years ago we had a problem where some end users believed "int" was a TLD for internal use, and much worse some CAs believed them. It isn't so of course the certificates for testwww4.int and windows2000dev.int are a big problem even though the people who had them never intended to set up a server claiming to be "testwww4.int" on the public Internet
- ignoramous 5y ago
  > For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers, so we don't fret about it. Just yesterday, I got banned by gatekeepers at privacyguides.org for pointing out the disconnect between their "must support DNSSEC" stance and the content-blocking scenarios made possible by services like Pi-Hole. I wish I was as eloquent and convincing as you are. [0] https://github.com/privacyguides/privacyguides.org/discussions/197#discussioncomment-1706112 https://github.com/privacyguides/privacyguides.org/discussio...
  - tptacek 5y ago
    To be clear, I don't think Nick Lamb is an opponent of DNSSEC.
    - tialaramex 5y ago
      Indeed. I did change my mind, but I changed my mind to being much less sceptical of the Web PKI partly as a result of the changes Ryan talked about on Thomas' podcast and partly after taking more active part in m.d.s.policy and seeing that it was possible to make a difference. I remain of the opinion (as do many other people who can't just wish away the problem) that we need DNSSEC, or at least, that we need to do what DNSSEC does and we have DNSSEC so we should just use that. Thomas disagrees fervently, as you have seen.
      - tptacek 5y ago
        I think you're wrong about that even in the general sense --- that I don't believe we even need what DNSSEC is trying to accomplish, even if we had a sane design to do it. And I strenuously disagree that the DNSSEC design we have today --- DNSSEC-ter? DNSSEC-quater? --- has a positive risk/benefit. I think we will all be worse off in the unlikely event that it's adopted; we'll be worse off even in the best case of universal adoption where nothing goes wrong except that we're all locked into RSA and ECDSA P-Curve signatures, and I think there are much worse things that are likely to happen. But I'll do my best to disagree more respectfully! I missed the mark badly downthread, and I'm sorry for that.

Nah. That's probably relevant for what Thomas imagines doing, but in reality what CT does is provide independent researchers with an easy way to see anomalies. I've done this a few times, academics have done it here and there, and when there are incidents everybody involved will be staring at crt.sh these days. There was a recent m.d.s.policy policy change idea about requiring CAs to publish the SHA256s of problem certificates, perhaps as crt.sh links because again, in practice people are going to look at them on crt.sh (but SHA256 because one day crt.sh will go away and it'd be a shame to have opaque database row numbers instead of SHA256) For example, suppose I find a certificate with a 1024-bit RSA public key issued last Thursday by a particular CA. Before CT if I told m.d.s.policy, you can be 100% sure the CA would say "Oops. But that's the only one, we know what happened and we've definitely fixed it". But with CT, they won't even bother with that lie, because they know a researcher is already running a crt.sh database query to find the others they probably issued. They're going to need to actually find and fix the problem. Ugh. Work. This was a much bigger problem for the Web PKI than it is for DNS today, which is why CT was built. Why? Because of "private" systems. For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers (but when pointed out this actually makes HN readers angry!) so we don't fret about it. But for the Web PKI "private" systems are a big problem. We don't want a CA selling you a certificate for *.ad-network.example so that you can block their ads "just on your private network". Because we don't trust that it'll stay on your network. Years ago we had a problem where some end users believed "int" was a TLD for internal use, and much worse some CAs believed them. It isn't so of course the certificates for testwww4.int and windows2000dev.int are a big problem even though the people who had them never intended to set up a server claiming to be "testwww4.int" on the public Internet

ignoramous 5y ago
> For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers, so we don't fret about it. Just yesterday, I got banned by gatekeepers at privacyguides.org for pointing out the disconnect between their "must support DNSSEC" stance and the content-blocking scenarios made possible by services like Pi-Hole. I wish I was as eloquent and convincing as you are. [0] https://github.com/privacyguides/privacyguides.org/discussions/197#discussioncomment-1706112 https://github.com/privacyguides/privacyguides.org/discussio...
- tptacek 5y ago
  To be clear, I don't think Nick Lamb is an opponent of DNSSEC.
  - tialaramex 5y ago
    Indeed. I did change my mind, but I changed my mind to being much less sceptical of the Web PKI partly as a result of the changes Ryan talked about on Thomas' podcast and partly after taking more active part in m.d.s.policy and seeing that it was possible to make a difference. I remain of the opinion (as do many other people who can't just wish away the problem) that we need DNSSEC, or at least, that we need to do what DNSSEC does and we have DNSSEC so we should just use that. Thomas disagrees fervently, as you have seen.
    - tptacek 5y ago
      I think you're wrong about that even in the general sense --- that I don't believe we even need what DNSSEC is trying to accomplish, even if we had a sane design to do it. And I strenuously disagree that the DNSSEC design we have today --- DNSSEC-ter? DNSSEC-quater? --- has a positive risk/benefit. I think we will all be worse off in the unlikely event that it's adopted; we'll be worse off even in the best case of universal adoption where nothing goes wrong except that we're all locked into RSA and ECDSA P-Curve signatures, and I think there are much worse things that are likely to happen. But I'll do my best to disagree more respectfully! I missed the mark badly downthread, and I'm sorry for that.