I've never viewed PNE as a security measure, but instead as an anti-ossification and a privacy measure. 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.
On Tue, Feb 14, 2023 at 3:58 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Mon, Feb 13, 2023 at 06:13:36PM -0800, Christian Huitema wrote: > > > The process for any proposal is to submit a draft to the relevant > > working group. I have no idea whether you will find a better reception > > in QUIC or in TLS. Your proposal amounts to lowering security in order > > to improve performance. The working groups may very well find that this > > is not a good idea. > > That said, we do want TLS and/or QUIC to perform sufficiently well to be > used in high-performance network applications, better that they be used, > rather than cleartext. So if the tradeoff is reasonable (solid > performance gain at marginal security cost), it should at least be > considered seriously. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
