On Feb 29, 2024, at 20:33, Arnold DECHAMPS wrote:
>
>
> Is it still a concern enough that they justify continuing using those tags
> instead of the full key?
The full key is not there. There is only a key tag. Are you proposing a wire
format change to DNSSEC that puts the full key there?
>First, forbidding key tag collisions is not controversial, the
>trouble is that forbidding them is not feasible and, more
>importantly, does not prevent them from happening. Validators
>still need to guard themselves. Forbidding is what I'm objecting
>to - discouraging them,
>Remember that the keytags are just a hint to limit the number of keys
>you need to check for each signature. If I have a zone with 300
>signatures per key, it's still going to take a while to check them all
>even with no duplicate tags. It won't be as bad as the quadratic
>keytrap but it'll still
On 3/1/24, 13:45, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg"
wrote:
>If we have a protocol where validators are allowed to discard RR sets with
>duplicate key tags but we place no restriction on signers, then we have a
>protocol with a high chance of failure even if
> I removed a lot of logic, as it seems dead on. But...
>
> >This would allow validators to reject any DS or DNSKEY RR set that has a
> >duplicate key tag.
>
> "This" refers to barring keys from having duplicate key tags. My
> knee-jerk response is that validators are already permitted
Technically only a SHA-2 hash of the key would need to be there. If somebody
can create a SHA-2 hash collision then the world has bigger problems than
a DoS on DNSSEC validation.
How hard would it be to add a possibility for another key algorithm?
Beyond the change to the specs, it would
>The full key is not there. There is only a key tag. Are you proposing a wire f
>ormat change to DNSSEC that puts the full key there? That would be hard and sl
>ow to deploy and use up value bytes of the limited +/- 1400 bytes.
>
>> Wouldn't that limit the risk of collision?
>
>At a price, yes.
On 1 Mar 2024, at 16:44, Philip Homburg wrote:
>>> Wouldn't that limit the risk of collision?
>>
>> At a price, yes.
>
> Technically only a SHA-2 hash of the key would need to be there. If somebody
> can create a SHA-2 hash collision then the world has bigger problems than
> a DoS on DNSSEC
> So really what you're suggesting is that we change the keytag
> algorithm to something that has a lower chance of collisions.
>
> It's a shame that the design of keytags didn't anticipate a need
> for algorithm agility.
Even if key tags would have been MD5 it would have been enough for
On 3/1/24, 11:13, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg"
wrote:
I removed a lot of logic, as it seems dead on. But...
>This would allow validators to reject any DS or DNSKEY RR set that has a
>duplicate key tag.
"This" refers to barring keys from having duplicate
Remember that the keytags are just a hint to limit the number of keys
you need to check for each signature. If I have a zone with 300
signatures per key, it's still going to take a while to check them all
even with no duplicate tags. It won't be as bad as the quadratic
keytrap but it'll still be
> If a validator chooses to discard all signatures for which there
> are multiple DNSKEY resource records matching the key tab in the
> RRSIG resource record, there'll be SERVFAILs across the population
> that cares about the data involved. From past observations, when
> there's a widespread "I
On Fri, Mar 1, 2024 at 2:38 PM Edward Lewis wrote:
> On 3/1/24, 13:45, "pch-b538d2...@u-1.phicoh.com on behalf of Philip
> Homburg" pch-dnso...@u-1.phicoh.com> wrote:
>
> >If we have a protocol where validators are allowed to discard RR sets
> with
> >duplicate key tags but we place no
You don’t perform a verify if the time window is invalid. The same as you don’t
perform a verify if the tag doesn’t match. Mind you it’s completely pointless
to have multiple time ranges. The RRset and it’s signatures travel as pairs.
All the key rollover rules depend on that.
--
Mark
You don’t perform a verify if the time window is invalid. The same as you don’t
perform a verify if the tag doesn’t match. Mind you it’s completely pointless
to have multiple time ranges. The RRset and it’s signatures travel as pairs.
All the key rollover rules depend on that.
I agree it
> For about the hundredth time, the woy you deal with any of this is
> resource limits, not trying to invent new rules about stuff we
> might have forbidden if we'd thought of it 20 years ago.
There are a number of problems with resource limits:
1) We haven't written it down (in an RFC). So we
In your letter dated Fri, 1 Mar 2024 15:42:49 -0500 you wrote:
>Offlist because I don=E2=80=99t want to feed the flames, but:
>
>>=20
>> 2) Operators of validators don't want customer facing errors due resource
>> limit constraits. So they set them generous enough that it works for
>> real
17 matches
Mail list logo
