Hi Mikkel.

On Thu, Feb 9, 2023 at 8:21 PM Mikkel Fahnøe Jørgensen <mikke...@gmail.com>
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
> the case for released hardware.
> Weakening the security of official protocol versions through negotiation
> is likely not a good idea.
>

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?

In any case, it seems a bit extreme to create a custom/new version just to
add an option to negotiate slightly different header formatting. For
example, DTLS1.2 connection IDs, which are a far more drastic change in my
opinion, extend the DTLS header format without a new version.


>
> As to latency of hardware encryption:
>
> I’m not sure what unique pipeline stage means, but clearly some special
> attention is required for the header.
>

By 'unique pipeline stage', I mean to describe a dedicated piece of logic
in silicon dedicated for PNE. Hardware typically consists of a sequence of
logical stages manipulating data in sequence. Dedicated logic in silicon
costs money, and adds some latency.

Assuming we limit the discussion to AES encryption with block size 64, PNE
> works by sampling somewhere within the first AES block.
> We can assume there is enough data to sample because otherwise the packet
> is invalid so any random padding will do.
>
> You can precompute the AES encryption of the first block by encrypting
> zeroes so you have that encryption data before the packet data arrives -
> you should do that anyway
> for maximum throughput unless you are seriously constrained for memory.
>

This optimization improves things, but we've taken that into consideration
and the argument still holds. Putting dedicated hardware for header
protection exclusively is a tradeoff between performance and cost vs.
security, and  arguably important tradeoffs should be negotiable.


> Potentially you can also precompute the packet number length and even the
> packet number itself, at least optimistically.
> Once the data arrives, you can immediately retrieve the plain text data
> segment of the first block - and sample the data needed for PNE encryption
> without delaying the encryption pipeline.
> Now you have the AES block and the clear text mask data, and you just need
> to XOR onto the packet being encrypted. You may need to double encrypt the
> packet number : both with the mask
> and with its AES block at its own location such that you can XOR it into
> place once the encryption stage signals the block is available. This will
> undo that packet number encryption by the
> encryption stage and apply the packet number encryption as intended.
>
> On caveat is that I do not remember how this affects the signature at the
> end of the packet, but I assume it does not include the encrypted version
> of the packet number, otherwise
> that would complicate things.
>
> This will not necessarily work for encryption schemes that do not rely on
> XOR for encryption, but you can limit negotiation to schemes that have
> hardware support without changing protocol version.
>
>
Since DTLS1.3 supports only the AES encryption option, it seems like the
most common option to tackle.


>
> As I recall, header encryption was a really hard nut to crack because any
> trivial encryption was either too weak or too complicated.
>

Indeed I see no method of efficiency header protection while keeping the
current format and size of the header. For instance, one could conceivably
use another number for PNE, but that seems wasteful.


>
> Mikkel
>
> On 8 Feb 2023, at 09.25, Boris Pismenny <borispisme...@gmail.com> 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 hardware acceleration as I’ll explain next.
>
> For hardware to encrypt the packet numbers, there are two options:
>
>    1. Feed the header back into the encryption machine after data has
>    been encrypted. This means storing and forwarding data, higher
>    implementation complexity, and greater bandwidth requirements on the single
>    encryption machine.
>    2.
>
>    Adding an additional unique pipeline stage dedicated for header
>    encryption.
>
> As you may already know, this is not hardware friendly and for this reason
> many vendors will likely refuse to pay the cost of supporting this. But
> suppose a vendor does implement this feature, one problem still remains.
> PNE will still cause noticeable latency and performance degradation for
> high speed networks (think >400Gbps).
>
> Now, in certain use-cases, such as high performance computing, cloud
> computing, or data-center clusters—the security benefits of encrypting
> headers are marginal compared to the latency imposed by PNE. Would it be
> possible to consider letting these users negotiate to disable PNE and by
> doing so benefit (more) from encryption acceleration?
>
> Best regards,
>
> Boris
>
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to