[DNSOP] Re: PQ DNSSEC?

Hello all,

My name is on the draft, and I still think it is a good idea to be able 
to return only signatures that a resolver wants.

If I recall, the arguments against this was that a resolver or other 
caching intermediary may end up missing algorithms in cache that some 
downstream validator may want or need (basically what is in section 8 of 
the draft), as well as the thought that it would not help anything and 
is needless complication. Maybe the zeitgeist is different now and these 
arguments no longer seem as important?

Cheers,

--
Shane

On 2026-07-19 18:37, Sheth, Swapneel wrote:
>
> I am supportive of reviving algorithm negotiation draft 
> -https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-03 
> <https://secure-web.cisco.com/1ST79G3c1lLx7PRyhqhl4CSvZA1jqdEsLWmnQQL5Ia6uHCsnT3eEBrFchMALdvxWnFVn1lpabiDS8kT_yu4rojt1rondi6BQyalhrTd0GkyS8y0CWEpGlYor33flIIDdQvVfNXN0G51B7OwRyczZe2amvNmCJetmvbuAyxARdUXrN_mKyGhJHWorC-5F8QXrYCZ0dFofxJ0SBABiv3Ib6raAVwrMxP0IaP2CMmQiUibDTK_jtQH7YHEpx-NeBM-l4DEpd-XWzplAi4xKU22gkK7sGspOUzX0bKoRJJnTDMMiESsKFHDnpYDLgHTtJTzr0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-huque-dnssec-alg-nego-03>, 
> in anticipation of supporting multiple PQ DNSSEC algorithms as 
> suggested in 
> https://datatracker.ietf.org/doc/draft-sheth-pqc-dnssec-strategy/. 
> Happy to contribute/review as needed.
>
> -Swapneel
>
> *From: *Shumon Huque <[email protected]>
> *Date: *Sunday, July 19, 2026 at 3:07 PM
> *To: *Bas Westerbaan <[email protected]>
> *Cc: *"[email protected]" <[email protected]>
> *Subject: *[EXTERNAL] [DNSOP] Re: PQ DNSSEC?
>
> *Caution:*This email originated from outside the organization. Do not 
> click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> On Sun, Jul 19, 2026 at 1:16 PM Bas Westerbaan 
> <[email protected]> wrote:
>
>     Hey all,
>
>     With various new regulatory timelines for valuable systems to be
>     PQ by 2031, we're getting questions what we're looking at with
>     DNSSEC. Looking from afar (and please forgive me my ignorance) it
>     doesn't look good. There's a lot of academic investigation and
>     experimentation (great), IETF side-meetings, but no thrust or
>     plans to any deployment; no adopted drafts or BoFs.
>
> I agree that it's probably time to get PQ DNSSEC work officially into 
> an IETF working group's charter.
>
>     If we care for PQ DNSSEC by 2031, what would be the most practical
>     path? We can't be too ambitious.
>
>     So what are we looking at? The only practical [1] signature scheme
>     available on this timeframe is ML-DSA-44 with 2,420 byte
>     signatures and 1,322 byte public keys. We can't have
>     authoritatives include these by default: it'll break clients that
>     can't fall back to TCP, or are buggy in other ways.
>
>     Instead I suppose we have the client signal if it supports
>     ML-DSA-44 [2], and only in that case return those large RRSIGs.
>     This allows for gradual demployment, and only impacts those that
>     care for PQ DNSSEC. While we wait for the root to sign with
>     ML-DSA-44, resolver can anchor on TLDs ML-DSA-44 keys.
>
> Selectively returning PQC signatures was in fact one of the use cases 
> envisioned by that draft. It could be revived if there is renewed 
> interest. (Link: 
> https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-03 
> <https://secure-web.cisco.com/1ST79G3c1lLx7PRyhqhl4CSvZA1jqdEsLWmnQQL5Ia6uHCsnT3eEBrFchMALdvxWnFVn1lpabiDS8kT_yu4rojt1rondi6BQyalhrTd0GkyS8y0CWEpGlYor33flIIDdQvVfNXN0G51B7OwRyczZe2amvNmCJetmvbuAyxARdUXrN_mKyGhJHWorC-5F8QXrYCZ0dFofxJ0SBABiv3Ib6raAVwrMxP0IaP2CMmQiUibDTK_jtQH7YHEpx-NeBM-l4DEpd-XWzplAi4xKU22gkK7sGspOUzX0bKoRJJnTDMMiESsKFHDnpYDLgHTtJTzr0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-huque-dnssec-alg-nego-03> 
> )
>
> Shumon.
>

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]