Re: [TLS] Malformed Finished handling

Hubert Kario <> Mon, 09 July 2018 12:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34755130DC9 for <>; Mon, 9 Jul 2018 05:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YqvHSx4ag_IE for <>; Mon, 9 Jul 2018 05:12:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22D5A124C04 for <>; Mon, 9 Jul 2018 05:12:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 399F040250FF; Mon, 9 Jul 2018 11:27:26 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id EDDDE2026D65; Mon, 9 Jul 2018 11:27:24 +0000 (UTC)
From: Hubert Kario <>
To: "Salz, Rich" <>
Cc: Eric Rescorla <>, "<>" <>
Date: Mon, 09 Jul 2018 13:27:23 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2808641.ccO3BPbT5W"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Mon, 09 Jul 2018 11:27:26 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 ( []); Mon, 09 Jul 2018 11:27:26 +0000 (UTC) for IP:'' DOMAIN:'' HELO:'' FROM:'' RCPT:''
Archived-At: <>
Subject: Re: [TLS] Malformed Finished handling
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Jul 2018 12:12:21 -0000

On Wednesday, 4 July 2018 15:46:04 CEST Salz, Rich wrote:
> >    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...
> I think the rigorousness of error codes is not at the same level as the rest
> of the document.  I'm fine with that.  I can understand why people
> developing test suites are frustrated. 

It's not about developing test suites. It's about software the test suites are 
running against.

Inconsistent behaviour is usually a sign of a bug (I already had to deal with 
two security bugs, including one remote crash, that were/could have been found 
by verifying the sending of alerts and description of alerts), if not a 
security issue by itself (see ROBOT).

To reiterate: I'm not doing it because it brings me perverse pleasure or 
because I'm obsessive about details or because it makes writing test suites 
easier (it doesn't, that's why first tests I was writing didn't do that), I 
insist on specific, explicit and correct error handling
_because it finds bugs_ 

And I think we can all agree that a secure implementation of TLS needs not to 
have bugs. And we all primarily want to see such implementations, don't we?

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic