Dear DNS experts,
In a research which we concluded in June 2023 we performed longitudinal
measurements (2020 - 2023) and analysis of abuse of dandling DNS records.
We characterize the abuse and the attackers' infrastructure with
recommendations for countermeasures.
The research will be presented
Dear researchers, operators and developers,
Recently two attack vectors exploiting vulnerabilities in DNSSEC to launch
Denial of Service (DoS) against DNS resolvers were publicly disclosed:
KeyTrap and NSEC3-encloser attack. Both issues were assigned a CVE ID by
MITRE: KeyTrap CVE-2023-50387 and
KeyTrap
attacks that exploit them can be found here:
https://labs.ripe.net/author/haya-shulman/keytrap-algorithmic-complexity-attacks-exploit-fundamental-design-flaw-in-dnssec/
The technical report describing our research can be found here:
https://www.athene-center.de/fileadmin/content/PDF
ow attacks against DNS can
subvert RPKI validation. This research will be presented in November 2022.
Best, Haya Shulman
--
Prof. Dr. Haya Shulman
Goethe-Universität Frankfurt
Fraunhofer SIT
ATHENE
___
dns-operations mailing list
dns-operations@lis
chten and Happy new year.
--
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC SPRIDE
Mornewegstr. 30
64293 Darmstadt
Tel. +49 6151 16-75540
www.ec-spride.de
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://list
at contains the
> cookie.
In any case, it is great that you also agree that the published proposal
may be vulnerable and propose to use checksum to prevent those attacks.
On Sat, Oct 26, 2013 at 12:12 PM, Haya Shulman wrote:
> No number of hosts sending packets can exceed 25,000 500
hey used
only a single host that generated the traffic, and the traffic consisted of
64 Byte packets (we used 500Byte packets).
In any case, I am curious as to wether the loss occured in DNS software and
if increasing the buffers in DNS software can mitigate the problem (I'll
run it a
espite the use of Eastlake cookies for protection). This
should be of interest to DNS community, unless you argue that the DNS
community should rely on IP layer for security of DNS.
--
Best Regards,
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC S
en no loss; the cause for this
are the delays added by the interrupts of the sending system, and the
routers enroute (that further add their own interrupts). Thus, the impact
of the resulting volume is negligible, and does not result in packets'
loss. But, if the volume is split between a numb
backward
> looking, perhaps due to publication delays. For example, default
> verifying now in server software and verifying by resolvers such
> as 8.8.8.8 should help the verifying situation.
>
>
Agreed and noted, thank you.
p.s. Can you please cc me when sending responses related to me
nswer, NXDOMAIN, NODATA?
3. Did you try spoofing the glue in responses to DNSSEC validating
resolvers?
On Wed, Oct 23, 2013 at 7:24 PM, Dickson, Brian wrote:
> Paul Vixie wrote:
>
>
> Haya Shulman wrote:
>
>
>
>> > > so if i add "first weaponized by Haya S
On Tue, Oct 22, 2013 at 11:15 PM, Paul Vixie wrote:
> Haya Shulman wrote:
>
>
>
>> > > so if i add "first weaponized by Haya Shulman" this would settle the
>> > > matter?
>> >
>> > Thank you, can you please use Amir Herzberg and H
On Mon, Oct 21, 2013 at 1:42 PM, P Vixie wrote:
> On Tuesday, October 22, 2013 19:47:34 Haya Shulman wrote:
> > On Tue, Oct 22, 2013 at 6:20 PM, Paul Vixie wrote:
> > > note, i am using <http://arxiv.org/pdf/1205.4011.pdf> as my reference
> to
> > > haya sh
OARC through official channels?
Thank you.
On Tue, Oct 22, 2013 at 7:53 PM, Keith Mitchell wrote:
> On 10/22/2013 10:52 AM, Haya Shulman wrote:
>
> >> Disclosing such potential vulnerabilities remains valuable work,
> >> but I think careful consideration needs to be applied
sed to
> reference haya's work in my circleid blog post.
>
> In the first message in this thread I referred to my site, where all
updated papers are available.
sites.google.com/site/hayashulman/publications
Haya Shulman wrote:
>
>
> ---
>
> thanks for clarifying that
tocol,
between the proxy resolver and an upstream forwarder, prevents the attacks.
> Rubens
>
>
--
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC SPRIDE
Mornewegstr. 30
64293 Darmstadt
Tel. +49 6151 16-75540
www.ec-spride.de
_
,
while they may be vulnerable to attacks.
Please see paper for more details and a brieft abstract in the first
message on this thread.
--
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC SPRIDE
Mornewegstr. 30
64293 Darmstadt
Tel. +49 6151 16-75540
www.e
ious about relative priorities and
> by statements like that sentence above that suggests that fixing port
> randomization could be easier than deploying DNSSEC in any except quite
> exceptional cases.
This conspiracy theory is intriguing...
On Sat, Oct 19, 2013 at 7:14 PM, Haya Shul
surprising to me, that after so many years, the community is still not
convinced that port randomisation is signfiicant.
Furthermore, if port randomisation is not an issue why standardise
[RFC6056]? Why set up DNS checkers? If current port randomisation
algorithms are vulnerable - why not fix?
O
)
On Sun, Oct 20, 2013 at 10:42 PM, Haya Shulman wrote:
> In that case, on what should an organization spend time or money
>
> first, on DNSSEC or the recommendations in the mail message? Would
> it be better if each of the recommendations in the mail message
> started with som
deanonymisation of communication over
TOR. Some of the papers are already on my site.
>
>
On Sun, Oct 20, 2013 at 10:01 PM, Haya Shulman wrote:
> Sorry for delay, I was omw to a different continent.
> Please see response below.
>
>
> On Sat, Oct 19, 2013 at 9:21 PM, Paul V
may be concerned (often justly) with enforcing
strict DNSSEC validation, due to interoperability (or other) problems (we
discuss this in more detail in `Availability and Security Challenges
Towards Adoption of DNSSEC`).
>
>
>
On Sat, Oct 19, 2013 at 7:14 PM, Haya Shulman wrote:
> IMHO,
Sorry for delay, I was omw to a different continent.
Please see response below.
On Sat, Oct 19, 2013 at 9:21 PM, Paul Vixie wrote:
> Haya Shulman wrote:
>
> You are absolutely right, thanks for pointing this out.
>
>
> thanks for your kind words, but, we are still not comm
eam"? Why aren't efforts to protect port
randomization, hide hidden servers and so forth like trying to make
it safe to use .rhosts and /etc/hosts.equiv files by filtering ICMP
dedirects and IP source routing, and strengthening TCP initial sequence
>
> numbers?
On Sat, Oct 19, 201
ld lead
> some to believe that these attacks are immune to DNSSEC protection
> of
> the cache.
>
> Cheers,
> Phil
>
--
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC SPRIDE
Morewegstr. 30
64293 Darmstadt***
to any of
> these vulnerabilities, can you explain why not? Vixie
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC SPRIDE
Morewegstr. 30
64293 Darmstadt
Tel. +49 6
aper on my site).
To appear at IEEE CNS'13.
--
Best regards.
Haya Shulman
Technische Universität Darmstadt
FB Informatik/EC SPRIDE
Morewegstr. 30
64293 Darmstadt
Tel. +49 6151 16-75540
www.ec-spride.de
___
dns-operations ma
Yes, I was referring to porttest.
Best.
On Mon, Sep 9, 2013 at 6:27 PM, Keith Mitchell wrote:
> On 09/09/2013 06:07 AM, Haya Shulman wrote:
>
> > For instance, DNS-OARC does not detect port prediction attacks, and
> > reports clients as secure, while they are vulnerable to
On Sun, Sep 8, 2013 at 5:25 PM, Aaron Campbell wrote:
> On 2013-09-06, at 3:44 PM, Haya Shulman wrote:
>
> > We studied the IPID randomisation on the name servers (not the
> resolvers). Only the name server side IPID randomisation is relevant to the
> attack, since it is the
Yasuhiro-san :-)
Nice find, thanks for sharing!!
I will add reference to it in our works.
On Sun, Sep 8, 2013 at 3:00 PM,
wrote:
>
>
> Message: 6
> Date: Sun, 08 Sep 2013 17:30:57 +0900 (JST)
> From: Yasuhiro Orange Morishita / <
> yasuh...@jprs.co.jp>
> To: aa...@arbor.net
> Cc: dns-opera
> On Fri, Sep 06, 2013 at 09:44:34PM +0300,
> Haya Shulman wrote
> a message of 232 lines which said:
>
> > We studied the IPID randomisation on the name servers (not the
> resolvers).
>
> Just a warning: it's IPID _unpredictability_ (for a blind attacker)
> wh
Hello Aaron,
Please see below.
On Fri, Sep 6, 2013 at 7:33 AM, Aaron Campbell wrote:
> On 2013-09-05, at 10:02 PM, Haya Shulman wrote:
>
> > I would recommend short term patched (that we recommend in the paper) in
> the meanwhile, and addressing the deployment challenges of D
32 matches
Mail list logo
