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

Commentary: It probably makes sense to be a little more consistent . 
 Makes sense . I will do this after the current wave of pull requests have been reviewed and accepted / rejected . 
 I addressed this issue in PR 
 Addressed with submitted draft version  
 I do n't think that you need to change the grammar .
Paragraph (version A):
This document specifies the Connection ID construct for the Datagram
Transport Layer Security (DTLS) protocol version 1.2.
Paragraph (version A):
A Connection ID is an identifier carried in the record layer header
that gives the recipient additional information for selecting the
appropriate security association.  In "classical" DTLS, selecting a
security association of an incoming DTLS record is accomplished with
the help of the 5-tuple.  If the source IP address and/or source port
changes during the lifetime of an ongoing DTLS session then the
receiver will be unable to locate the correct security context.
Paragraph (version B):
This document specifies the Connection ID (CID) construct for the
Datagram Transport Layer Security (DTLS) protocol version 1.2.
Paragraph (version B):
A CID is an identifier carried in the record layer header that gives
the recipient additional information for selecting the appropriate
security association.  In "classical" DTLS, selecting a security
association of an incoming DTLS record is accomplished with the help
of the 5-tuple.  If the source IP address and/or source port changes
during the lifetime of an ongoing DTLS session then the receiver will
be unable to locate the correct security context.
Paragraph (version A):
This document defines an extension to DTLS to add a connection ID
(CID) to the DTLS record layer.  The presence of the connection ID is
negotiated via a DTLS extension.
Paragraph (version B):
This document defines an extension to DTLS 1.2 to add a CID to the
DTLS record layer.  The presence of the CID is negotiated via a DTLS
extension.
Paragraph (version A):
This document defines a new extension type (connection_id(TBD)),
which is used in ClientHello and ServerHello messages.
Paragraph (version B):
This document defines the "connection_id" extension, which is used in
ClientHello and ServerHello messages.
Paragraph (version A):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure, which carries
the CID which the client wishes the server to use when sending
messages towards it.  A zero-length value indicates that the client
is prepared to send with a connection ID but does not wish the server
to use one when sending (alternately, this can be interpreted as the
client wishes the server to use a zero-length CID; the result is the
same).
Paragraph (version A):
A server which is willing to use CIDs will respond with its own
"connection_id" extension, containing the CID it wishes the client to
use when sending messages towards it.  A zero-length value indicates
that the server will send with the client's CID but does not wish the
client to use a CID (or again, alternately, to use a zero-length
CID).
Paragraph (version B):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure, which carries
the CID which the client wishes the server to use when sending
messages towards it.  A zero-length value indicates that the client
is prepared to send with a CID but does not wish the server to use
one when sending (alternately, this can be interpreted as the client
wishes the server to use a zero-length CID; the result is the same).
Paragraph (version B):
A server willing to use CIDs will respond with a "connection_id"
extension in the ServerHello, containing the CID it wishes the client
to use when sending messages towards it.  A zero-length value
indicates that the server will send with the client's CID but does
not wish the client to include a CID (or again, alternately, to use a
zero-length CID).
Paragraph (version A):
Because each party sends the value in the "connection_id" extension
that it wants to receive as a connection identifier in encrypted
records, it is possible for an endpoint to use a globally constant
length for such connection identifiers.  This can in turn ease
parsing and connection lookup, for example by having the length in
question be a compile-time constant.  Implementations, which want to
use variable-length CIDs, are responsible for constructing the CID in
such a way that its length can be determined on reception.  Note that
such implementations must still be able to send connection
identifiers of different length to other parties.
Paragraph (version A):
Note that it is not possible to parse the records without knowing how
long the Connection ID is.
Paragraph (version A):
In DTLS 1.2, connection ids are exchanged at the beginning of the
DTLS session only.  There is no dedicated "connection id update"
message that allows new connection ids to be established mid-session,
because DTLS 1.2 in general does not allow TLS 1.3-style post-
handshake messages that do not themselves begin other handshakes.
Paragraph (version B):
Because each party sends the value in the "connection_id" extension
that it wants to receive as a connection identifier in encrypted
records, it is possible for an endpoint to use a globally constant
length for such connection identifiers.  This can in turn ease
parsing and connection lookup,
Paragraph (version B):
for example by having the length in question be a compile-time
constant.  Implementations, which want to use variable-length CIDs,
are responsible for constructing the CID in such a way that its
length can be determined on reception.  Note that such
implementations must still be able to send connection identifiers of
different length to other parties.
Paragraph (version B):
Note that it is not possible to parse the records without knowing how
long the CID is.
Paragraph (version B):
In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session
only.  There is no dedicated "CID update" message that allows new
CIDs to be established mid-session, because DTLS 1.2 in general does
not allow TLS 1.3-style post-handshake messages that do not
themselves begin other handshakes.
Paragraph (version A):
When CID is 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 B):
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):
dtls-example2 shows an example exchange where a connection id is used
uni-directionally from the client to the server.  To indicate that a
connection_id has zero length we use the term 'connection_id=empty'.
Paragraph (version B):
dtls-example2 shows an example exchange where a CID is used uni-
directionally from the client to the server.  To indicate that a
zero-length CID we use the term 'connection_id=empty'.
Paragraph (version A):
The connection id replaces the previously used 5-tuple and, as such,
introduces an identifier that remains persistent during the lifetime
of a DTLS connection.  Every identifier introduces the risk of
linkability, as explained in RFC6973.
Paragraph (version A):
In addition, endpoints can use the connection ID to attach arbitrary
metadata to each record they receive.  This may be used as a
mechanism to communicate per-connection information to on-path
observers.  There is no straightforward way to address this with
connection IDs that contain arbitrary values; implementations
concerned about this SHOULD refuse to use connection ids.
Paragraph (version A):
An on-path adversary, who is able to observe the DTLS protocol
exchanges between the DTLS client and the DTLS server, is able to
link the observed payloads to all subsequent payloads carrying the
same connection id pair (for bi-directional communication).  Without
multi-homing or mobility, the use of the connection id is not
different to the use of the 5-tuple.
Paragraph (version B):
The CID replaces the previously used 5-tuple and, as such, introduces
an identifier that remains persistent during the lifetime of a DTLS
connection.  Every identifier introduces the risk of linkability, as
explained in RFC6973.
Paragraph (version B):
In addition, endpoints can use the CID to attach arbitrary metadata
to each record they receive.  This may be used as a mechanism to
communicate per-connection information to on-path observers.  There
is no straightforward way to address this with CIDs that contain
arbitrary values; implementations concerned about this SHOULD refuse
to use connection ids.
Paragraph (version B):
An on-path adversary, who is able to observe the DTLS protocol
exchanges between the DTLS client and the DTLS server, is able to
link the observed payloads to all subsequent payloads carrying the
same connection id pair (for bi-directional communication).  Without
multi-homing or mobility, the use of the CID is not different to the
use of the 5-tuple.