Re: [quicwg/base-drafts] Packet number encryption (#1079)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> +assumed to be its largest possible length (4 octets).  Thus, for a short header,
+the sampled ciphertext starts at either octet 5 when the connection ID is
+omitted, or octet 13 when the connection is present.
+
+The protected packet might not have produced enough input for the negotiated
+packet protection algorithm.  This might happen if a packet with a short header
+contains minimal data and uses a packet number encoding that is shorter than 4
+octets.  Additional zero octets are added to the end of the sequence to reach
+the required amount of data.
+
+Before a TLS ciphersuite can be used with QUIC, a packet protection algorithm
+MUST be specifed 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 {{!RFC5116}}), and
+AEAD_CHACHA20_POLY1305 ({{!CHACHA=RFC7539}}).
+

I can understand @martinthomson's point that if a stream cipher (or block cipher in CTR mode) exists beneath an AEAD is an implementation detail. Hence we need a mapping.

I also agree with @huitema that it would help implementors if the AES algorithm was explained as CTR mode. That would help people come up with an implementation that shares the code between the cipher suites.

-- 
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/1079#discussion_r165555327