>
>
>> 2. Bit harder: do we discourage ("D") or stay neutral ("N") on quantum
>> vulnerable algorithms? Recall that "N" is defined as
>>
>> Do you expect implementations to actually follow this soon? That is, remove
>> it from their default? At least D implies to me that it should be disabled
>> by default. And I don't think we're ready for that.
>>
>>
>> Getting endpoints to support (and prefer) hybrid key exchange is a big
>> win for practical security and there's no reason not to do it as soon as
>> possible.
>>
>> Getting endpoints to remove their non-PQ support barely moves the needle
>> for security and will take a very long time.
>>
> Not to mention would cause a huge amount of breakage.
>
I am under no illusion that we can disable quantum vulnerable key
agreements anytime soon. "D" doesn't imply this:
Indicates that the item is discouraged. This marking could be
used to identify mechanisms that might result in problems if they
are used, such as a weak cryptographic algorithm or a mechanism
that might cause interoperability problems in deployment. When
marking a registry entry as “D”, either the References or the
Comments Column MUST include sufficient information to determine
why the marking has been applied. Implementers and users SHOULD
consult the linked references associated with the item to
determine the conditions under which the item SHOULD NOT or MUST
NOT be used.
Now, the current hints merely hints about keeping support for it and the
risks there, but that can be made more explicit. (Even if we go for "N"
instead of "D" just now.)
> Marking algorithms as "D" has little effect as long as registering new
> PQ-vulnerable "N" algorithms is just "Specification required".
The designated experts have agency.
> Also, you may have missed arbitrary_explicit_prime_curves and
> arbitrary_explicit_char2_curves?
Oops, yes, thanks.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
