On 1/10/2024 10:20 PM, Martin Thomson wrote:
On Thu, Jan 11, 2024, at 15:45, Christian Huitema wrote:
Good for you. Not all implementations do that. It is hard for me to
blame them, because the 10 seconds recommendation is justified by for
"clients on the Internet", and delays larger than 1 or maybe 2 seconds
are quite rare on the "Earthian" Internet that we have today. Given that
complexity is the enemy of security, I certainly understand why some
implementations keep it simple.
I consider it necessary for reliability purposes. If you don't at least try to
account for RTT, you are skewing any window anti-replay window you have.
Yes, but the relation between delays and variance is rather complex. On
the current Internet, a good bit of delay variance comes from congestion
control protocols pushing ever more data until queues overflow -- but
better congestion control or using modern AQM in front of the bottleneck
can take care of that.
Keep in mind that a lot of these exchanges won't have had much data exchanged
on the connection at the time. So a lot of the variance from self-induced
congestion won't come into play. That's not to say that you won't be affected
by what others are doing or other active connections though. And of course,
your space networks have other more interesting factors pushing delays in all
directions.
Plus, how exactly does one test this kind of "variable delay" code?
Time is just another input to your program, right?
The more I think of it, the more I believe the solution may be some kind
of plug-in in the TLS implementation. Let the application that requires
the extra complexity deal with it, develop and test the adequate plug-in.
I don't think that there is much need for active code, just configuration.
Maybe I'm missing something though.
If an implementation does not want to deal with the extra complexity,
then having a way to plug in some extra code for a specific scenario
makes sense...
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
