IETF Logo Mail Archive

Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix

"Steven M. Bellovin" <smb@cs.columbia.edu> Mon, 20 November 2006 23:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmILy-0005km-C2; Mon, 20 Nov 2006 18:15:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmILx-0005kg-3R for TLS@lists.ietf.org; Mon, 20 Nov 2006 18:15:05 -0500
Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmILv-0004BM-RH for TLS@lists.ietf.org; Mon, 20 Nov 2006 18:15:05 -0500
Received: by machshav.com (Postfix, from userid 512) id 51DD2FB2DD; Mon, 20 Nov 2006 23:14:51 +0000 (UTC)
Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D37F3FB2AC; Mon, 20 Nov 2006 23:14:49 +0000 (UTC)
Received: by berkshire.machshav.com (Postfix, from userid 54047) id CCAC03C0137; Mon, 20 Nov 2006 18:14:33 -0500 (EST)
Date: Mon, 20 Nov 2006 18:14:33 -0500
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Omirjan Batyrbaev <batyr@sympatico.ca>
Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix
Message-Id: <20061120181433.7fe164b0.smb@cs.columbia.edu>
In-Reply-To: <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa>
References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> <86lkm6rdau.fsf@delta.rtfm.com> <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa>
Organization: Columbia University
X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: TLS@lists.ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Mon, 20 Nov 2006 17:51:15 -0500, "Omirjan Batyrbaev"
<batyr@sympatico.ca> wrote:

> >The length
> > value is explicit in the record and is used to find the >record
> > boundary (recall that TCP has no explicit record >boundaries).
> 
> Slightly OT: when client/server writes the TLS fragment or/and messages the
> TCP then puts it in one TCP packet? So it becomes one TCP packet per one TLS
> fragment. Is this what happens in the real world implementations?

TCP offers no guarantees on that; you cannot predict what will happen.  It
can even change if TCP has to retransmit something.


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

v2.31.3 | Report a Bug | By Email | System Status