target = "https://tools.ietf.org/rfc/rfc8446#4.4.4"

# 4.4.4.  Finished
#
# The Finished message is the final message in the Authentication
# Block.  It is essential for providing authentication of the handshake
# and of the computed keys.
# 
# Recipients of Finished messages MUST verify that the contents are
# correct and if incorrect MUST terminate the connection with a
# "decrypt_error" alert.
# 
# Once a side has sent its Finished message and has received and
# validated the Finished message from its peer, it may begin to send
# and receive Application Data over the connection.  There are two
# settings in which it is permitted to send data prior to receiving the
# peer's Finished:
# 
# 1.  Clients sending 0-RTT data as described in Section 4.2.10.
# 
# 2.  Servers MAY send data after sending their first flight, but
#     because the handshake is not yet complete, they have no assurance
#     of either the peer's identity or its liveness (i.e., the
#     ClientHello might have been replayed).
# 
# The key used to compute the Finished message is computed from the
# Base Key defined in Section 4.4 using HKDF (see Section 7.1).
# Specifically:
# 
# finished_key =
#     HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
# 
# Structure of this message:
# 
#    struct {
#        opaque verify_data[Hash.length];
#    } Finished;
# 
# The verify_data value is computed as follows:
# 
#    verify_data =
#        HMAC(finished_key,
#             Transcript-Hash(Handshake Context,
#                             Certificate*, CertificateVerify*))
# 
#    * Only included if present.
# 
# HMAC [RFC2104] uses the Hash algorithm for the handshake.  As noted
# above, the HMAC input can generally be implemented by a running hash,
# i.e., just the handshake hash at this point.
# 
# In previous versions of TLS, the verify_data was always 12 octets
# long.  In TLS 1.3, it is the size of the HMAC output for the Hash
# used for the handshake.
# 
# Note: Alerts and any other non-handshake record types are not
# handshake messages and are not included in the hash computations.
# 
# Any records following a Finished message MUST be encrypted under the
# appropriate application traffic key as described in Section 7.2.  In
# particular, this includes any alerts sent by the server in response
# to client Certificate and CertificateVerify messages.

[[spec]]
level = "MUST"
quote = '''
Recipients of Finished messages MUST verify that the contents are
correct and if incorrect MUST terminate the connection with a
"decrypt_error" alert.
'''

[[spec]]
level = "MUST"
quote = '''
Recipients of Finished messages MUST verify that the contents are
correct and if incorrect MUST terminate the connection with a
"decrypt_error" alert.
'''

[[spec]]
level = "MAY"
quote = '''
Servers MAY send data after sending their first flight, but
because the handshake is not yet complete, they have no assurance
of either the peer's identity or its liveness (i.e., the
ClientHello might have been replayed).
'''

[[spec]]
level = "MUST"
quote = '''
Any records following a Finished message MUST be encrypted under the
appropriate application traffic key as described in Section 7.2.
'''