>The advise is split between producing SHA1 signatures and consuming SHA1
>signatures, and those timings do not have to be identical.
>
>That said, a number of OSes have already forced the issue by failing
>SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So
>right now, if you ru
On Tue, 30 Apr 2024, Philip Homburg wrote:
The advise is split between producing SHA1 signatures and consuming SHA1
signatures, and those timings do not have to be identical.
That said, a number of OSes have already forced the issue by failing
SHA1 as cryptographic operation (RHEL, CentOS, Fedo
>It will also prevent ServFails when the system crypto SHA1 for
>authentication and signature purposes is blocked, and the DNS software
>sees this as a failure and returns BOGUS. I am not sure how many DNS
>implementations are now probing SHA1 and on failure put it in the
>"unsupported algorithm" c
On Tue, 30 Apr 2024, Mark Andrews wrote:
They DO NOT disable SHA1. They disable RSASHA1. The distinction is
important. NSEC3 works fine on them.
There were issues with NSEC3's use of SHA1 as well. I am failing to find
the reports on this now unfortunately.
Paul
___
One got servfail because validators where not aware that support was ripped
away underneath it. Validators started to get errors that where totally
unexpected. Performing runtime testing of algorithm support addressed that by
allowing the validator to skip the unsupported algorithm.
--
Mark An
On Tue, 30 Apr 2024, Philip Homburg wrote:
So what happens instead is that software is patched to return insecure if
SHA1 is not avaiable for signing and that is of course very risky.
has been patched, yes. The problem arguably is that DNS moved WAY slower
that the industry as a whole to get r
On Wed, 1 May 2024, Mark Andrews wrote:
One got servfail because validators where not aware that support was ripped
away underneath it. Validators started to get errors that where totally
unexpected. Performing runtime testing of algorithm support addressed that by
allowing the validator to s
Hi there all,
I'm sending this to multiple lists, so you might get multiple copies…
As mentioned during the Deleg BoF, we are casting a wide net for chairs for
the (proposed) Deleg WG.
The DNS is "core plumbing" for the Internet. It is also one of the very few
protocols which has scaled through
The validators where not returning BOGUS. They where returning unknown error.
Both errors resulted in servfail.
Once we knew what RH had done one could go from compile time testing of support
to runtime testing of support.
The DNSSEC RFC’s already told developers how to handle this. RSASHA
And that doesn’t fail in RH with the tighter crypto.
--
Mark Andrews
> On 1 May 2024, at 00:46, Paul Wouters wrote:
>
> On Wed, 1 May 2024, Mark Andrews wrote:
>
>> One got servfail because validators where not aware that support was ripped
>> away underneath it. Validators started to ge
>- FIPS
>- PCI-DSS
>- BSI
>- OWASP
>- SOC2
>- PKI-industry & CAB/Forum
>- TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF.
>- All the cryptographers including CFRG
The problem is that none if them did an impact analysis for this draft.
Yes of course, in isolation it is good to move away from SHA1.
On Tue, 30 Apr 2024, Philip Homburg wrote:
- FIPS
- PCI-DSS
- BSI
- OWASP
- SOC2
- PKI-industry & CAB/Forum
- TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF.
- All the cryptographers including CFRG
The problem is that none if them did an impact analysis for this draft.
I phrase it the other
The people arguing for adoption seem to have two major arguments:
1) we should punish zones that sign with old algorithms by making compliant
resolvers treat them as insecure
2) we should make it impossible for zones to sign or re-sign with old algorithms
#1 affects resolvers, in particular the r
Bob Harold writes:
> I support this.
Hi Bob,
Thanks for the support and the bugs. Inline below:
> It sounds like future updates will be separate RFC documents, so it seems odd
> to say
> 'this document' in 1.3. Perhaps "future documents" ? (I assume this text
> was just
> copied from the
S Moonesamy writes:
> I took a quick look at draft-hardaker-dnsop-must-not-ecc-gost-00.
> The Introduction Section states that the security of the ECC-GOST
> algorithm has been slowly diminishing over time as various forms of
> attacks have weakened its cryptographic underpinning. There isn't a
Paul Wouters writes:
> Perhaps Viktor can share his updated numbers with us.
Viktor's daily scanning numbers are host on our USC/ISI server at:
https://stats.dnssec-tools.org/#/?dnssec_param_tab=0
Click on "DNSSEC Parameter Trends" followed by "KSK algorithm", etc.
KSK usage (click on the "do
This cull-because-of-low usage thread incorrectly assumes that the DNS is flat
instead of a hierarchy. The last I saw, there are 14 TLDs who use RSASHA1.
Advancing this draft as-is means that all of the zones under those TLDs would
be completely wiped out as well. Or maybe that's what the WG wan
On 1 May 2024, at 00:42, Paul Hoffman wrote:
> This cull-because-of-low usage thread incorrectly assumes that the DNS is
> flat instead of a hierarchy. The last I saw, there are 14 TLDs who use
> RSASHA1. Advancing this draft as-is means that all of the zones under those
> TLDs would be comp
On Apr 30, 2024, at 18:42, Paul Hoffman wrote:
>
> This cull-because-of-low usage thread incorrectly assumes that the DNS is
> flat instead of a hierarchy. The last I saw, there are 14 TLDs who use
> RSASHA1. Advancing this draft as-is means that all of the zones under those
> TLDs would be c
On Apr 30, 2024, at 16:00, Paul Wouters wrote:
>
> On Apr 30, 2024, at 18:42, Paul Hoffman wrote:
>>
>> This cull-because-of-low usage thread incorrectly assumes that the DNS is
>> flat instead of a hierarchy. The last I saw, there are 14 TLDs who use
>> RSASHA1. Advancing this draft as-is m
Paul Hoffman writes:
> This cull-because-of-low usage thread incorrectly assumes that the DNS
> is flat instead of a hierarchy.
A few points:
1. I only pointed at data that people were asking for. I did not state
my personal opinion.
2. I published the drafts based on desires by people to hav
On Apr 30, 2024, at 16:20, Wes Hardaker wrote:
> 3. The whole discussion, IMHO, is side-stepping the real issue: if not
> now, then when? IE, do we never put something at MUST NOT? Is there a
> usage threshold? Is it "must be zero"? Is it "known to be broken and
> everyone must have a flag day
On Tue, 30 Apr 2024, Paul Hoffman wrote:
Is that something within the realm of ICANN? Perhaps the DNS Tech Day ?
You ask those questions sounding as if ICANN staff had not already done so.
Why not share the data if you have some? This is the list of TLDs affected:
apple. brand TLD
beats.
On Tue, 30 Apr 2024, Paul Hoffman wrote:
Until someone can show that a reduction in collision resistance can lead to a reduction in real-world
security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason
for this group to say to a zone operator who signed
If we go ahead with this these two sentences
Validating resolvers MUST treat
RRSIG records created from DNSKEY records using these algorithms as
insecure. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver MUST
>Their zone is already made insecure by a number of OS/DNS implementation
>combos. Perhaps someone with RIPE Atlas credits can run a check like the
>equivalent of "dig dnskey nic.kpn +dnssec" to see how many endusers
>already get insecure answers for this?
This reads as Redhat strong-arming the IE
26 matches
Mail list logo
