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

@DavidSchinazi 
> I would be inclined to disallow TLS_AES_128_CCM_8_SHA256 in QUIC but either way padding the payload is a viable solution

Yeah my point is that I would rather avoid the possibility of discussing _how_ QUIC should be adjusted to support cipher-suites like AES128-CCM8, and that requiring the encoder to pad is a good approach in that respect. Because people who wants to introduce that type of cipher can simply define a different constant for the right-hand side (see my comment above).

-- 
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_r234394744