On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote: > I think it's a close call, because the length is sort of external to the > language.
which language? the decode_error alert description literally says "length of
the message was incorrect."
> 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.
but the text is explicit, if a message continues past message boundary, the
correct response is decode_error. Decode_error is also consistent with the way
above-expected length Client Hello MUST be handled.
Just because the description of the message uses a single opaque array doesn't
make this message syntactically any different from other Handshake protocol
message.
if the interpretation of "I know this _message_ _length_ is wrong because of
some other values I negotiated before, so I'll send illegal_parameter" was
correct, then overflow_error, decrypt_error and probably few others would also
need to be replaced with illegal_parameter...
> -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
--
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
