Re: [TLS] Sending fatal alerts over TCP

Bodo Moeller <bmoeller@acm.org> Thu, 22 December 2011 13:34 UTC

Return-Path: <SRS0=ruXs=7C=acm.org=bmoeller@srs.kundenserver.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 79C0721F8AFE for <tls@ietfa.amsl.com>; Thu, 22 Dec 2011 05:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.231
X-Spam-Level:
X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 qM0WVxinaUGZ for <tls@ietfa.amsl.com>; Thu, 22 Dec 2011 05:34:52 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id A540221F86AA for <tls@ietf.org>; Thu, 22 Dec 2011 05:34:51 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LhThA-1QrPT723FI-00mjO4; Thu, 22 Dec 2011 14:34:49 +0100
Received: by qcsf15 with SMTP id f15so6155238qcs.31 for <tls@ietf.org>; Thu, 22 Dec 2011 05:34:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.77.134 with SMTP id g6mr4090023qck.125.1324560888446; Thu, 22 Dec 2011 05:34:48 -0800 (PST)
Received: by 10.224.19.196 with HTTP; Thu, 22 Dec 2011 05:34:48 -0800 (PST)
In-Reply-To: <E1Rda3N-0001mW-UJ@login01.fos.auckland.ac.nz>
References: <CADMpkcJ2P+AV4GJuXZRs4c_4f_xkQy2kivsrmqS0pBTmpZPD+g@mail.gmail.com> <E1Rda3N-0001mW-UJ@login01.fos.auckland.ac.nz>
Date: Thu, 22 Dec 2011 14:34:48 +0100
Message-ID: <CADMpkcKNraGkh61FLiFfcjM+M+V0Yos2YzYMS_G07jXyPumXfg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=00235433297e3d3e5304b4ae5dab
X-Provags-ID: V02:K0:NhQLIp5LYAEUUZcameoKMo5+t8+b3fs5s1q1LzIX2QB u//Yx5VAfHBC2XCswtw08b77IeBD+o/1i5AoWwbzBAiJrXAm0V oQMeRyxoYmcPlxdYYYMWtzT/44kHf7PZlw6k8UjfEHwHRtf2BA cdiSZa947UodIzYyP/dKCe/pSvU4YzZ7uJmmi3X1RKUwQXwGpn 7f6frO+9VD+5J/7dnuJ6bXErMqpzP5hfdLuDah0LP6dI1FBiJZ sWlISdDSIhbb88veiRnOLxpPcpZYqTIwWhrN7ScttDFcZpC/Bp It3PzXKqPyCOiUdfpyf+aJRlJ6zBPD89uSSsgVcx58yS2AYUy9 Ibz/8FK/5Oow8VuppTmQB1xq4vmeGluhwXWsoJEudQcLx/hHKF yIfSwmVClVYksDSzwDEN81amEd+um73GEsCIuhNS1hHEpkw2SC mmdRP
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 13:35:56 -0000

On Thu, Dec 22, 2011 at 5:14 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>wrote;wrote:

> Bodo Moeller <bmoeller@acm.org> writes:
>


> >[quoting RFC]
>


> For situations like this, in which the OP asked about dealing with
> real-world
> behaviour, you can't quote the TCP RFCs, you can't even quote the Berkely
> sockets specs or manpages, you have to look at what the actual
> implementation(s) do, because that often bears little or no resemblance to
> the
> specs.  That's not just because of bugs, it's because the implementations
> are
> based on extensive real-world experience and tuning (and, sometimes, de-
> tuning) which require slight... adaptations away from what the specs say.
>

Indeed.  However, I haven't quoted the RFCs to prove what real-world
implementation are doing -- I have looked at the RFCs to confirm that what
real-world implementations seem to be doing is, as far as relevant to this
discussion, not in violation of the RFC.