On 2/13/2023 7:57 PM, Viktor Dukhovni wrote:
On Tue, Feb 14, 2023 at 04:22:48PM +1300, Marten Seemann wrote:
It hides certain bits of the header, as well as the packet number,
from an on-path observer. This is crucial to prevent middleboxes from
being "helpful" and acting upon (observed) gaps in packet numbers. As
such, it's hard to define what a reasonable tradeoff would be. Giving
up on an anti-ossification measure always seems fine at first, until
at some point it isn't any more.
If the proposed feature is negotiated via a default-off extension, and
used in high-speed internal datacentre networks, then its use is at the
internal discretion of the datacentre network designers. Presumably, in
such networks middleboxes of the sort you mention are a no-go just on
performance grounds.
Yes, especially if not on by default, the feature is liable to run into
barriers on networks with random middlebox crud. Is sufficient reason
to preclude well-motivated negotiated use elsewhere?
Cue the "visibility" discussion... The usual argument against lowering
protections "in a controlled environment" is that, in practice, once an
extension is defined, there could be massive pressure to use it outside
of the purported environment.
Personally, if I was engaged in a hardware acceleration project, I would
try hard to make the hardware work on an unchanged spec. I don't think
that's impossible, once you look at the spec closely.
RFC 9001 says that the header encryption material applied to the first
byte of the header and to the packet number is obtained by encrypting a
16 byte sample of the encrypted payload. From RFC 9001: "The sample of
ciphertext is taken starting from an offset of 4 bytes after the start
of the Packet Number field." To obtain these 16 bytes, the encryption
hardware has to obtain at most the first 32 bytes of the encrypted
payload before applying the header protection, and forwarding the header
and these 32 bytes. Yes, this is harder than not doing it at all. And
yes, that requires maybe 40 or 50 bytes of latency. But it could
certainly be done.
-- Christian Huitema
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
