Re: [DNSOP] [dnsext] DNS vulnerabilities
David Conrad wrote: >> Then, plain DNS modified to have 32 (or 64?) bit messages >> ID is as secure as DNSSEC. > > How does a 32 or 64 bit message ID protect you from on-path > MITM/injection attacks? Tell it to those who are asserting plain NTP were good enough for DNSSEC. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
Mark Andrews wrote: >> Not necessarily. Some security protocol can safely assume >> clocks of related equipments are manually managed by skilled >> operators, which is not the case with DNS clients. > > Most people are capable of setting the clocks on their laptops, > phones and other portable equiment which all should be validating > responses. Most people are capable of setting clocks on their > desktop machines which should be validating responses. Because they have buttons and displays to do so, which is not the case for a home router as a black box. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
On Mon, Oct 28, 2013 at 04:57:46PM +0100, Marc Lampo wrote: > How could a "local time problem" lead to using an "expired (zone) key" for > arbitrary data of the zone ? There is a genuine theoretical concern here, but IMHO it's unrealistic. Imagine some shadowy omnipotent organization has tapped your connection to the internet and controls every packet you send and receive. Your router box (or other embedded device lacking an RTC battery) boots and requests the current time via NTP. The bad guys send a forged response indicating a time in the past, then they answer all DNS queries by replaying data that were captured at that time: the answers *used* to be valid, but they aren't anymore. Now suppose this no-longer-valid data includes a TLSA record for a certificate that's been compromised and revoked since then...? I can't see this as realistic for several reasons - among them, that it's easily detectable by anyone who happens to compare the clock on their router to what it says on their calendar, and I presume a shadowy omnipotent organization would have a strong preference for undetectability. I'd prefer "provably impossible" to "insanely impractical" if I had a choice in the matter, but the truth is, any adversary with the resources to pull this off would certainly have cheaper alternatives. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
How could a "local time problem" lead to using an "expired (zone) key" for arbitrary data of the zone ? ~ DNSKEY info itself does not expire - only signatures have expiration date ~ admitting a "local time problem" can allow for replay attacks in the sense of : "making a validating resolver believe the RRSIG is still within validity time". Do not overlook the fact that the public key is still required to perform the validation itself ! So, I think you actually make a case for not letting "no longer used" DNSKEY information linger in the zone file. Overall, assuming a DNS reply for www.example.com. with a signed but expired signature, would also need the no longer used zone signing key signed with the key signing key (possibly also expired) (and things get even more complicated if the key signing key has been rotated as well) So, there is still a lot of value in validating DNSSEC responses. Kind regards, Marc On Mon, Oct 28, 2013 at 5:07 AM, Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > (partly removed) > > The problem is that, without human intervention by skilled > operators, clocks can be very inaccurate. > > Then, a compromised and expired zone key can be used for > arbitrary data of the zone, which is more serious than > replay attack. > > Masataka Ohta > > ___ > dnsext mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
On Oct 28, 2013, at 12:07 AM, Masataka Ohta wrote: > Then, plain DNS modified to have 32 (or 64?) bit messages > ID is as secure as DNSSEC. How does a 32 or 64 bit message ID protect you from on-path MITM/injection attacks? Protecting the communication channel does not equal protecting the data. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
