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

Commentary: This is supposed to all be editorial stuff , and I split a couple changes out into separate commits in case they 're not actually desired .
Paragraph (version A):
The Datagram Transport Layer Security (DTLS) protocol was designed
for securing connection-less transports, like UDP.  DTLS, like TLS,
starts with a handshake, which can be computationally demanding
(particularly when public key cryptography is used).  After a
successful handshake, symmetric key cryptography is used to apply
data origin authentication, integrity and confidentiality protection.
This two-step approach allows endpoints to amortize the cost of the
initial handshake across subsequent application data protection.
Ideally, the second phase where application data is protected lasts
over a longer period of time since the established keys will only
need to be updated once the key lifetime expires.
Paragraph (version A):
In the current version of DTLS, the IP address and port of the peer
are used to identify the DTLS association.  Unfortunately, in some
cases, such as NAT rebinding, these values are insufficient.  This is
a particular issue in the Internet of Things when devices enter
extended sleep periods to increase their battery lifetime.  The NAT
rebinding leads to connection failure, with the resulting cost of a
new handshake.
Paragraph (version B):
The Datagram Transport Layer Security (DTLS) RFC6347 protocol was
designed for securing connection-less transports, like UDP.  DTLS,
like TLS, starts with a handshake, which can be computationally
demanding (particularly when public key cryptography is used).  After
a successful handshake, symmetric key cryptography is used to apply
data origin authentication, integrity and confidentiality protection.
This two-step approach allows endpoints to amortize the cost of the
initial handshake across subsequent application data protection.
Ideally, the second phase where application data is protected lasts
over a long period of time since the established keys will only need
to be updated once the key lifetime expires.
Paragraph (version B):
In DTLS as specified in RFC 6347, the IP address and port of the peer
are used to identify the DTLS association.  Unfortunately, in some
cases, such as NAT rebinding, these values are insufficient.  This is
a particular issue in the Internet of Things when devices enter
extended sleep periods to increase their battery lifetime.  The NAT
rebinding leads to connection failure, with the resulting cost of a
new handshake.
Paragraph (version A):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID 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.  Such implementations must
still be able to send CIDs of different length to other parties.
Note that there is no CID length information included in the record
itself.
Paragraph (version B):
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID 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.  Such implementations MUST still be able to send CIDs of
different length to other parties.  Implementations that 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
there is no CID length information included in the record itself.
Paragraph (version A):
The CID value, cid_length bytes long, as agreed at the time the
extension has been negotiated.
Paragraph (version B):
The CID value, cid_length bytes long, as agreed at the time the
extension has been negotiated.  Recall that (as discussed
previously) each peer chooses the CID value it will receive and
use to identify the connection, so an implementation can choose to
always recieve CIDs of a fixed length.  If, however, an
implementation chooses to receive different lengths of CID, the
assigned CID values must be self-delineating since there is no
other mechanism available to determine what connection (and thus,
what CID length) is in use.
Paragraph (version A):
Several types of ciphers have been defined for use with TLS and DTLS
and the MAC calculation for those ciphers differs slightly.
Paragraph (version A):
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):
Several types of ciphers have been defined for use with TLS and DTLS
and the MAC calculations for those ciphers differ slightly.
Paragraph (version B):
This specification modifies the MAC calculation as 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 A):
Value of the negotiated CID.
Paragraph (version A):
The length (in bytes) of the serialised DTLSInnerPlaintext.
The length MUST NOT exceed 2^14.
Paragraph (version B):
Value of the negotiated CID (variable length).
Paragraph (version B):
The length (in bytes) of the serialised DTLSInnerPlaintext (two-
byte integer).
The length MUST NOT exceed 2^14.
Paragraph (version A):
The above is necessary to protect against attacks that use datagrams
with spoofed addresses or replayed datagrams to trigger attacks.
Note that there is no requirement to use of the anti-replay window
mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions,
the "anti-replay window" or "newer algorithm" will prevent address
updates from replay attacks while the latter will only apply to peer
address updates and the former applies to any application layer
traffic.
Paragraph (version A):
Application protocols that implement protection against these attacks
depend on being aware of changes in peer addresses so that they can
engage the necessary mechanisms.  When delivered such an event, an
application layer-specific address validation mechanism can be
triggered, for example one that is based on successful exchange of
minimal amount of ping-pong traffic with the peer.  Alternatively, an
DTLS-specific mechanism may be used, as described in I-D.tschofenig-
tls-dtls-rrc.
Paragraph (version B):
The above is necessary to protect against attacks that use datagrams
with spoofed addresses or replayed datagrams to trigger attacks.
Note that there is no requirement for use of the anti-replay window
mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions,
the "anti-replay window" or "newer" algorithm, will prevent address
updates from replay attacks while the latter will only apply to peer
address updates and the former applies to any application layer
traffic.
Paragraph (version B):
Note that datagrams that pass the DTLS cryptographic verification
procedures but do not trigger a change of peer address are still
valid DTLS records and are still to be passed to the application.
Paragraph (version B):
Application protocols that implement protection against these attacks
depend on being aware of changes in peer addresses so that they can
engage the necessary mechanisms.  When delivered such an event, an
application layer-specific address validation mechanism can be
triggered, for example one that is based on successful exchange of a
minimal amount of ping-pong traffic with the peer.  Alternatively, an
DTLS-specific mechanism may be used, as described in I-D.tschofenig-
tls-dtls-rrc.
Paragraph (version A):
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):
Note: In the example exchange the CID is included in the record layer
once encryption is enabled.  In DTLS 1.2 only one handshake message
is encrypted, namely the Finished message.  Since the example shows
how to use the CID for payloads sent from the client to the server
only the record layer payloads containing the Finished messages
include a CID.  Application data payloads sent from the client to the
server contain a CID in this example as well.
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 is present in the "connection_id" extension we use
the notation 'connection_id=empty'.
Paragraph (version B):
Note: In the example exchange the CID is included in the record layer
once encryption is enabled.  In DTLS 1.2 only one handshake message
is encrypted, namely the Finished message.  Since the example shows
how to use the CID for payloads sent from the client to the server,
only the record layer payloads containing the Finished message or
application data include a CID.
Paragraph (version A):
Finally, 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 concern with CIDs that
contain arbitrary values.  Implementations concerned about this
aspects SHOULD refuse to use CIDs.
Paragraph (version B):
Finally, endpoints can use the CID to attach arbitrary per-connection
metadata to each record they receive on a given connection.  This may
be used as a mechanism to communicate per-connection information to
on-path observers.  There is no straightforward way to address this
concern with CIDs that contain arbitrary values.  Implementations
concerned about this aspect SHOULD refuse to use CIDs.
Paragraph (version A):
Additionally, an attacker able to observe the data traffic exchanged
between two DTLS peers is able to replay datagrams with modified IP
address/port numbers.
Paragraph (version B):
Additionally, an attacker able to observe the data traffic exchanged
between two DTLS peers is able to modify IP address/port numbers.
When the optional DTLS replay detection is not in use, such an
attacker can also replay the observed packets, and the multiple
copies of each packet can have different IP address/port numbers as
well.
Paragraph (version A):
registry to indicate whether an extension is only applicable to DTLS.
Paragraph (version A):
Note: The value "N" in the Recommended column is set because this
extension is intended only for specific use cases.  This document
describes an extension for DTLS 1.2 only; it is not to TLS (1.3).
The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13.
Paragraph (version B):
registry to indicate whether an extension is only applicable to DTLS
and to include this document as an additional reference for the
registry.
Paragraph (version B):
Note: The value "N" in the Recommended column is set because this
extension is intended only for specific use cases.  This document
describes the behavior of this extension for DTLS 1.2 only; it is not
applicable to TLS, and its usage for DTLS 1.3 is described in I-
D.ietf-tls-dtls13.