> On Aug 3, 2025, at 12:38, Michael StJohns wrote:
>
>
> Hi - apologies, I wasn't paying attention as I thought this would have been a
> simple and clean document.
>
> Mukund's note made me take a quick look a this. I think the document is
> incomplete or ambiguous.
>
> Please add a re
ns (DNSOP) WG
of the IETF.
Title: Domain Control Validation using DNS
Authors: Shivan Sahib
Shumon Huque
Paul Wouters
Erik Nygren
Tim Wicinski
Name: draft-ietf-dnsop-domain-verification-techniques-09.txt
Pages: 18
Dates: 2025-
On Tue, 15 Jul 2025, Philip Homburg wrote:
This is not expensive. It is still cheap with the limit or 2 or 3
failures allowed. I mean, compare this to do doing DoH to all auth
servers, this crypto operation amounts to nothing.
It is exactly this limit that causes trouble for some validator sof
On Tue, 15 Jul 2025, Philip Homburg wrote:
Colliding with what? Just the other keys it is writing at the time?
On a multi-signer setup it can collide and its not your own other keys
writing at the same time.
Looking at it from a validator perspective, collisions can affect validation
in two
Paul Wouters has entered the following ballot position for
charter-ietf-dnsop-04-01: Block
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with
On Jul 9, 2025, at 04:03, Mark Andrews wrote:
>
>
>
> BIND has had code to prevent collisions in single signer scenarios since the
> very beginning. It also has the ability to specify key tag ranges that
> multi-signers can use to prevent key tag collisions between independent
> key generato
On Jul 8, 2025, at 03:27, Libor Peltan
wrote:
>
>
> I think that having DNSSEC non-BOGUS 100% of the time is critical at least
> for important zones (like TLDs).
> AFAIK the current state is that the _specification_ allows the atuhoritatives
> to publish DNSKEYs with any number of konflictin
On Mon, 7 Jul 2025, Willem Toorop wrote:
This draft came from the Poisonlicious hackathon project at the
Netnod/DNS-OARC/RIPE-NCC DNS Hackathon that was held this spring in Stockholm.
The -00 version was
posted by Stephane just after the hackathon, and this new version has (some) of
the feedb
“ These complications can be avoided by assuming Classic DNS over TCP is the only form of Classic DNS that new protocols need to accommodate.”This is not how protocols using DNS work. You can’t say “new” protocols must use only a specific flavour of DNS transport as it’s mostly not up to the new pr
Paul Wouters has entered the following ballot position for
charter-ietf-dnsop-04-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along
> On Jun 11, 2025, at 06:29, John Levine wrote:
>
> I don't think any of this is wrong per se, but I also think it is vast
> overkill, the threats are
> largely if not entirely hypothetical, and this will add a lot of complication
> that distracts from the
> goal of this draft, to provide a co
> On Jun 6, 2025, at 15:02, Erik Nygren wrote:
>
>
> Following this discussion, I've taken a pass at proposing some updates to
> clarify the "purpose"
> of domain validation (as suggested by Ben in PR #160 although I started with
> a new take on it)
> as well as to clarify the difference bet
On Jun 1, 2025, at 12:54, Jim Reid wrote:
>
>
>
>> Until that happens, dnsop will pretty much be the only place at the IETF for
>> doing maintenance, updates and extensions to the DNS protocol. [Apart from
>> deleg of course.]
Good thing you said “pretty much”, as early experiments and disc
On Fri, 30 May 2025, John R Levine wrote:
On Fri, 30 May 2025, Joe Abley wrote:
I have definitely received automated email telling me that my domain is
about to be detached from a particular service because the TXT record had
been removed. Other TXT records I have been removed in the interes
On Thu, May 29, 2025 at 3:03 PM Wes Hardaker wrote:
> Paul Wouters via Datatracker writes:
>
> Hi Paul,
>
> > In the Operational Considerations, one could add a sentence about the
> > difference of not supporting SHA-1 versus having a system that does not
> support
&
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-rfc8624-bis-11: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-must-not-sha1-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On Wed, 21 May 2025, Ben Schwartz wrote:
[ speaking only as individual DNS enthousiast ]
> From what I understand about the draft so far, it seems that this would be a
> vendor-neutral convergence point to do these connectivity checks against.
No, that is not the idea. The idea is that when p
On Wed, 21 May 2025, Wes Hardaker wrote:
Paul Wouters via Datatracker writes:
Zone owners currently making use of SHA-1 based algorithms should
immediately switch to algorithms
I would use "should immediately rollover to algorithms" to avoid the illusion
some ine
On Wed, 21 May 2025, Wes Hardaker wrote:
I have some questions I would like to see a short discussion on before
balloting Yes
The columns added to the IANA "DNS Security Algorithm Numbers"
[DNSKEY-IANA]
While doing IANA updates, can this document perhaps also update the name "DNS
S
On Wed, 21 May 2025, Paul Wouters via Datatracker wrote:
Subject: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-must-not-sha1-07:
(with DISCUSS and COMMENT)
Following up on myself:
I very much plan to say Yes, after one error is fixed in the document:
This doc
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-must-not-sha1-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-rfc8624-bis-10: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On Mon, 12 May 2025, Ben Schwartz wrote:
I believe the current draft text in the datatracker agrees with me. For
example, draft-07 Section 4.3 says
> Some Application Service Providers currently require the Validation Record to
remain in the zone indefinitely for periodic revalidation purpos
On Mon, 12 May 2025, Paul Hoffman wrote:
[ speaking only as co-author of draft-ietf-dnsop-domain-verification-techniques
]
Reading this thread and the GitHub issue that spawned it, it is clear that even
the co-authors of draft-ietf-dnsop-domain-verification-techniques do not agree
on how to
[ still speaking as individual dns enthousiast ]I removed the text where we have disagreement where I don’t think we are progressing / converging. I just have a few comments to add to some of your responses.On May 12, 2025, at 03:12, tirumal reddy wrote:If you could elaborate further on the nature
On Wed, 7 May 2025, 张淑涵 wrote:
It’s my honor to share our recently submitted draft titled “Handling
Unvalidated Data during DNSSEC Troubleshooting”
(draft-zhang-dnsop-dnssec-unvalidated-data-00).
Draft link:
https://datatracker.ietf.org/doc/draft-zhang-dnsop-dnssec-unvalidated-data/
Given th
On Tue, 6 May 2025, Ben Schwartz wrote:
From: Erik Nygren
> 1) Is DCV just point-in-time validation of control or does the contin
On Wed, 7 May 2025, tirumal reddy wrote:
I disagree. An ENUM can be handled by browsers to display text in the
locality of the user. This can just fling up a free text English
message, that you expect browsers to validate for potential harm
before displaying to the user.
On Tue, 6 May 2025, tirumal reddy wrote:
I am not sure why a JSON object for a browser would produce a more
"meaingful error message" than one that is possible with RFC 8914 ?
It is designed for clients to interpret and render meaningful, user-friendly
messages. This approach has a
On Mon, 5 May 2025, Stephane Bortzmeyer wrote:
On Mon, May 05, 2025 at 12:49:28PM +,
Eric Vyncke (evyncke) wrote
a message of 200 lines which said:
* Are full-text explanations better or worse from UX or security
point of view ?
Indeed, it was mentioned and I am quite surprise
On Wed, 30 Apr 2025, Mark Nottingham wrote:
[ speaking as individual ]
If browsers only display proper error messages when using a few well
known DNS servers, than I think that is apparent.
I'd agree, *if* being able to show DNS filtering / censorship error messages
can be argued to be a sig
On Wed, 30 Apr 2025, Mark Nottingham wrote:
[ speaking as individual ]
Now, we could talk about defaults and how that inertia tends to empower a few
operators, but how this mechanism makes that situation worse isn't readily
apparent.
If browsers only display proper error messages when using
I reviewed draft-bortzmeyer-dnsop-poisonlicious-00 as I have an interest in
being able
to link DNS caches together.
The protocol is still a bit underspecified, and I have lots of concerns here.
For one,
it talks about successfull DNS resolution, where I think perhaps it should talk
about
"whe
On Mar 21, 2025, at 15:15, Loganaden Velvindron wrote:
[ speaking as individual ]
>
> Hi All,
>
> Based on this experimental branch of PowerDNS:
> https://github.com/nils-wisiol/dns-falcon/commit/3e0861cd2942f6a0ca938cf6a20104e450835fae
>
> Would it be possible to request codepoints for DNS
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-must-not-ecc-gost-03: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-generalized-notify-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On Feb 28, 2025, at 13:22, Peter Thomassen
wrote:
>
> Hi Paul,
>
> Thank you for your suggestions, all of which are incorporated one way or
> another. Details below.
Looks good, one minor suggestion:
>
> NEW
> This document generalizes and extends the use of DNS NOTIFY (RFC
> 1996) bey
On Fri, Feb 28, 2025 at 10:19 AM Peter Thomassen wrote:
> Hi Paul,
>
> Thank you very much for your thorough review!
>
Thanks for the detailed response as well!
As for SVCB, the WG has discussed this on various occasions and rejected
> the idea. [...]
Thanks for the pointers to those discussi
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-generalized-notify-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-compact-denial-of-existence-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
> On Jan 24, 2025, at 13:44, Frederico A C Neves wrote:
>
> Dear David,
>
>> On Fri, Jan 24, 2025 at 06:23:36PM +, David Dong via RT wrote:
>> Dear Frederico A C Neves, Paul Wouters (cc: dnsop wg),
>>
>> As the designated experts for the Underscored an
On Thu, 16 Jan 2025, Philip Homburg wrote:
b) Is step 3b (a short RFC that points to a specific version of an
expired draft) acceptable? If not, what would be needed, given that
the original author didn't want to progress their document?
When it comes to using a cryptographic algorithm in DNSS
On Jan 13, 2025, at 16:38, Warren Kumari wrote:On Tue, Jan 07, 2025 at 1:44 PM, Paul Wouters <p...@nohats.ca> wrote:On Tue, 7 Jan 2025, Paul Hoffman wrote: draft-ietf-dnsop-must-not-sha1 This document is fine as-is, with one minor nit: Appendix C should be marked for removal by the RFC
On Tue, 7 Jan 2025, Paul Hoffman wrote:
draft-ietf-dnsop-must-not-sha1
This document is fine as-is, with one minor nit: Appendix C should be marked
for removal by the RFC Editor, similar to Appendix B.
I think the Title and Abstract are broken. It currently states:
Remove SHA-1 from
On Sun, 17 Nov 2024, Philip Homburg wrote:
[indeed a bit offtopic]
Use OPENSSL_CONF environment to point to conf file containing:
.include = /etc/ssl/openssl.cnf
[evp_properties]
rh-allow-sha1-signatures = yes
That is all needed to get SHA1 verification in DNSSEC back, without
accepting SHA1
On Mon, 4 Nov 2024, Roy Arends wrote:
While I thought this was an original idea when I heard it during the DELEG discussions,
it has been proposed by both Peter van dijk (see below) and Paul Wouters independently
(I've seen a draft for it, named "ds uplifting", though not in
On Thu, 31 Oct 2024, Ben Schwartz wrote:
This is why I wanted to raise this topic. I don't believe we have thought very
carefully about when DCV is actually safe
or appropriate, and I don't think we should be recommending a mechanism without
consensus and guidance for what this
mechanism achi
On Thu, 31 Oct 2024, Tim Wicinski wrote:
draft-ietf-dnsop-domain-verification-techniques-06.txt
I'll review it today and I now understand your reasoning a lot better.
I reviewd the text.
It makes assumptions on knowing what are valid and invalid use cases of
domain ownership verificatio
On Oct 25, 2024, at 09:25, Ben Schwartz
wrote:
>
>
> Yes. I would like to see deeper consideration of what we are trying to prove
> to whom, to help the reader decide how best to do it.
Please provide text as it is unclear to the authors what you feel is missing
for the reader.
Paul__
Ondřej Surý wrote:
I am quite confused as SHA-512 is not standardized for use in DS records:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
I believe this change should be rejected until (and if) SHA-512 is standardized
to use in DS records.
Indeed it should be rejected, bu
ed value.
>
> If you think this analysis is wrong, please explain the attack
> which is prevented by client-side DNSSEC validation, remembering
> that it can only be done reliably when the client already is
> using a TRR.
>
> -Ekr
>
>
> [0] DNSSEC validation at the recursive
On Mon, 7 Oct 2024, Benno Overeinder wrote:
* draft-ietf-dnsop-delegation-only
- In 2021, there was a poll on the DNSOP WG mailing list to drop the draft.
Rough consensus to drop the document was established on 24 August 2021.
- We marked the draft as Dead in the datatracker.
Still sad abou
On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
>>
>> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>>
>>> This is explicitly prohibited rfc9460 as it would provide linkability.
>
On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
>>> partitioned for each local network, or flushed on network changes, to
>>> prevent a local adve
[kind of off-topic here, and also speaking as just an individual]
On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote:
>
> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
> wrote:
>
>>
>> On 10/4/24 19:30, Paul Wouters wrote:
>> > Which makes me wonder if it m
>
> On Oct 4, 2024, at 15:28, Russ Housley wrote:
>
> This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the DSNOP
> WG to adopt it.
The document seems like a theoretical ideal of an algorithm life cycle. There
have been many kind of considerations in play that have determine
t; --
> *From:* Eric Rescorla
> *Sent:* Friday, October 4, 2024 8:07 AM
> *To:* Salz, Rich
> *Cc:* Arnaud Taddei ; Ben Schwartz <
> bem...@meta.com>; Paul Vixie ; Paul Wouters <
> paul.wout...@aiven.io>; draft-ietf-tls-svcb-ech.auth...@i
[drifting off topic]
> On Oct 2, 2024, at 00:10, Paul Vixie
> wrote:
>
>
>
>
> i would not. much of the world now relies upon inauthentic dns responses for
> defense against bad actors.
that's a limitation of RPZ. Years ago I proposed to move the Answer to the
Authority section so you c
trusted DNS servers.
As for the RFC1034 reference, Warren suggested to maybe use: "DNS (see
RFC1034, BCP219)" (where BCP219 is the latest DNS Terminology doc).
Paul
--
> *From:* Salz, Rich
> *Sent:* Monday, September 30, 2024 1:29 PM
> *To:* Ben S
Hi,
I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well
summarized by the Document
Shepherd:
Please note that the text in this I-D was initially developed in the DNSOP WG,
went through IETF LC, and IESG review. The result of the IESG review was to take
the text in this I-D
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-rfc8109bis-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
On Jul 31, 2024, at 09:29, Petr Špaček wrote:
>
> On 30. 07. 24 9:41, libor.peltan wrote:
>> 2) I would still vote for allowing one keytag collision per zone (not per
>> whole chain-of-trust, like Bind does) instead of none. This would be more
>> comfortable for many older/simpler signers and
On Mon, 29 Jul 2024, Jim Reid via Datatracker wrote:
Proposed changes below are part of:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/146
draft-ietf-dnsop-domain-verification-techniques-05
Reviewer: Jim Reid
Review result: Not Ready
I am disappoi
> On Jul 26, 2024, at 16:08, Mark Andrews wrote:
>
>
> Even if we where to go with one failure is allowed we still need to
> write down the new rules and there will be complaints that we are
> retrospectively changing the rules. This is grand fathering in the
> old rules for the old algorithm
On Jul 26, 2024, at 21:48, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC7901,
> "CHAIN Query Requests in DNS".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8053
>
>
On Jul 25, 2024, at 17:54, Shumon Huque wrote:
>
>
> The actual proposal is initially only "new" DNSKEY algorithms will have the
> no colliding key tags requirement.
Better than a flag day. But still seems to introduce new communication
requirements on the multi signer deployments which woul
On Jul 25, 2024, at 17:50, Yorgos Thessalonikefs wrote:
>
> But I do want to see a flag day for validators (either failing on the first
> or second collision) for all algorithms.
No flag days. DNS on devices shouldn’t just start failing for no good reason
other than running software from befor
On Jul 23, 2024, at 12:09, Paul Vixie wrote:
>
>
> Making TLS 1.2 available as a fallback is vital. Many secure private edge
> networks will never allow TLS 1.3 because of ECH.
You can do TLS 1.3 without ECH ?
Making a weaker version of TLS mandatory would be unwise, unless it’s to give
mor
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-10: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
On Fri, 5 Jul 2024, Petr Špaček wrote:
My interpretation is that it means "if you don't know any better use
1400", but RECOMMENDED is more concise.
I read RECOMMENDED as “don’t think you are smarter than the collective
IETF”. Or maybe that’s just how I hope people will read it.
I think y
On Jul 5, 2024, at 08:14, Petr Špaček wrote:
>
> I understand why Paul Vixie does not like 1400 set in stone.
>
> Having said that I think it's in fact _not_ set in stone because the text
> says RECOMMENDED.
>
> My interpretation is that it means "if you don't know any better use 1400",
> bu
On Tue, 25 Jun 2024, Warren Kumari wrote:
This errata is correct.
Doh! Yes, it is…
Paul, would you mind being the one to mark it as Verified? I'm an author, and
while I don't really
see a much conflict of interest for an AD to mark an errata as verified, it's
probably cleaner if
some
This errata is correct.
Paul
Sent using a virtual keyboard on a phone
> On Jun 21, 2024, at 17:47, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC7344,
> "Automating DNSSEC Delegation Trust Maintenance".
>
> --
> You
On Wed, 19 Jun 2024, Tim Wicinski wrote:
On Wed, Jun 19, 2024 at 2:49 PM Paul Vixie
wrote:
This document makes the argument that because of how things work at the
moment, we should limit our aspirations.
I completely disagree.
I agree with Paul. We deserve nice things - we
On Tue, Jun 18, 2024 at 2:01 PM Wessels, Duane wrote:
>
>
> > On Jun 18, 2024, at 10:49 AM, Paul Hoffman
> wrote:
> >
> > Responding to one bit of Duane's response.
> >
> > On Jun 18, 2024, at 10:40, Wessels, Duane 40verisign@dmarc.ietf.org> wrote:
> >
> >>> What should an authoritative nam
On Tue, Jun 18, 2024 at 1:40 PM Wessels, Duane
wrote:
> Hi Paul, thanks for the review. Comments inline…
>
>
>
> > On Jun 17, 2024, at 4:23 PM, Paul Wouters via Datatracker <
>
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dnssec-bootstrapping-10: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
On Sun, 19 May 2024, Steve Crocker wrote:
[speaking as individual only]
In my view, an algorithm moves through seven phases during its lifecycle.
1. Experimental – defined and included in the IANA registry
2. Adopted – begin inclusion in validation suite
3. Available – ok to use for signing
4
On Mon, 6 May 2024, Petr Špaček wrote:
R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200].
Operational impact of this recommendation is unclear.
Why? Because clients belong to several sets:
- One set clients cannot receive fragmented answers,
Good because it has been proven to
On Fri, 17 May 2024, Peter Thomassen wrote:
Proposed text:
# Abstract
OLD
This document deprecates the DS enrollment methods described in
Section 3 of RFC 8078 in favor of Section 4 of this document, and
also updates RFC 7344.
NEW
This document establishes the DS enrollment method
On Wed, 15 May 2024, Peter Thomassen wrote:
[ I know this message predates the telechat, but I had no time to process
this before the telechat ]
[ cut everywhere where we agreed ]
I have a few items to discuss and some comments. I'm leaving out the
discussion
of _signal as a name, as this
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dnssec-bootstrapping-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
On May 10, 2024, at 05:36, jab...@strandkip.nl wrote:
>
> I'm interested in where this guidance comes from.
>
> RFC 2782 to me is the grandfather of underscore labels, and it pretty much
> goes out of its way to encourage a hierarchy of underscore labels to anchor
> SRV records under, e.g. unde
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
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 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 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
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
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 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
___
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
On Mon, 29 Apr 2024, Paul Hoffman wrote:
If the purpose of deprecating validation that involves SHA-1 is the decision by
RedHat to make that entire section of the DNS insecure, the documents should
say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual
useful attacks on
On Mon, 29 Apr 2024, Philip Homburg wrote:
As far as I know there is no second pre-image attack on SHA1, and there
will not be one in the foreseeable future.
Correct.
So if we deprecate SHA1 for validators, and assuming validators will follow
this advice, and some platforms already stopped v
On Apr 27, 2024, at 20:39, Tim Wicinski wrote:
>
> M
>
>
> This starts a Call for Adoption for:
> draft-hardaker-dnsop-rfc8624-bis
> draft-hardaker-dnsop-must-not-sha1
> draft-hardaker-dnsop-must-not-ecc-gost
I support adoption for all three drafts. Willing to help with text and w
On Sat, 20 Apr 2024, Peter Thomassen wrote:
The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.
John proposed "_dnssec-signal" elsewhere in this thread.
The authors would like to note that adding "_dnssec-" eats up 8 more bytes,
increasin
ust a ping on this; thank you.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
>> On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote:
>> Hi Paul,
>>
>>> On 4/12/24 22:36, Paul Wouters wrote:
>>> However, I would urge the au
On Fri, 12 Apr 2024, David Dong via RT wrote:
Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG),
As the designated experts for the Underscored and Globally Scoped DNS Node
Names registry, can you review the proposed registration in
draft-ietf-dnsop-dnssec-bootstrapping-08 for us
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
1 - 100 of 993 matches
Mail list logo
