Paul Wouters writes:
> I drop my objection to changing SHA1 status :)
I win I win!
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I have a question which doesn't need answering, but I have it anyway.
Nobody intends re-using the code points, right?
So the deprecation is about BCP, not about conformance to protocol?
It's just the DNS police telling people to move along?
Some days, I think that kind of thing might be better
On Mon, 15 Aug 2022, Viktor Dukhovni wrote:
Presently, out of 18,975,098 working signed delegations:
* 136,295 zones use RSASHA1-NSEC3-SHA1 (7).
* 21,254 zones use RSASHA1 (5).
So the number of eTLD+1 zones that rely on SHA-1 RRSIGs is a fairly
stable ~0.8%, and a stronger nudge would
On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote:
> I think our decision should be based on the deplyment statistics of SHA1
> based zones and keys. I'd love to see the trending statistics from
> Viktor to guide us here. Last time we looked it was still in the order
> of 40% or so ?
>
On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote:
> I think our decision should be based on the deplyment statistics of SHA1
> based zones and keys. I'd love to see the trending statistics from
> Viktor to guide us here. Last time we looked it was still in the order
> of 40% or so ?
On Mon, 15 Aug 2022, Tony Finch wrote:
o 2019: IETF partially deprecates SHA-1 for use in DNSSEC [RFC8624]
"s/partially/for new stuff/"
o 2020: Chosen-prefix collision demonstrated in SHA-1 [SHA-mbles]
Yes, this is where we disagree about whether this can be abused in
DNSSEC. You
Paul Wouters writes:
> This is why I also think 8624bis is better than a stand-alone document,
> as it takes into account security effects, market deployment, and
> trying to push the deployments to where we want it to go, instead of just
> issuing a document the current deployments have no
Wes Hardaker wrote:
>
> Because it's time...
Better late than never :-)
My draft from a couple of years ago describes some fun attacks you can
perform on DNSSEC if you can generate a hash collision. So I think SHA-1
ought to be MUST NOT for signing, and there should be a concerted effort
to get
On Fri, 2022-08-12 at 08:48 -0700, Wes Hardaker wrote:
> This document retires the use of SHA-1 within DNSSEC
(Half-echoing what Mark Andrews said elsewhere in the thread.)
This document fails to retire the use of SHA-1 in NSEC3, and is thus,
given its current title, incomplete.
We can do
On Sun, 14 Aug 2022, Tim Wicinski wrote:
Speaking as a chair, and a fan of 8624, I would welcome a 8624-bis document to
appear.
(I think I expressed this to others than myself, but).
The table in 3.1 is so clear in what to use and not use.
Right, but there is a reason the original
Speaking as a chair, and a fan of 8624, I would welcome a 8624-bis document
to appear.
(I think I expressed this to others than myself, but).
The table in 3.1 is so clear in what to use and not use.
And Paul W is correct if someone else creates a 8624-bis and then
we can sort out the
Sent using a virtual keyboard on a phone
> On Aug 14, 2022, at 12:38, Wes Hardaker wrote:
>
> Paul Wouters writes:
>
>> If only we had thoughts about this before, hey look RFC 8624. Why not
>> do a bis of that one ? (Yes I have thought about it as author, but I
>> don’t agree we
Paul Wouters writes:
> If only we had thoughts about this before, hey look RFC 8624. Why not
> do a bis of that one ? (Yes I have thought about it as author, but I
> don’t agree we can/should kill sha1 yet on the validation path)
That's a possibility too, but then I'd have to fight the authors
On Aug 13, 2022, at 23:56, Wes Hardaker wrote:
>
> Roy Arends writes:
>
>> What is missing is how validators/validating resolvers should behave
>> when presented with SHA1.
If only we had thoughts about this before, hey look RFC 8624. Why not do a bis
of that one ? (Yes I have thought
Roy Arends writes:
> What is missing is how validators/validating resolvers should behave
> when presented with SHA1.
Yep; see the response to Jim.
[the draft was a starting place, of course; I'm sure there will be more
text needed. "send text" is always an adequate thing to do]
--
Wes
Wes,
What is missing is how validators/validating resolvers should behave when
presented with SHA1.
Roy
> On 12 Aug 2022, at 16:48, Wes Hardaker wrote:
>
>
> Because it's time...
>
> Start of forwarded message
> From: internet-dra...@ietf.org
> To:
Because it's time...
Start of forwarded message
From: internet-dra...@ietf.org
To: "Wes Hardaker"
Subject: New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Date: Fri, 12 Aug 2022 08:48:21 -0700
A new version of I-D,
17 matches
Mail list logo
