On Tue, Apr 08, 2025 at 04:48:12PM +0000, Salz, Rich wrote:
> Is the second paragraph of Sec 4 not sufficient? It says “If deployment
> considerations are a concern, the protocol MAY specify TLS 1.2 as an
> additional, non-default option.”
That wording alone encourages non-interop: One implementation that does
not think about the issue will simply use some TLS 1.3-only stack, and
then it will not be interoperable with another implementation in which
it is not possible to support TLS 1.3 (e.g.: because it's non-upgradeable
firmware,
only the app-software is/can-be newer).
For all the cases, where not all communication partners can support TLS 1.3,
the wording of RFC9325 is already perfect. And my suggested text for your
draft was trying to restate that. Except that we probably should add requring
RFC9325 for new protocols in that case too.
But maybe break the suggestions into two parts:
a) Currently, the draft overstates what it can prove: we do not know whether
TLS 1.3 is (universally) in widespread use. We can only determine this for
some implementation wide rather limited, but utilization wise very significant
subseet of TLS usage: protocols for browsers on the Internet. See example F5
paper from S. I think we should be crisper about that limited, but important
insight in the draft. I also think we will never know a lot more about that
"dark usage" of TLS (or for that matter a lot of that "dark usage" of our
protocols).
b) The suggested solutions to the visible vs. non-visible use of TLS do
not only need to be IMHO differrent because of the well understood problems
of inagile software/firmware in the non-visible part, but also because
of the difference of visibility.
For example, i think it would make sense to think about a simple timeout
based requirement against MUST support TLS1.3 for the dark part of usage,
for example 10 years after announcement of TLS1.3 - which would be 2028.
But obviously now that it's already 2025, its a bit late for that given how
the purpose of such a timed requirement would be to have some good amount of
time to let that RFC trickle through those slow industries where it applies.
Also, the fact that PQ has been around the corner has given me pause of
pushing for something like that for pre-quantum versions/profile of TLS.
Alas, i have no good enough understanding about PQ crypto to have a strong
opinion if or whether we could do such a timed requirement for TLS with PQ
at some point in time - beyond the so-far mentioned firmware issues, PQ
has hardware issues in IoT: A lot of IOT HW seem to have jumped on EC for
faster processing, and its unclear to me, how constrained HW will best become
PQ anyhow...
Aka: We can still think of making a timed requirement for TLS 1.3 and ignore
PQ (unfortunately) for dark usage of TLS, but obviously it would still have to
be
a long enough period of time to make the timed announcement useful.
Not sure if less than 10 years from announcement makes sense. *sigh*
Cheers
Toerless
_______________________________________________
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
