Re: [quicwg/base-drafts] First octet changes (#2006)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> +Before a TLS ciphersuite can be used with QUIC, a header protection algorithm
+MUST be specified for the AEAD used with that ciphersuite.  This document
+defines algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM,
+AEAD_AES_256_CCM (all AES AEADs are defined in {{!AEAD=RFC5116}}), and
+AEAD_CHACHA20_POLY1305 {{!CHACHA=RFC8439}}.
+
+
+### Header Protection Sample {#hp-sample}
+
+The header protection algorithm uses both the header protection key and a sample
+of the ciphertext from the packet Payload field.
+
+The same number of bytes are always sampled, but an allowance needs to be made
+for the endpoint removing protection, which will not know the length of the
+Packet Number field.  In sampling the packet ciphertext, the Packet Number field
+is assumed to be 4 bytes long (its maximum possible encoded length), unless

As pointed out by @huitema elsewhere, we might start seeing cipher-suites that use smaller-sized tags.

For example, the TLS_AES_128_CCM_8_SHA256 cipher-suite defined in [TLS 1.3](https://tools.ietf.org/html/rfc8446) uses a 64-bit tag, meaning that the shortest possible IV passed to the header protection would be just 72-bits.

Considering that, I think it might be safer to require senders to pad the payload so that there would be at least 128 bits of IV.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006#discussion_r234105228