Draft: draft-ietf-tls-dtls13

Commentary: I read through the draft and amassed a number of comments . This PR resolves the easy stuff . I 'll send an email to the WG list with the more interesting ones shortly .  fixes . The text describing sequence number encryption does n't say how the receiver handles short ciphertexts . It 's also phrased oddly . It says " In some ( rare ) cases the ciphertext may be less than 16 bytes " , but the whole point of the text is to ensure it can not be less than 16 bytes .  it . Whether there 's a Certificate message is no longer a function of the ciphersuite , but of parameters in general . ( With resumption that was already true . ) The bits talking about epoch 1 - 3 so far before the definitions of those epochs should link to the section . Remove some remnants of EndOfEarlyData . They 're still in the definition of the Handshake struct . I was n't sure how to handle that since it was in the HandshakeType enum and we probably should n't call it RESERVED when it exists in TLS ? Spell out [ sender]\application\traffic\secret\ since traffic\secret\ is n't defined . 
 This looks good to me . 
 These changes look good to me ! can you please have a look ?
Paragraph (version A):
If the first byte is any other other value, then receivers MUST
check to see if the leading bits of the first byte are 001.  If
so, the implementation MUST process the record as DTLSCiphertext;
the true content type will be inside the protected portion.
Paragraph (version B):
If the first byte is any other value, then receivers MUST check to
see if the leading bits of the first byte are 001.  If so, the
implementation MUST process the record as DTLSCiphertext; the true
content type will be inside the protected portion.
Paragraph (version A):
In some (rare) cases the ciphertext may be less than 16 bytes.  This
cannot happen with most of the DTLS AEAD algorithms because the
authentication tag itself is 16 bytes, however some algorithms such
as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag, and in
combination with a short plaintext, the result might be less than 16
bytes.  In this case, implementations MUST pad the plaintext out
(using the conventional record padding mechanism) in order to make a
suitable-length ciphertext.
Paragraph (version B):
This procedure requires the ciphertext length be at least 16 bytes.
Receivers MUST reject shorter records as if they had failed
deprotection, as described in handling-invalid-records.  Senders MUST
pad short plaintexts out (using the conventional record padding
mechanism) in order to make a suitable-length ciphertext.  Note most
of the DTLS AEAD algorithms have a 16-byte authentication tag and
need no padding.  However, some algorithms such as
TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag and may
require padding for short inputs.
Paragraph (version A):
An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source of the victim.
The server then sends its response to the victim machine, thus
flooding it.  Depending on the selected ciphersuite this response
message can be quite large, as it is the case for a Certificate
message.
Paragraph (version B):
An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source of the victim.
The server then sends its response to the victim machine, thus
flooding it.  Depending on the selected parameters this response
message can be quite large, as it is the case for a Certificate
message.
Paragraph (version A):
The DTLS 1.3 specification changes the way how cookies are exchanged
compared to DTLS 1.2.  DTLS 1.3 re-uses the HelloRetryRequest message
and conveys the cookie to the client via an extension.  The client
receiving the cookie uses the same extension to place the cookie
subsequently into a ClientHello message.  DTLS 1.2 on the other hand
used a separate message, namely the HelloVerifyRequest, to pass a
cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reason the cookie field in the
ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3
compliant server implementation.
Paragraph (version B):
The DTLS 1.3 specification changes the way how cookies are exchanged
compared to DTLS 1.2.  DTLS 1.3 re-uses the HelloRetryRequest message
and conveys the cookie to the client via an extension.  The client
receiving the cookie uses the same extension to place the cookie
subsequently into a ClientHello message.  DTLS 1.2 on the other hand
used a separate message, namely the HelloVerifyRequest, to pass a
cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reasons, the cookie field in the
ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3
compliant server implementation.
Paragraph (version A):
The DTLS 1.3 handshake has one important difference from the TLS 1.3
handshake: the EndOfEarlyData message is omitted both from the wire
and the handshake transcript: because DTLS records have epochs,
EndOfEarlyData is not necessary to determine when the early data is
complete, and because DTLS is lossy, attackers can trivially mount
the deletion attacks that EndOfEarlyData prevents in TLS.  Servers
SHOULD aggressively age out the epoch 1 keys upon receiving the first
epoch 2 record and SHOULD NOT accept epoch 1 data after the first
epoch 3 record is received.
Paragraph (version A):
The implementation reads a ACK from the peer: upon receiving an
ACK for a partial flight (as mentioned in sending-acks), the
implementation transitions to the SENDING state, where it
retransmits the unacked portion of the flight, resets the
retransmit timer, and returns to the WAITING state.  Upon
receiving an ACK for a complete flight, the implementation cancels
all retransmissions and either remains in WAITING, or, if the ACK
was for the final flight, transitions to FINISHED.
Paragraph (version B):
The implementation reads an ACK from the peer: upon receiving an
ACK for a partial flight (as mentioned in sending-acks), the
implementation transitions to the SENDING state, where it
retransmits the unacked portion of the flight, resets the
retransmit timer, and returns to the WAITING state.  Upon
receiving an ACK for a complete flight, the implementation cancels
all retransmissions and either remains in WAITING, or, if the ACK
was for the final flight, transitions to FINISHED.
Paragraph (version A):
Though timer values are the choice of the implementation, mishandling
of the timer can lead to serious congestion problems; for example, if
many instances of a DTLS time out early and retransmit too quickly on
a congested link.  Implementations SHOULD use an initial timer value
of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the
value at each retransmission, up to no less than the RFC 6298 maximum
of 60 seconds.  Application specific profiles, such as those used for
the Internet of Things environment, may recommend longer timer
values.  Note that a 100 msec timer is recommend rather than the
3-second RFC 6298 default in order to improve latency for time-
sensitive applications.  Because DTLS only uses retransmission for
handshake and not dataflow, the effect on congestion should be
minimal.
Paragraph (version B):
Though timer values are the choice of the implementation, mishandling
of the timer can lead to serious congestion problems; for example, if
many instances of a DTLS time out early and retransmit too quickly on
a congested link.  Implementations SHOULD use an initial timer value
of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the
value at each retransmission, up to no less than the RFC 6298 maximum
of 60 seconds.  Application specific profiles, such as those used for
the Internet of Things environment, may recommend longer timer
values.  Note that a 100 msec timer is recommended rather than the
3-second RFC 6298 default in order to improve latency for time-
sensitive applications.  Because DTLS only uses retransmission for
handshake and not dataflow, the effect on congestion should be
minimal.
Paragraph (version A):
epoch value (1) is used for messages protected using keys derived
from client_early_traffic_secret.  This includes early data sent
by the client and the EndOfEarlyData message.
Paragraph (version B):
epoch value (1) is used for messages protected using keys derived
from client_early_traffic_secret.  Note this epoch is skipped if
the client does not offer early data.
Paragraph (version A):
epoch value (3) is used for payloads protected using keys derived
from the initial traffic_secret_0.  This may include handshake
messages, such as post-handshake messages (e.g., a
NewSessionTicket message).
Paragraph (version A):
epoch value (4 to 2^16-1) is used for payloads protected using
keys from the traffic_secret_N (N>0).
Paragraph (version B):
epoch value (3) is used for payloads protected using keys derived
from the initial [sender]_application_traffic_secret_0.  This may
include handshake messages, such as post-handshake messages (e.g.,
a NewSessionTicket message).
Paragraph (version B):
epoch value (4 to 2^16-1) is used for payloads protected using
keys from the [sender]_application_traffic_secret_N (N>0).