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

[ekr <[e-mail]>]

ekr 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.

Hmm.... This seems like it raises the broader issue of how we import new ciphers into QUIC. As a hypothetical suppose TLS were to adopt an AES-GCM-SIV-based construction. It seems like at present we would actually require some new document to explain how to use it with QUIC. That seems sort of unfortunate, but formally I think that's true, because this document specifies a very specific list of ciphers.

If we wanted to, we could probably generalize this to some extent by documenting the *properties* of given ciphers and then how header protection works (i.e., block ciphers are done like this, nonce-based stream ciphers are done like this...) Not sure it's worth it, thoguh.



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