Re: KeyTrap DNS vulnerability
On Wed, February 14, 2024 4:44 am, Peter J. Philipp wrote: > ... > > * I'm not a cryptographer, mathematician nor do I program DNS on the > recursive end. I program on the authoritative server end, where you can't > do anything about something like a MITM anyhow. Donald Knuth and other > books using algorithmic approaches may be good reading for this. if you have I2P instead or even Tor (hidden services only, not clearweb) you don't need broken DNS
Re: KeyTrap DNS vulnerability
Otto Moerbeek wrote: > On Wed, Feb 14, 2024 at 04:55:20AM +0100, b...@fea.st wrote: > > > “A single packet can exhaust the processing > > capacity of a vulnerable DNS server, effectively > > disabling the machine, by exploiting a > > 20-plus-year-old design flaw in the DNSSEC > > specification. > > > > https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/ > > To be clear, this does not mean DNSSEC is cryptographically broken. > > The RFCs specifying the DNSSEC validation algorithm do not take into > account potential resource usage validating many potential signatures > so the implementations following the RFCs suffered from the same. > > By constraining the amount of work (limiting the potential signatures > considered) while validating these issues are worked around. Otto you just don't believe the sky is falling.
Re: KeyTrap DNS vulnerability
On Tue, Feb 13, 2024, at 9:55 PM, b...@fea.st wrote: > “A single packet can exhaust the processing > capacity of a vulnerable DNS server, effectively > disabling the machine, by exploiting a > 20-plus-year-old design flaw in the DNSSEC > specification. > > https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/ -current and both -stable branches have been updated: https://marc.info/?l=openbsd-cvs=2=1=CVE-2023-50387=b Brian Conway Owner RCE Software, LLC
Re: KeyTrap DNS vulnerability
On Wed, Feb 14, 2024 at 04:55:20AM +0100, b...@fea.st wrote: > “A single packet can exhaust the processing > capacity of a vulnerable DNS server, effectively > disabling the machine, by exploiting a > 20-plus-year-old design flaw in the DNSSEC > specification. > > https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/ To be clear, this does not mean DNSSEC is cryptographically broken. The RFCs specifying the DNSSEC validation algorithm do not take into account potential resource usage validating many potential signatures so the implementations following the RFCs suffered from the same. By constraining the amount of work (limiting the potential signatures considered) while validating these issues are worked around. -Otto
Re: KeyTrap DNS vulnerability
On 2/14/24 04:55, b...@fea.st wrote: “A single packet can exhaust the processing capacity of a vulnerable DNS server, effectively disabling the machine, by exploiting a 20-plus-year-old design flaw in the DNSSEC specification. https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/ Thank you for sharing this, it's good to talk about this, as it affects any cryptographic keying system. I was aware of this for a few years without giving it more thought because sending random garble instead of DNSSEC keys was mentioned on chat channels such as #dns before. In my opinion, the defenses are not to turn off DNSSEC, but rather, to do some sanitizing of the cryptographic data with a lesser cost algorithm. Such as length checks, heuristic collection identifying an algorithm before using the main decryption algorithm on it *. To be honest I looked at the patches but wasn't any wiser that this was really done. Another approach is to flag abusers of DNSSEC keys and block them for some time penalty, and if repeated abuse happens then to block the entire site. * I'm not a cryptographer, mathematician nor do I program DNS on the recursive end. I program on the authoritative server end, where you can't do anything about something like a MITM anyhow. Donald Knuth and other books using algorithmic approaches may be good reading for this. Best Regards, -peter
KeyTrap DNS vulnerability
“A single packet can exhaust the processing capacity of a vulnerable DNS server, effectively disabling the machine, by exploiting a 20-plus-year-old design flaw in the DNSSEC specification. https://www.theregister.com/2024/02/13/dnssec_vulnerability_internet/
