Draft: draft-ietf-quic-tls

Commentary: For input to discussion on the related issues . This says that we do n't do CCM_8 and makes it clear that you do n't reject an attempt to use a ciphersuite you do n't understand . This is an editorial resolution to the design issue . , . 
 LGTM 
 I think I must be entirely missing the point , but I do n't understand this : Can you please explain how this works ? For the sake of argument , TLSAES128CCM8_SHA256 is not supported , but the peer chooses to use it , and the TLS engine behind it all decides to support it via some configuration that the endpoint is directly aware of . How does the endpoint now deal with header protection . Is it assumed that this is a TLS black box so it just magically works if the TLS engine has accepted the cipher via some useful API call . If it is a TLS blackbox API call , how would that work with HW offloading ? 
 Now I understand it . Being offered by TLS is not the same as being used by any of the endpoints . Sorry for the noise . 
 Suppose that we had a future TLS cipher suite such as AESOCBSHA256 . Would that work with QUIC without a new QUIC draft ? The AEAD part is already clearly defined and given that AES - OCB uses AES , the same HP mechanism as we currently use with GCM can be used here . From my perspective , the desirable property is that if we add new TLS cipher suites with analogous cipher cores ( block cipher and/or nonce - based stream cipher ) to the existing spec , then no new QUIC document should be required . An alternative design would be to just require a " QUIC applicability " paragraph in new TLS cipher suites analogous to the DTLS - OK IANA flag . ( see also ) . 
 How about header protection which depends on being defined for the negotiated AEAD ? 
 That 's what paragraph 2 above is about . 
 As discussed in , we did not originally have a good way to make AEADAES128CCM8 work in QUIC , because it needs a 16 byte sample for header protection but only produces an 8 byte auth tag . However , since then we have merged , and it 's therefore easy to pad short packets by 8 extra bytes when using CCM_8 . There might be QUIC use - cases that could benefit from the shorter tags , and it would be nice to have QUIC support all the original TLS 1.3 cipher suites . 
 +1 CCM_8 is big in environments like broadcast production 
 This just adds an odd error - prone special case for padding , and the key benefit of being short is lost on short packets due to padding . 
 I think we can accommodate this in QUIC v1 . The change has zero impact on implementations not supporting CCM8 . Code can be left as - is . Specification - wise the required change would be to alter the definition of minimal payload size from 4 to ) . 
 I disagree . It 's only the very short packets that do not have the benefit . Longer packets do not require additional padding , and will benefit from the use of the shorter tag . 
 I do n't think that we need this . The reasons offered thus far amount to " because we can " . I 'd like to see some analysis suggesting that shorter authentication tags are OK in the general case . Or text explaining constraints on deployments that choose to use a shorter tag . I understand the benefits of CCM over GCM ; I understand that this includes an ability to have a shorter tag , unlike GCM which fails badly . I understand the desire to save bits . But it is n't really that many bits , and the shorter tag changes the odds of an invalid packet being accepted fairly significantly . 
 can you elaborate on what makes QUIC different from TLS that suggests AES128CCM_8 is useful in TLS but not in QUIC ? 
 It 's worth remembering that QUIC packet sizes are ( typically ) smaller than TLS record size which means that the consequences of saving bytes are larger in QUIC than in TLS . 
 Well , we generally discourage the use of CCM_8 in TLS as well . We mostly only it for IoT purposes . 
 QUIC is also applicable to IoT , CCM_8 should be supported but discouraged here as well . 
 Is there a strong argument to diverge from existing TLS practice here ? 
 CCM8 is better suitet for a separate QUIC version for IoT where header protection and padding is also dropped and where the traffic volume is low . A cheaper handshake would also be needed . Someone said  is commonly used with video AFAIR . 
 I do n't think encouraging protocol fragmentation is a good idea . The reason TLS 1.3 has CCM_8 is to allow IoT use - cases to use TLS 1.3 instead of making them develop new protocols . The same argument applies to QUIC . 
 Q : Should we allow it for QUIC , but not allow it for HTTP/3 ? 
 No , the application layer should n't deal with transport security . If the security properties changes , it should be a new QUIC version . 
 I agree with on this one . HTTP/2 does n't disallow CCM_8 when run over TLS 1.3 . 
 But if I argue that CCM8 changes security properties , you might disagree since that would move CCM8 to a new QUIC version . 
 this does n't seem like a very persuasive analogy , given that HTTP/2 has a long list of rules about disabling ciphers that were present in TLS 1.2 : The reason that it does n't have that for TLS 1.3 is that ( 1 ) TLS 1.3 post - dates HTTP/2 and ( 2 ) the suites were chosen according to the same principles Second , as a practical matter , most browsers do not support CCM_8 , and I suspect that will continue to be true for most stacks , partly because performance is not awesome ( as it requires computing CBC ) . If , as implies , we want to have a cipher with a shorter authentication tag ( I 'm undecided on this topic myself at present ) for general use then we should consult CFRG for one , rather than just use the one that happened to be the one that IoT devices supported . 
 I would personally have preferred to include AES128CCM8 in the QUIC spec to have parity with TLS 1.3 , but I can live with the text from because that allows someone to write a one - page spec on how to use AES128CCM8 in QUIC without risking interoperability issues . I 'm OK with closing this issue with no further action at this point . 
 LGTM
Paragraph (version A):
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, does not produce a large enough
authentication tag for use with the header protection designs
provided (see header-protect).  All other ciphersuites defined in
TLS13 have a 16-byte authentication tag and produce an output 16
bytes larger than their input.
Paragraph (version B):
QUIC can use any of the ciphersuites defined in TLS13 with the
exception of TLS_AES_128_CCM_8_SHA256.  A ciphersuite MUST NOT be
negotiated unless a header protection scheme is defined for the
ciphersuite.  This document defines a header protection scheme for
all ciphersuites defined in TLS13 aside from
TLS_AES_128_CCM_8_SHA256.  These ciphersuites have a 16-byte
authentication tag and produce an output 16 bytes larger than their
input.
Paragraph (version B):
An endpoint MUST NOT reject a ClientHello that offers a
ciphersuite that it does not support, or it would be impossible to
deploy a new ciphersuite.  This also applies to
TLS_AES_128_CCM_8_SHA256.
Paragraph (version A):
To ensure that sufficient data is available for sampling, packets are
padded so that the combined lengths of the encoded packet number and
protected payload is at least 4 bytes longer than the sample required
for header protection.  For the AEAD functions defined in TLS13,
which have 16-byte expansions and 16-byte header protection samples,
this results in needing at least 3 bytes of frames in the unprotected
payload if the packet number is encoded on a single byte, or 2 bytes
of frames for a 2-byte packet number encoding.
Paragraph (version B):
To ensure that sufficient data is available for sampling, packets are
padded so that the combined lengths of the encoded packet number and
protected payload is at least 4 bytes longer than the sample required
for header protection.  The ciphersuites defined in TLS13 - other
than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme
is not defined in this document - have 16-byte expansions and 16-byte
header protection samples.  This results in needing at least 3 bytes
of frames in the unprotected payload if the packet number is encoded
on a single byte, or 2 bytes of frames for a 2-byte packet number
encoding.