On Feb 27, 2024, at 17:48, Mark Andrews wrote:
>
> If you forbid in the protocol
But part of this is not “in” the protocol. Eg if two dns hosters happen to
arrive at the same key tag for a single zone in concurrent offline ways. Or if
that happens when KSK and ZSK are managed differently.
It appears that Mark Andrews said:
>It’s not the complexity of the validator we are worried about. The number of
>crypto verifications per second is really low on all
>hardware. Being able to stop validating on the first failure rather than
>having to continue because the attacker has
Warren and I have just published long promised documents. The first
updates RFC8624 to move all recommendations to the DNSSEC registries,
similar to how TLS does. The next two request updates to said
registries for deprecating SHA-1 and ECC-GOST, which we believe the
community wishes to
> On 28 Feb 2024, at 09:58, John R Levine wrote:
>
>>> The kind of load is different but in each case the client needs to
>>> limit the amount of work it's willing to do. We can forbid it in the
>>> protocol but unless you have better contacts at the Protocol Police
>>> than I do, people will
I think this draft is a great idea and I'd love to see it progress. GREASE
did well in TLS and worked wonders in QUIC - it helped us catch multiple
real production issues early on.
That said, I do worry about the idea of using random unallocated values.
Not all software gets updated, and no
The kind of load is different but in each case the client needs to
limit the amount of work it's willing to do. We can forbid it in the
protocol but unless you have better contacts at the Protocol Police
than I do, people will do it anyway.
If you forbid in the protocol the tools will be fixed
> On 28 Feb 2024, at 09:09, John Levine wrote:
>
> It appears that Mark Andrews said:
>> The current “fixes” still leave validators more vulnerable to cpu exhaustion
>> attacks than eliminating colliding key tags in the signer does. This is a
>> protocol bug that leads to
>> cpu
It appears that Mark Andrews said:
>The current “fixes” still leave validators more vulnerable to cpu exhaustion
>attacks than eliminating colliding key tags in the signer does. This is a
>protocol bug that leads to
>cpu exhaustion. We, the IETF, have a duty to fix this at the protocol level.
On Tue, Feb 27, 2024 at 6:07 AM, Toerless Eckert wrote:
> Thanks, Paul
>
> My comment:
>
> https://www.icann.org/en/public-comment/proceeding/
> proposed-top-level-domain-string-for-private-use-24-01-2024/submissions/
> eckert-toerless-27-02-2024 Summary of Submission:
> I would like to see a
> On 28 Feb 2024, at 05:52, Peter Thomassen wrote:
>
>
>
> On 2/16/24 17:19, Jim Reid wrote:
>>> If a zone's signatures and keys are constructed and published in such a way
>>> that it causes indigestion in validators, and as a consequence validators
>>> fail to return responses for data
> On 28 Feb 2024, at 05:50, Peter Thomassen wrote:
>
>
>
> On 2/15/24 22:53, Mark Andrews wrote:
>> But we can state that they should be avoided when generating new DNSKEYs.
>> BIND has been avoiding key tag collisions for 2 decades now when generating
>> new keys. Multi-signers all have
It appears that Peter Thomassen said:
>
>
>On 2/16/24 17:19, Jim Reid wrote:
>It rather seems like inviting instability, then telling the signer "well, you
>knew...! Or should have, at least."
>
>I don't see in what way that's better than what we have with the current
>fixes, which
On Tue, 27 Feb 2024, Toerless Eckert wrote:
Me ? No.
Why do we care whether ICANN will delegate .INTERNAL? They'll never
delegate .AA or .ZZ either, and nobody sees that as a problem.
R"s,
John
On Tue, Feb 27, 2024 at 01:22:43PM -0500, John Levine wrote:
It appears that Joe Abley
On Feb 27, 2024, at 10:53, Toerless Eckert wrote:
>
> On Tue, Feb 27, 2024 at 01:48:22PM +0100, Joe Abley wrote:
>> Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende
>> geschreven:
>>
>>> I would like to see a BCP RFC on the use of the "internal" TLD,
>>> and ICANN should
Hi there,
Op 27 feb 2024 om 19:54 heeft Toerless Eckert het volgende
geschreven:
>> Surely what ICANN is preparing to do is make a decision that an "internal"
>> TLD should never be available.
>
> How did you come to that conclusion. It sounded to me as if ICANN
> is on the road to assign
Me ? No.
On Tue, Feb 27, 2024 at 01:22:43PM -0500, John Levine wrote:
> It appears that Joe Abley said:
> >Hey,
> >
> >Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende
> >geschreven:
> >
> >> I would like to see a BCP RFC on the use of the "internal" TLD,
> >> and ICANN
On Tue, Feb 27, 2024 at 01:48:22PM +0100, Joe Abley wrote:
> Hey,
>
> Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende
> geschreven:
>
> > I would like to see a BCP RFC on the use of the "internal" TLD,
> > and ICANN should not finalize availability of the TLD unless that
On 2/16/24 17:19, Jim Reid wrote:
If a zone's signatures and keys are constructed and published in such a way
that it causes indigestion in validators, and as a consequence validators fail
to return responses for data in that zone, that's a self-inflicted problem and
the zone administrator
On 2/15/24 22:53, Mark Andrews wrote:
But we can state that they should be avoided when generating new DNSKEYs. BIND
has been avoiding key tag collisions for 2 decades now when generating new
keys. Multi-signers all have to have the current published DNSKEY RRset which
includes *all*
It appears that Joe Abley said:
>Hey,
>
>Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende
>geschreven:
>
>> I would like to see a BCP RFC on the use of the "internal" TLD,
>> and ICANN should not finalize availability of the TLD unless that RFC
>> exists.
>
>Surely what
Hey,
Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende
geschreven:
> I would like to see a BCP RFC on the use of the "internal" TLD,
> and ICANN should not finalize availability of the TLD unless that RFC
> exists.
Surely what ICANN is preparing to do is make a decision
Thanks, Paul
My comment:
https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024/submissions/eckert-toerless-27-02-2024
Summary of Submission:
I would like to see a BCP RFC on the use of the "internal" TLD,
and ICANN
22 matches
Mail list logo
