IETF Logo Mail Archive

Re: [TLS] Sending fatal alerts over TCP

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 22 December 2011 04:15 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
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 3399211E80EE for <tls@ietfa.amsl.com>; Wed, 21 Dec 2011 20:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Mbp1BYdh0dIF for <tls@ietfa.amsl.com>; Wed, 21 Dec 2011 20:14:59 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1111E8096 for <tls@ietf.org>; Wed, 21 Dec 2011 20:14:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1324527299; x=1356063299; h=from:to:subject:in-reply-to:message-id:date; bh=x2YB03PAtprl8ORB+k1FPc/TMSe7efdus3OjC+F32Wg=; b=OrtruOM2iGYMhZxUn7wWaD6KX/vNUPVbJSgwrFJk9W9ZZzsto4JN1x+v 6zCPL2BcFOhxzVSOVkJJhe/hwJD3tXLHOhefQ7ey6blnOIRqPQLABiSfF E/94/DKnubU0pJbGKHTivif2YNadp9v5TbbjfM8FpmONVFeO7B93vOjIg E=;
X-IronPort-AV: E=Sophos;i="4.71,391,1320577200"; d="scan'208";a="95749057"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Dec 2011 17:14:50 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Rda3N-0001mW-UJ; Thu, 22 Dec 2011 17:14:49 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: bmoeller@acm.org, tls@ietf.org
In-Reply-To: <CADMpkcJ2P+AV4GJuXZRs4c_4f_xkQy2kivsrmqS0pBTmpZPD+g@mail.gmail.com>
Message-Id: <E1Rda3N-0001mW-UJ@login01.fos.auckland.ac.nz>
Date: Thu, 22 Dec 2011 17:14:49 +1300
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 04:15:00 -0000

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.
Going from the TCP RFC is at best going to give you an abstract model of what
some implementations may do in certain circumstances, but it won't tell you
how to deal with real-world implementations and behaviour.

Peter.

v2.23.0 | Report a Bug | By Email