> On 21 Feb 2024, at 01:58, Edward Lewis wrote:
>
> That’s where I’m heading as well…
> 1) Benign collisions aren’t major headaches, except perhaps for the key
> manager (because rare events are headaches)
> 2) Validator resource consumption is a general issue, not tied to key tag
>
On Feb 20, 2024, at 5:42 AM, Edward Lewis wrote:
>
> On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" on behalf of ma...@isc.org> wrote:
>
> Pardon ... perhaps this issue has died down, but I've been off a few days,
> and I just saw this...
>
>> Generating a new key is not hard to do.
>
Thanks for this helpful input!
(In theory DNSSEC could prevent falsified responses about scope, but I
realize that it's not widely deployed :(
Let's also think about the more general (non-ACME) application use case
too. Maybe multiple possible ways to indicate scope are needed.
Shumon.
On Tue,
There are some benefits in ACME for it being on the label (At least in the
ACME use case):
It being on the label provides external confirmation that the ACME server
did the correct thing. If it's part of the response, it's a lot easier for
an ACME server to falsely claim the scope was something
From: DNSOP on behalf of Bob Harold
Date: Tuesday, February 20, 2024 at 09:53
To: Edward Lewis
Cc: "dnsop@ietf.org" , Paul Wouters
Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About
key tags
>But if I have a 'standby' DS record, to allow faster rollover if a key
Sorry, Bob, this is just me being ignorant—my experience of zone signing
and validation is largely as a consumer, not an author of code. If this can
only occur within a single zone, then I think what I said still
applies—it's hard to see how this is a serious problem in that case. Again,
I don't
That’s where I’m heading as well…
1) Benign collisions aren’t major headaches, except perhaps for the key manager
(because rare events are headaches)
2) Validator resource consumption is a general issue, not tied to key tag
collisions
My kicking this off was not the KeyTrap issue, a report of
On Tue, Feb 20, 2024 at 8:42 AM Edward Lewis wrote:
> On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" <
> dnsop-boun...@ietf.org on behalf of ma...@isc.org> wrote:
>
> Pardon ... perhaps this issue has died down, but I've been off a few days,
> and I just saw this...
>
> >Generating a new
Sorry, I did not mean that the attack isn't a serious problem. I mean that
insisting that there be no key hash collisions in a verification attempt is
not as hard a problem as you were suggesting. The main issue is that it
would require a flag day, but the number of affected zones in the wild is
On Tue, Feb 20, 2024 at 9:06 AM Ted Lemon wrote:
> This seems like an implementation detail. The random likelihood of the
> root and com key hashes colliding seems pretty small. And while com is
> rather large, computes aren't as expensive as they were when y'all invented
> the ritual. I suspect
From: Ted Lemon
Date: Tuesday, February 20, 2024 at 09:05
To: Edward Lewis
Cc: Mark Andrews , Paul Wouters ,
"dnsop@ietf.org"
Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About
key tags
>This seems like an implementation detail.
I don’t want to brush this off
This seems like an implementation detail. The random likelihood of the root
and com key hashes colliding seems pretty small. And while com is rather
large, computes aren't as expensive as they were when y'all invented the
ritual. I suspect that if you just always pick two keys and sign the zones
On 20 Feb 2024, at 11:55, jab...@strandkip.nl wrote:
> That is some good, arcane DNS knowledge right there, Niall, I like it!
8-)
> [...]
> Perhaps it's worth making it even more clear that this is just a provision
> for AXFR responses by specifying the QTYPE? Something like:
>
> DNS Zone
On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" wrote:
Pardon ... perhaps this issue has died down, but I've been off a few days, and
I just saw this...
>Generating a new key is not hard to do.
That's not the issue, it's knowing that it would be the wise thing to do that
is the issue.
On 20 Feb 2024, at 12:38, Niall O'Reilly wrote:
> I think it would help, for completeness, and the better
> to support the inexperienced reader of the DNS scriptures,
> to include mention of RFC5936 (AXFR) in the "brief summary
> of the guidance provided in the existing DNS specification"
>
On 15 Feb 2024, at 15:57, Suzanne Woolf wrote:
> The qdcount draft is brief and straightforward
and very welcome.
I think it would help, for completeness, and the better
to support the inexperienced reader of the DNS scriptures,
to include mention of RFC5936 (AXFR) in the "brief summary
of the
16 matches
Mail list logo
