I made a mistake in my previous mail.
> From: Kazunori Fujiwara
> Sorry for too late reply.
> Authors submitted -17 today.
>
>> From: Martin Duke via Datatracker
>> Date: Tue, 02 Jan 2024 11:44:09 -0800
>
>> Martin Duke has entered the following ballot position for
>> draft-ietf-dnsop-avoid-fr
Sorry for too late reply.
Authors submitted -17 today.
> From: Martin Duke via Datatracker
> Date: Tue, 02 Jan 2024 11:44:09 -0800
> Martin Duke has entered the following ballot position for
> draft-ietf-dnsop-avoid-fragmentation-16: Discuss
>
> When responding, please keep the subject line int
Mark Andrews writes:
> Ed, your reasoning is off. The point of forbidding is to allow the
> validator to safely stop as soon as possible when it is under
> attack.
Uh? Why can't any DNS server safely stop as soon as possible when it
is under attack?
Count me in the "we don't need a protocol cha
Dear dnsop WG,
Authours submitted avoid-fragmentation-17 following comments from IESG review.
> Internet-Draft draft-ietf-dnsop-avoid-fragmentation-17.txt is now available.
> It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
>
> https://datatracker.ietf.org/doc/draft
Internet-Draft draft-ietf-dnsop-avoid-fragmentation-17.txt is now available.
It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: IP Fragmentation Avoidance in DNS over UDP
Authors: Kazunori Fujiwara
Paul Vixie
Name:draft-ietf-dnsop-avoid
How much would those "unnecessary expensive validations attempts" cost with
modern hardware?
Is it still a concern enough that they justify continuing using those tags
instead of the full key?
Wouldn't that limit the risk of collision?
Regards,
Arnold Dechamps
So, I am the person who added
> On Feb 29, 2024, at 07:52, Edward Lewis wrote:
> (If no action is taken, malicious activity might follow now that it is
> described, but I have not heard of a historical case of it.)
This attack was more or less described five year ago:
https://essay.utwente.nl/78777/
They didn’t get to
I think it might be worth distinguishing between caching validators and end
validators. For an end validator, doing a second validation is not going to
be a serious issue. The Apple DNSSEC validator currently does not allow key
tag collisions at all, but it's not yet in heavy use so I wouldn't want
From: DNSOP on behalf of Shumon Huque
Date: Wednesday, February 28, 2024 at 16:22
To: Edward Lewis
Cc: John Levine , "dnsop@ietf.org"
Subject: Re: [DNSOP] [Ext] About key tags
>… I think writing a BCP telling folks how to avoid collisions would make sense
>though (and yes, it needs to cover
Op 29 feb 2024 om 09:35 heeft Ralf Weber het volgende
geschreven:
> Bind and and other servers (egg Akamai Cacheserve) already stop/fail when
> having more then two keys with a colliding key tag today. I think what at
> least I want is that every key a validator has to consider has a unique k
Moin!
On 28 Feb 2024, at 22:44, John R Levine wrote:
> On Thu, 29 Feb 2024, Mark Andrews wrote:
>>> If it is forbidden in the protocol, it might still happen.
>>
>> Ed, your reasoning is off. The point of forbidding is to allow the
>> validator to safely stop as soon as possible when it is unde
11 matches
Mail list logo
