I'm not fixated on any particular argument, but the preceding comment offers network security advice as if it were best common practice, and it is not in fact that. That's all! Not a big thing.
I would be interested in your take; if you had to distrust the network, how would you protect HTTP, SMTP, DNS, and TLS certs? I suspect your answer isn't DNSSEC, but I'd be interested to hear what you would use instead. The European answer seems to be DNSSEC, considering adoption rates there. (edit: should be "includes" not "be", it's one of the tools they use).
We do have to distrust the network, which is partly why TLS cert validation now includes a bunch of mitigations around validation from multiple network positions, certificate transparency logs, etc.
DNSSEC adoption on major European properties is also quite low! Try a bunch of domains out (`host -t ds <domain>`). There are more in Europe, of course, but not very many, at least not major ones. My hypothesis, I think strongly supported: the more mature your security team, the more internal pushback against DNSSEC.
I'm not fixated on any particular argument, but the preceding comment offers network security advice as if it were best common practice, and it is not in fact that. That's all! Not a big thing.
I would be interested in your take; if you had to distrust the network, how would you protect HTTP, SMTP, DNS, and TLS certs? I suspect your answer isn't DNSSEC, but I'd be interested to hear what you would use instead. The European answer seems to be DNSSEC, considering adoption rates there. (edit: should be "includes" not "be", it's one of the tools they use).
We do have to distrust the network, which is partly why TLS cert validation now includes a bunch of mitigations around validation from multiple network positions, certificate transparency logs, etc.
DNSSEC adoption on major European properties is also quite low! Try a bunch of domains out (`host -t ds <domain>`). There are more in Europe, of course, but not very many, at least not major ones. My hypothesis, I think strongly supported: the more mature your security team, the more internal pushback against DNSSEC.
2 replies →