3 ms·
DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp
by belorn 3y ago
DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.
- tptacek 3y agoWho cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.
- hsbauauvhabzb 3y agoYou’re also relying on the client validating DNSSec. I have no idea if/how/when this occurs, or if you can choose to ignore it.
- wlonkly 3y agoA nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.
- belorn 3y agoIf the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack). If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server. If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.
- tptacek 3y agoNone of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.
- belorn 3y agoTLSA record can specify what specific hash the certificate must have (DANE-EE). You can't solve that with BGP and ACME. The certificate that you get from acme will have a different hash. With CAA records you can also lock it down to a specific user and method (RFC 8657). How will you solve that with BGP using acme?