Re: [TLS] Sending fatal alerts over TCP

Florian Weimer <fweimer@bfk.de> Thu, 22 December 2011 15:03 UTC

Return-Path: <fweimer@bfk.de>
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 96DBB21F8AAA for <tls@ietfa.amsl.com>; Thu, 22 Dec 2011 07:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.516
X-Spam-Level:
X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1aND18nqd-1 for <tls@ietfa.amsl.com>; Thu, 22 Dec 2011 07:03:39 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 614A721F8A7D for <tls@ietf.org>; Thu, 22 Dec 2011 07:03:39 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RdkBF-0002W1-Sr; Thu, 22 Dec 2011 15:03:37 +0000
Received: by bfk.de with local id 1RdkBF-0002OJ-PQ; Thu, 22 Dec 2011 15:03:37 +0000
From: Florian Weimer <fweimer@bfk.de>
To: Bodo Moeller <bmoeller@acm.org>
References: <201112211939.pBLJdovn015672@fs4113.wdf.sap.corp> <4EF23BB2.600@extendedsubset.com> <CADMpkcLWduzn1Tn5Lc1SZ1bmuZ7qfeOvq2XVzze62m5oW4N3vQ@mail.gmail.com>
Date: Thu, 22 Dec 2011 15:03:37 +0000
In-Reply-To: <CADMpkcLWduzn1Tn5Lc1SZ1bmuZ7qfeOvq2XVzze62m5oW4N3vQ@mail.gmail.com> (Bodo Moeller's message of "Wed, 21 Dec 2011 21:28:32 +0100")
Message-ID: <82ipl8d4xi.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] Sending fatal alerts over TCP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 22 Dec 2011 15:03:43 -0000

* Bodo Moeller:

> Note that this only implies that Y's TCP needs to process the segment
> containing X's TLS alert before it can process the RST segment. Processing
> the segment with the alert merely means queuing it; the TLS layer would
> have to "RECEIVE" it from the TCP to do something with it.  If the RST
> segment gets processed before the TLS layer has received the TLS alert, the
> receiving queue will be flushed, and the alert will be gone.

Indeed, this is the correct explanation.

This flushing behavior was introduced that when you hit ^C in your FTP
client during a transfer, the transfer actually stops quickly, and does
not continue until the server has transmitted all data.  As a result, it
is impossible to tear down full-duplex connections without potential
data loss, unless the connection teardown is negotiated above the TCP
layer.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra├če 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99