2023年2月14日(火) 14:31 Christian Huitema <huit...@huitema.net>: > > > 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. >
+1 to this. I would hope we could choose NICs that support crypto offloading of QUIC traffic unchanged, so that we could offload encryption of packets that we ship over the Internet, rather than just intra-datacenter traffic. Many protocols, if not all, have their own complexity when you offload crypto. To my knowledge, when retransmitting a TLS-encrypted TCP packet, you have to reencrypted bytes then throw them away just to calculate the AEAD tag, because the byte boundaries of TCP packets do not match that of TLS records. In that respect, QUIC and DTLS/1.3 are simpler than TLS over TCP. I get that any complexity is a cost, but I wonder how costly it would be to actually support crypto offload with PNE compared to without. Is that so different that it stops people from buying NICs with crypto-offload support? > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
