Re: [TLS] PR#625: Change alert requirements

Hubert Kario <> Thu, 15 September 2016 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 131B712B925 for <>; Thu, 15 Sep 2016 08:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.43
X-Spam-Status: No, score=-8.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1r0ylZ0OUXE4 for <>; Thu, 15 Sep 2016 08:37:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED8AD12B562 for <>; Thu, 15 Sep 2016 07:40:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68F16627C3; Thu, 15 Sep 2016 14:40:01 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u8FEe0gx003468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2016 10:40:01 -0400
From: Hubert Kario <>
Date: Thu, 15 Sep 2016 16:39:54 +0200
Message-ID: <>
User-Agent: KMail/5.2.3 (Linux/4.7.3-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2037707.HsNl7apBbd"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Thu, 15 Sep 2016 14:40:01 +0000 (UTC)
Archived-At: <>
Subject: Re: [TLS] PR#625: Change alert requirements
X-Mailman-Version: 2.1.17
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: Thu, 15 Sep 2016 15:37:51 -0000

On Friday, 9 September 2016 18:13:04 CEST Benjamin Kaduk wrote:
> I'm happy to make all alerts fatal.
> I also like the state in the pull requests where some cases require that
> if an alert is sent, it is a specific alert, while leaving flexibility
> in other cases (and preventing us from having to exhaustively enumerate
> all possible causes for alerts).

I have one scenario in which a the difference in alert type sent is actually 
quite crucial for properly testing an implementation.

Say you have a server that implements NPN. In case that extension is 
negotiated, client will send EncryptedExtensions between CCS and Finished, 
something that is a big no-no in standard TLS.

Now, if client misbehaves and sends the EncryptedExtensions despite NPN not 
being negotiated, server should respond with an unexpected_message alert. But 
if a server is expecting some message (by mistake) it won't match what it 
expects and by standard definition it should then send decode_error.

The end result of detailed specification is not only easier testing, but also 
higher confidence in test results.

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic