4 ms·

I’m assuming that if you’re stripping the responses of RRSIGs you’d also deny requests for DNSKEY and DS records, returning no data and no error.

teddyh 7y ago
The resolver has, hard coded, the root zone keys. If the resolver is denied the NS records from the root zone, a resolution is not possible. If the NS records are returned, they are signed and include the lower signature keys. If the NS records are stripped of keys, the signature of those responses is invalid. People have put some thought into the design of DNSSEC, you can’t simply invisibly block it and force a protocol downgrade.
- bluejekyll 7y ago
  I’ll have to consider this in my own implementation. That is a reasonable way to detect invalid records. Thanks for the correction. I will add, though, that as you walk the tree back to the roots, downgrades in the key strength do happen as you get to the root 1024bit keys, which is unfortunate. Aside from that, if DNSSEC is detected to be blocked, or invalid, there’s currently not great mechanisms of signaling this to end users (in most software) to either opt into the security risk or notify them, beyond just failing the lookup.
  - deleted 7y ago
    [deleted]
  - teddyh 7y ago
    > the root 1024bit keys I was under the impression that the root key is now 2048 bits, since October 2018, over a year ago. > there’s currently not great mechanisms of signaling this to end users Not unlike SMTP, but we seem to have managed to transition to mostly TLS-encrypted mail transport.
- tptacek 7y ago
  There have in fact been downgrade attacks on DNSSEC; for instance, relatively recent BIND versions would cache unsigned records in the Additional Data section of response packets. Part of the problem is that avoiding downgrade attacks is a shared responsibility between resolvers and authority servers and DNSSEC simply hasn't been fielded enough (and probably never will be) to receive the kind of sustained attention it takes to shake out these kinds of bugs; part of the problem is DNSSEC's incoherent cryptographic design (you can strip all the signatures out of a DNSSEC response and end up with a valid DNS response).

teddyh 7y ago

The resolver has, hard coded, the root zone keys. If the resolver is denied the NS records from the root zone, a resolution is not possible. If the NS records are returned, they are signed and include the lower signature keys. If the NS records are stripped of keys, the signature of those responses is invalid. People have put some thought into the design of DNSSEC, you can’t simply invisibly block it and force a protocol downgrade.

bluejekyll 7y ago
I’ll have to consider this in my own implementation. That is a reasonable way to detect invalid records. Thanks for the correction. I will add, though, that as you walk the tree back to the roots, downgrades in the key strength do happen as you get to the root 1024bit keys, which is unfortunate. Aside from that, if DNSSEC is detected to be blocked, or invalid, there’s currently not great mechanisms of signaling this to end users (in most software) to either opt into the security risk or notify them, beyond just failing the lookup.
- deleted 7y ago
  [deleted]
- teddyh 7y ago
  > the root 1024bit keys I was under the impression that the root key is now 2048 bits, since October 2018, over a year ago. > there’s currently not great mechanisms of signaling this to end users Not unlike SMTP, but we seem to have managed to transition to mostly TLS-encrypted mail transport.
tptacek 7y ago
There have in fact been downgrade attacks on DNSSEC; for instance, relatively recent BIND versions would cache unsigned records in the Additional Data section of response packets. Part of the problem is that avoiding downgrade attacks is a shared responsibility between resolvers and authority servers and DNSSEC simply hasn't been fielded enough (and probably never will be) to receive the kind of sustained attention it takes to shake out these kinds of bugs; part of the problem is DNSSEC's incoherent cryptographic design (you can strip all the signatures out of a DNSSEC response and end up with a valid DNS response).