Re: [TLS] Packet number encryption negotiation

> A first draft can be found here: > https://www.ietf.org/id/draft-pismenny-tls-dtls-plaintext-sequence-number-00.txt > > > > and the source is here: > https://github.com/BorisPis/draft-pismenny-tls-dtls-plaintext

Re: [TLS] Packet number encryption negotiation

2023年2月14日(火) 14:31 Christian Huitema : > > > 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 middl

Re: [TLS] Packet number encryption negotiation

Boris Pismenny 于2023年3月2日周四 18:43写道： > > On Tue, Feb 28, 2023 at 2:18 PM Lanlan Pan wrote: > >> Personally I think, the negotiation may cause the downgrade security >> risk, making PNE not actually work for privacy protection. >> The hardware acceleration can support both PNE and plaintext packe

Re: [TLS] Packet number encryption negotiation

On Tue, Feb 28, 2023 at 2:18 PM Lanlan Pan wrote: > Personally I think, the negotiation may cause the downgrade security risk, > making PNE not actually work for privacy protection. > The hardware acceleration can support both PNE and plaintext packet number. > Maybe we can consider assigning a n

Re: [TLS] Packet number encryption negotiation

Personally I think, the negotiation may cause the downgrade security risk, making PNE not actually work for privacy protection. The hardware acceleration can support both PNE and plaintext packet number. Maybe we can consider assigning a new port, just for plaintext packet number's QUIC/DTLS ? such

Re: [TLS] Packet number encryption negotiation

> > Next, I'll start working on a draft. > A first draft can be found here: https://www.ietf.org/id/draft-pismenny-tls-dtls-plaintext-sequence-number-00.txt and the source is here: https://github.com/BorisPis/draft-pismenny-tls-dtls-plaintext-sequence-number All inputs will be appreciated. _

Re: [TLS] Packet number encryption negotiation

On Tue, Feb 14, 2023 at 6:31 AM Christian Huitema 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 crucia

Re: [TLS] Packet number encryption negotiation

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) gap

Re: [TLS] Packet number encryption negotiation

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

Re: [TLS] Packet number encryption negotiation

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

Re: [TLS] Packet number encryption negotiation

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 p

Re: [TLS] Packet number encryption negotiation

On 2/13/2023 7:25 AM, Boris Pismenny wrote: On Mon, Feb 13, 2023 at 7:20 AM Christian Huitema > wrote: This issue, packet number encryption versus hardware acceleration, was discussed in quite some depth during the standardization process. The current de

Re: [TLS] Packet number encryption negotiation

On Mon, Feb 13, 2023 at 4:29 PM Watson Ladd wrote: > > > On Wed, Feb 8, 2023 at 10:16 AM Boris Pismenny > wrote: > > > > Hello, > > > > I work on NIC hardware acceleration for NVIDIA, and we are looking into > QUIC and DTLS1.3 acceleration. QUIC and DTLS employ packet number > encryption (PNE) w

Re: [TLS] Packet number encryption negotiation

On Wed, Feb 8, 2023 at 10:16 AM Boris Pismenny wrote: > > Hello, > > I work on NIC hardware acceleration for NVIDIA, and we are looking into QUIC and DTLS1.3 acceleration. QUIC and DTLS employ packet number encryption (PNE) which increases security. At the same time, PNE significantly encumbers ha

Re: [TLS] Packet number encryption negotiation

On Mon, Feb 13, 2023 at 7:20 AM Christian Huitema wrote: > This issue, packet number encryption versus hardware acceleration, was > discussed in quite some depth during the standardization process. The > current design was adopted with full knowledge that hardware > acceleration will require some

Re: [TLS] Packet number encryption negotiation

This issue, packet number encryption versus hardware acceleration, was discussed in quite some depth during the standardization process. The current design was adopted with full knowledge that hardware acceleration will require some harder work than if numbers were in clear text. Boris, you m

Re: [TLS] Packet number encryption negotiation

> On 10 Feb 2023, at 09.21, Boris Pismenny wrote: > > Thanks for the information. I didn't know it was possible to register custom > versions of QUIC/DTLS. Are there any examples of that? What would be the > process of proposing one? I cannot speak to DTLS, but QUIC version discussion is dis

Re: [TLS] Packet number encryption negotiation

Hi Mikkel. On Thu, Feb 9, 2023 at 8:21 PM Mikkel Fahnøe Jørgensen wrote: > QUIC does allow for creating a custom version of the protocol but it > should be registered with IANA. It is also possible to use unregistered > version numbers for test purposes in closed environments, but tis hardly >

Re: [TLS] Packet number encryption negotiation

QUIC does allow for creating a custom version of the protocol but it should be registered with IANA. It is also possible to use unregistered version numbers for test purposes in closed environments, but tis hardly the case for released hardware. Weakening the security of official protocol versi