From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Date: Mon, 09 Jul 2018 13:29:28 +0200
Message-ID: <2130941.FryZTEcNbp@pintsize.usersys.redhat.com>
In-Reply-To: <CABcZeBOAamJ-agBeKObjVEM9w-MUV1nYtDctBc1iexmGta+gDg@mail.gmail.com>
References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com>
 <10346670.25GZR1XrEq@pintsize.usersys.redhat.com>
 <CABcZeBOAamJ-agBeKObjVEM9w-MUV1nYtDctBc1iexmGta+gDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart382788306.0sBPEuVBLf";
 micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fTZnapfETzeGUsEGqaz-X01SOe0>
Subject: Re: [TLS] Malformed Finished handling
Precedence: list

--nextPart382788306.0sBPEuVBLf
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 4 July 2018 18:54:10 CEST Eric Rescorla wrote:
> On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario <hkario@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.
> >=20
> > which language? the decode_error alert description literally says "leng=
th
> > of
> > the message was incorrect."
>=20
> The protocol definition language.

Sorry, I really don't see it. There are multiple references to "length" in =
the=20
draft, and as far as I can tell, all are quite consistent.
=20
> -Ekr
>=20
> > > That's why, for instance, NSS sends "illegal_parameter". So,
> > > absent specific text about this value, I think this is something we c=
an
> > > leave to the implementations.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > if the interpretation of "I know this _message_ _length_ is wrong becau=
se
> > of
> > some other values I negotiated before, so I'll send illegal_parameter" =
was
> > correct, then overflow_error, decrypt_error and probably few others wou=
ld
> > also
> > need to be replaced with illegal_parameter...
> >=20
> > > -Ekr
> > >=20
> > > On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario <hkario@redhat.com> wrot=
e:
> > > > Despite this, is it correct to terminate a connection with
> > > > "illegal_parameter"
> > > > upon receiving a Finished handshake message with a 100 byte payload?
> >=20
> > or a
> >=20
> > > > 20
> > > > byte payload? My opinion is that it is not, "decode_error" is more
> > > > specific so
> > > > it should be used instead.
> > > >=20
> > > >=20
> > > > Specification says the following on the matter:
> > > >=20
> > > > The draft 28 specifies the Finished message as having following
> >=20
> > structure:
> > > >       struct {
> > > >      =20
> > > >           opaque verify_data[Hash.length];
> > > >      =20
> > > >       } Finished;
> > > >=20
> > > > At multiple places it also talks about handling messages that have
> >=20
> > sizes
> >=20
> > > > that
> > > > don't match their structure as requiring termination of connection
> > > > with
> > > > "decode_error".
> > > >=20
> > > > 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" aler=
t.
> > > >=20
> > > > as description of the alert in Section 6.2:
> > > >    decode_error  A message could not be decoded because some field =
was
> > > >   =20
> > > >       out of the specified range or the length of the message was
> > > >       incorrect.  This alert is used for errors where the message d=
oes
> > > >       not conform to the formal protocol syntax.
> > > >=20
> > > > 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.
> > > >=20
> > > > 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.
> > > >=20
> > > > 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
> >=20
> > enum)
> >=20
> > > >    MUST terminate the connection with an "illegal_parameter" alert.
> > > >=20
> > > > Alert description in Section 6.2:
> > > >    illegal_parameter  A field in the handshake was incorrect or
> > > >   =20
> > > >       inconsistent with other fields.  This alert is used for errors
> > > >       which conform to the formal protocol syntax but are otherwise
> > > >       incorrect.
> > > >=20
> > > > (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=C5=88ova 115, 612 00  Brno, Czech Repub=
lic
> > > > _______________________________________________
> > > > TLS mailing list
> > > > TLS@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/tls
> >=20
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic


=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
--nextPart382788306.0sBPEuVBLf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltDRxgACgkQkqjRuAHS
9fVRHg//f3gk5QNafNPMfPbdcMgEfp0f5Smp/xIVxmEhABw26udIr7tYrYjL8xbh
MNrH9zufz9eapQVuK9M7MtBfqjrk4tiSwni62G9HBZHXvNhw/LWAzMzmGf24Nnd7
Qx4L+tNpPvh7eLczARPsDQzi3NzaJc4zH1auJDd62gV/mlvQ3TNXjOJpORyyeyiY
yRF5bz0QsmV2Pu84Loa8WcNYf/uWXTeESVVOFUGuV1DL9MDuaOIxrXooO9f/1Fjk
JRRExEGYyukWgh/pyd0Qv+4H+vmP0oYiW1xuwzjGMYCZzGPznjxy/Za+ESrqt1lc
6C3kH+S8VSSIh3/uord2Dk5xOhszh23iROY6C/yoozofAejNEuRWzzNo+RwGt1Xs
YoHLJNm5OL2+xdrQfQOT8NY3Fy69abgmHdxydyv1NOBpN1sGO0SnBGKljpORA/9W
8kQ+ALiW4ggEHva3rALKwKhLtp6dQDICqM2AJCljDRFKP+oCkGLj8XQkirrw+HKo
SCNqLLjQTjHQyHrxagAuELxHOaQDXovsnBU166FxyaxTqPJx+OnfmLxCtwek2A9t
rYwt4DIUAnwkZvlB3rcbbey9/NkT2eKfwp+fA5sw7ZRpJsQ0tgAXgknJB0KKInzc
do7eqG+qMgdUodwU2WpUZGOhdL01sy9QbA02aLLx4aTXFmNWVnI=
=yeQx
-----END PGP SIGNATURE-----

--nextPart382788306.0sBPEuVBLf--