On 8/6/2025 18:19, Wes Hardaker wrote:
"StJohns, Michael"<[email protected]> writes:
Are the authors stil sure they want to move forward, and that the language
is clear on what they meant?
The authors have been discussing it and need to review the entire
thread. As a reminder authors are actually editors, not authors and as
such it's really up to the WG not just the editors.
I hope to get a change/path-forward proposal done shortly (but life got
in the way for me to get it done by today)
Hi Wes -
Let me try this using a somewhat different approach. E.g. writing what
I think you wanted, but in perhaps more pedantic words.
Initial effect:
The DNSSEC use of SHA1 and algorithms that depend on SHA1 is
DEPRECATED as of the publication of this document as a Standards
Track RFC. This means that SHA1 dependent algorithms SHOULD NOT be
used in the creation of any DNS resource records. Publishers of
DNSSEC records that currently use SHA1 or SHA1 dependent
algoritihms should make arrangements to transition away those
algorithms as quickly as possible. The current DNSSEC algorithms
affected are: <list of algorithm names and their alg numbers>
Future Effect:
The DNSSEC use of SHA1 and algorithms that depend on SHA1 is
PROHIBITED as of the <third? pick one> anniversary of the
publication of this document as a Standards Track RFC. This means
that SHA1 dependent algorithms MUST NOT be used in the creation of
any DNS resource records after this date and existing records should
be removed as they expire.
Client processing:
Validating resolvers MAY be configured to support one of three
models with respect to the receipt of DEPRECATED or PROHIBITED
records: Legacy, Deprecated or Strict.
* Legacy processing treats the deprecated records as fully
supported. In otherwords, no change from processing prior to
the deprecation date.
* Deprecated processing treats the deprecated records as if they
were unsupported, with the single exception that a DNSSEC
delegation into a zone that consists only of SHA1 dependent DS
records (e.g. no other delegations to the domain using non-SHA1
algorithms) is treated as if it were a secure delegation to an
insecure zone.
* Strict processing treats the deprecated records as if they were
unsupported. A zone delegation using only unsupported
algorithms is treated as Bogus per << ref>>.
Validating resolvers SHOULD use the "Deprecated" model after the
publication of this document and before the PROHIBITED milestone,
and SHOULD use "Prohibited" after the prohibited milestone.
Mikes commentary:
A valid delegation signature (e.g. SHA256EDSA) over an NSEC(3) record
that says that there is a secure delegation I believe results in a BOGUS
result for subordinate records only signed by unsupported algorithms?
As I read this, you want a soft landing for SHA1 which would turn a
Secure delegation into an Insecure delegation if only SHA1 algorithms
were uses?
Or am I far off in the weeds?
Later. Mike
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
