Despite this, is it correct to terminate a connection with "illegal_parameter" upon receiving a Finished handshake message with a 100 byte payload? or a 20 byte payload? My opinion is that it is not, "decode_error" is more specific so it should be used instead.
Specification says the following on the matter:
The draft 28 specifies the Finished message as having following structure:
struct {
opaque verify_data[Hash.length];
} Finished;
At multiple places it also talks about handling messages that have sizes that
don't match their structure as requiring termination of connection with
"decode_error".
The generic situation in Section 6:
Peers which receive a message which
cannot be parsed according to the syntax (e.g., have a length
extending beyond the message boundary or contain an out-of-range
length) MUST terminate the connection with a "decode_error" alert.
as description of the alert in Section 6.2:
decode_error A message could not be decoded because some field was
out of the specified range or the length of the message was
incorrect. This alert is used for errors where the message does
not conform to the formal protocol syntax.
In specific about Client Hello, in Section 4.1.2:
If negotiating a version of TLS prior to 1.3, a server MUST check
that the message either contains no data after
legacy_compression_methods or that it contains a valid extensions
block with no data following. If not, then it MUST abort the
handshake with a "decode_error" alert.
And specific handling of Certificate from server in Section 4.4.2.4:
If the server supplies an empty Certificate message, the client MUST
abort the handshake with a "decode_error" alert.
Description of "illegal_parameter" in Section 6:
Peers which receive a message which is syntactically correct but
semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
MUST terminate the connection with an "illegal_parameter" alert.
Alert description in Section 6.2:
illegal_parameter A field in the handshake was incorrect or
inconsistent with other fields. This alert is used for errors
which conform to the formal protocol syntax but are otherwise
incorrect.
(it's also mentioned in over a dozen places in the draft)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
