On Mon, Feb 23, 2026 at 03:18:54PM +0100, Bas Westerbaan wrote:
> Given store-now/decrypt-later, we should update our recommendations.
>
> I've drafted a quick I-D which we could work on. I couldn't help myself to
> have my preferred outcome as a stub, but it's just a starting point.
>
> https://datatracker.ietf.org/doc/draft-westerbaan-tls-keyshare-recommendations/
>
> Now, to actually make progress I see the following questions (if we desire
> to work on this):
>
> 1. Do we want to keep "Y" for quantum vulnerable algorithms? This is
> probably an easy one.
>
> 2. Bit harder: do we discourage ("D") or stay neutral ("N") on quantum
> vulnerable algorithms? Recall that "N" is defined as
>
> Indicates that the item has not been evaluated by the IETF and that the
> IETF has made no statement about the suitability of the associated
> mechanism. This does not necessarily mean that the mechanism is flawed,
> only that no consensus exists. The IETF might have consensus to leave an
> item marked as "N" on the basis of the item having limited applicability or
> usage constraints.
>
> Personally I prefer D, but I can live with N if we add a comment.
Even "N" seems rather a Chicken Little reaction to the possibility that
some day a CRQC might appear that might be able to break a handful of
high-interest keys a year for a significant cost. While out of an
abundance of caution it seems prudent to update X25519MLKEM768 to "Y", I
don't presently see good cause to change the status of x25519, secp256r1,
ffdhe2048 or stronger variants thereof to either "N" or "D".
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
