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 g
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"
> conta
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 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 Tr
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
tw
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 th
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
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
pr
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 ke
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 a
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 me
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 i
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 ot
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,
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.
>
> 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
> collisio
16 matches
Mail list logo