I think it's a close call, because the length is sort of external to the
language. That's why, for instance, NSS sends "illegal_parameter". So,
absent specific text about this value, I think this is something we can
leave to the implementations.
-Ekr
On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario <hka...@redhat.com> wrote:
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
