Draft: draft-ietf-tls-dtls-connection-id

Commentary: As discussed with Hannes , this PR replaces 
 We currently only describe CID processing with AEAD ciphersuites , which seems to imply that the CID extension effectively influences ciphersuite negotiation . The draft should explain how the two - ciphersuite negotiation and CID ext - interact . 
 I 'm not sure , what the scope of this explanation should be ? For the MAC , it seems to be obvious , that the block cipher ( ) extend the data for the MAC accordingly . will get That was already discussed in So , I 'm not sure , if you are the intended "  " , which may write that :-) 
 The question is whether we should define the CID - enhanced MAC calculation for non - AEAD ciphers . The current draft only supports AEAD ciphers . If that 's OK then we could just tell implementers that the ciphersuite selection should be influenced by this . Alternatively , we could define the MAC calculation also for non - AEAD ciphers . What would you prefer ,  ? 
 The latter , I think ... 
 Though  ( LWM2 M , also supporting CBC ) is one of the major using and contributing projects , I would also prefer to have the MAC defined for the none - AEAD . 
 Here is the PR :
Paragraph (version A):
When receiving a datagram with the tls12_cid content type, the new
MAC computation defined in mac MUST be used.  When receiving a
datagram with the RFC 6347-defined record format the MAC calculation
defined in Section 4.1.2 of RFC6347 (and Section 4.1.2.4 of RFC6347
for use with AEAD ciphers) MUST be used.
Paragraph (version B):
When receiving a datagram with the tls12_cid content type, the new
MAC computation defined in mac MUST be used.  When receiving a
datagram with the RFC 6347-defined record format the MAC calculation
defined in Section 4.1.2 of RFC6347 MUST be used.
Paragraph (version A):
When CIDs are being used, the content to be sent is first wrapped
along with the true content type and padding into a
DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext
value is then encrypted. dtls-record12 illustrates the record format.
Paragraph (version A):
This field contains the byte encoding of a handshake, an alert
message, or the raw bytes of the application's data to send.
Paragraph (version A):
The DTLSInnerPlaintext.type value contains the content type of the
record.  This is the non-obfuscated (true) content type.
Paragraph (version A):
The outer opaque_type field of a DTLSCiphertext record is always
set to the value 25 (tls12_cid).  The actual content type of the
record is found in DTLSInnerPlaintext.type after decryption.  By
encapsulating the true content type inside the encrypted payload
the outer content type (special_type) can be used to signal the
new record layer format containing the CID.
Paragraph (version A):
The DTLSCiphertext.version field describes the protocol being
employed.  This document describes an extension to DTLS version
1.2.
Paragraph (version A):
The DTLSCiphertext.length field indicates the length (in bytes) of
the following DTLSCiphertext.encrypted_record, which is the sum of
the lengths of the content and the padding, plus one for the inner
content type, plus any expansion added by the AEAD algorithm.
Paragraph (version A):
The CID value of length indicated with cid_length, as agreed
during the exchange.
Paragraph (version A):
The AEAD-encrypted form of the serialized DTLSInnerPlaintext
structure.
Paragraph (version A):
Other fields are defined in RFC 6347.  Note that this specification
does not make use of the DTLSCompressed structure.
Paragraph (version A):
This specification changes the MAC calculation defined in
Section 4.1.2 of RFC 6347.  At the time of writing ciphers using
authenticated encryption with additional data (AEAD) were state-of-
the-art.  Hence, this specification updates only the additional data
calculation defined in Section 6.2.3.3 of RFC5246, which is re-used
by Section 4.1.2.1 of RFC6347.
Paragraph (version A):
As described in Section 6.2.3.3 of RFC5246 this 64-bit value is
formed by concatenating the epoch and the sequence number in the
order they appear on the wire.
Paragraph (version A):
This value contains the outer-header content type, i.e. the
tls12_cid.
Paragraph (version A):
This value contains the version number.
Paragraph (version A):
This value contains the length information in the outer-header.
Paragraph (version B):
The DTLSInnerPlaintext value is then encrypted and the CID added to
produce the final DTLSCiphertext.
Paragraph (version B):
The outer content type of a DTLSCiphertext record carrying a CID
is always set to the value 25 (tls12_cid).  The actual content
type of the record is found in DTLSInnerPlaintext.real_type after
decryption.
Paragraph (version B):
The CID value, cid_length bytes long, as agreed at the time the
extension has been negotiated.
Paragraph (version B):
The encrypted form of the serialized DTLSInnerPlaintext structure.
Paragraph (version B):
All other fields are as defined in RFC 6347.
Paragraph (version B):
This specification modifies the MAC calculation defined in RFC6347
and RFC7366 as well as the definition of the additional data used
with AEAD ciphers provided in RFC6347 for records with content type
tls12_cid.  The modified algorithm MUST NOT be applied to records
that do not carry a CID, i.e., records with content type other than
tls12_cid.
Paragraph (version B):
All other fields are as defined in the cited documents.
Paragraph (version B):
The length (in bytes) of the serialised DTLSInnerPlaintext.  The
length MUST NOT exceed 2^14.