Florian Maury (pub-dnsop) writes:
> Let's take an extreme example to illustrate:
[...]
> Mallory wants to read Alice's emails. He manages to rent Bob "AMX". He,
> then, replays the old MX record set whose signature are not expired (the
> signature is still valid for 2 months) to Charlie, whose resolver is
> vulnerable to the Kaminsky hack.
I use precisely this example in our workshops to illustrate why TTLs
are included in the signatures, and why these are limited in duration.
(Slight variation: old IP is rented by attacker to host a website that
then does an SSL stripping attack, and Bob's your uncle[*])
You still control the validity of the data in the cache, though you
don't control the cache behaviour.
> If Alice could have revoked her signature on the previous MX RRSet, her
> emails sent by Charlie would not have been redirected to Mallory's server.
Revoking = have short signature lifetime, publish new ones regularly
that will be preferred by validators.
> One can tell "She should not have signed for a period that long". It's
> the eternal problem of zone survivability: the shorter the signature,
> the shorter the interval a slave server can serve data before it expires
> without signing the zone himself (which can be a problem if the slave
> server is administrated by a third party).
It's an operational challenge, not a design one, and it remains:
"polluting" caches with still-valid data is not cache poisoning
(that data could have ended up in the cache in any number of ways;
ceasing to publish signed data does not preclude it still being
available somewhere).
[*] No relation to to Alice's Bob.
Cheers,
Phil
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
