Re: [TLS] Malformed Finished handling

Hubert Kario <hkario@redhat.com> Mon, 09 July 2018 12:12 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34755130DC9 for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 05:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqvHSx4ag_IE for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 05:12:19 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D5A124C04 for <tls@ietf.org>; Mon, 9 Jul 2018 05:12:19 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 399F040250FF; Mon, 9 Jul 2018 11:27:26 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id EDDDE2026D65; Mon, 9 Jul 2018 11:27:24 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "<tls@ietf.org>" <tls@ietf.org>
Date: Mon, 09 Jul 2018 13:27:23 +0200
Message-ID: <2272713.B1rdPjq6dU@pintsize.usersys.redhat.com>
In-Reply-To: <76911F76-2FF1-4EAB-8BEA-784B805184F2@akamai.com>
References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> <76911F76-2FF1-4EAB-8BEA-784B805184F2@akamai.com>
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 10.11.54.4
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 09 Jul 2018 11:27:26 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 09 Jul 2018 11:27:26 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nNIGF6fOZeBidIsVFfTKCcpN0_o>
Subject: Re: [TLS] Malformed Finished handling
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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?

-- 
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