On Tue, Feb 14, 2023 at 6:31 AM Christian Huitema <[email protected]> wrote:
> > > 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. > > > I'm concerned that without such an option negotiated, we will be left with plaintext, or proprietary protocols for an important group of users, this doesn't mean hardware won't support, but it implies that some users will be stuck with less attractive options. Initially we examined DTLS1.3 and QUIC encryption acceleration for various use cases of high speed NICs, we found that a proper implementation which includes PNE has unacceptable overhead for high performance computing and similar use-cases that care a lot about latency. Solving this may open the way to deploy these protocols in places where there was only cleartext before. Next, I'll start working on a draft.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
