See our I-D on lifecycle. It addresses this issue squarely. I'm about to
to dinner and can't fill in the details. I'll do so later if someone
hasn't already.
Steve
Sent by a Verified
sender
On Wed, Nov 13, 2024 at 7:04 PM Philip Homburg
wrote:
> >Tony Finch has correctly identified in SHA
>See our I-D on lifecycle. It addresses this issue squarely.
The problem is that RedHat went ahead and disabled support for SHASHA1
(in the default configuration). That results in systems that
violate the current DNSSEC standards. It seems some people would like to
change the standards in suc
It was the red hat situation that led me to write this. Red hat should have
gone to phase 6, not phase 7.
I recommend moving SHASHA1 to phase 6 for the time being.
Steve
Sent from my iPhone
> On Nov 13, 2024, at 7:55 PM, Philip Homburg
> wrote:
>
>
>>
>> See our I-D on lifecycle. It
>Tony Finch has correctly identified in SHA-1 chosen prefix collisions
>and DNSSEC [3] article that when a single record is usually safe,
>multiple records might allow creating fake signature even in DNSSEC.
There are two types of attacks on hash functions: collisions and second
pre-image attac
On 11/13/24 19:55, Philip Homburg wrote:
See our I-D on lifecycle. It addresses this issue squarely.
The problem is that RedHat went ahead and disabled support for SHASHA1
(in the default configuration). That results in systems that
violate the current DNSSEC standards.
Yes. Given that
It sounds like you are primarily interested in split-horizon DNS deployments.
That's fine, but it doesn't require the complexity of the proposal you've drawn
up here.
Instead, we can "simply" append the server's name to the response packet in
EDNS at each hop, if the stub requested it, accumul
I recall that the key objection there was related to displaying HTML controlled
by the DNS server. Limiting the responses to plain text, as proposed here,
makes it significantly less scary.
--Ben
From: Ralf Weber
Sent: Monday, November 11, 2024 9:25 PM
To: Ben
