Re: [TLS] Suspicious behaviour of TLS server implementations

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 21 September 2016 16:12 UTC

Return-Path: <ilariliusvaara@welho.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 9339B12B57C for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 09:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] 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 myxzSp9eoM4X for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 09:12:47 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2812B569 for <tls@ietf.org>; Wed, 21 Sep 2016 09:12:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DCDAB12866 for <tls@ietf.org>; Wed, 21 Sep 2016 19:12:45 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id uvVmHeXpffUj for <tls@ietf.org>; Wed, 21 Sep 2016 19:12:42 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C1D06289 for <tls@ietf.org>; Wed, 21 Sep 2016 19:12:42 +0300 (EEST)
Date: Wed, 21 Sep 2016 19:12:39 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20160921161239.GA14446@LK-Perkele-V2.elisa-laajakaista.fi>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de> <20160909152901.9008C1A552@ld9781.wdf.sap.corp> <1473853106532.3256@cs.auckland.ac.nz> <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de> <57E25106020000AC0011BF3A@gwia2.rz.hs-offenburg.de> <CABkgnnX7X+21wjChxkW-uhd8WXAMyp5f1F74H5ja=1mui4POiQ@mail.gmail.com> <57E272CB020000AC0011BF63@gwia2.rz.hs-offenburg.de> <1474473207998.35647@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1474473207998.35647@cs.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pqdrtm9un1sVZq4tJvG0z3wELH8>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
X-BeenThere: tls@ietf.org
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." <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: Wed, 21 Sep 2016 16:12:49 -0000

On Wed, Sep 21, 2016 at 03:53:33PM +0000, Peter Gutmann wrote:
> Andreas Walz <andreas.walz@hs-offenburg.de> writes:
> 
>   Error: Couldn't connect to Amazon because <explanation for 
>          decoding_error alert>.
> 
> What would you put for the explanation for this case?  And if you say "decode
> error" the user's response will be to switch to some less buggy software that
> doesn't have problems connecting.

Well, valid response...
 
> If you're writing a strict validating protocol parser than disconnecting in
> this case is a valid response, but if it's software that will be used by
> actual humans then failing a connect based on something like this makes no
> sense.

decode_error only happens if either end is buggy (the receiver parsing
can also be buggy), or if data is corrupted in transport.

It is meant for errors where length of something is wrong (and such
errors would likely be non-recoverable anyway)..



-Ilari