On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario <hka...@redhat.com> wrote:
> 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."
>
The protocol definition language.
-Ekr
> > 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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
