Re: [quicwg/base-drafts] Don't allow use of AEAD_AES_128_CCM_8 (#2029)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -780,9 +780,12 @@ connection ID in the client's first Initial packet (see {{initial-secrets}}).
 This provides protection against off-path attackers and robustness against QUIC
 version unaware middleboxes, but not against on-path attackers.
 
-All ciphersuites currently defined for TLS 1.3 - and therefore QUIC - have a
-16-byte authentication tag and produce an output 16 bytes larger than their
-input.
+QUIC can use any of the ciphersuites defined in {{!TLS13}} with the exception of
+TLS_AES_128_CCM_8_SHA256.  The AEAD for that ciphersuite, AEAD_AES_128_CCM_8
+{{?CCM=RFC6655}}, does not produce a large enough authentication tag for use
+with header protection ({{header-protect}}).  All other ciphersuites defined in
+{{!TLS13}} have a 16-byte authentication tag and produce an output 16 bytes
+larger than their input.

I broadly agree, though I don't think that we can do (1) here because we don't know what PNE scheme might be devised to be paired with some future AEAD.  It seems like we have a requirement now, but something like FFX might be OK with a smaller sample.  I would prefer, as this does, to simply say that CCM_8 doesn't have a large enough expansion to use with the header protection schemes we have defined.

Should someone address the second question (and the question of whom to convince of this is interesting, but within the IETF it's clearly TLS), and design an header protection scheme based on that, then my hope is that this text wouldn't prevent them from using that.

-- 
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/2029#discussion_r236113733