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 may try to propose an extension or a new version that changes
this specification, but such changes will have to be negotiated and
agreed by the client and server for each connection. Very likely, a
significant number of these clients and servers are going to reject the
extension. So, even if you do define this extension, your hardware will
still have to support the existing specification to talk to this
unmodified clients or servers.
-- Christian Huitema
On 2/10/2023 12:21 AM, Boris Pismenny wrote:
Hi Mikkel.
On Thu, Feb 9, 2023 at 8:21 PM Mikkel Fahnøe Jørgensen
<mikke...@gmail.com <mailto: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
<mailto: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 uniquepipeline 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
