Re: [TLS] Comments on TLS identity protection

EKR <ekr@networkresonance.com> Sat, 30 December 2006 04:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VZf-0008Fk-NR; Fri, 29 Dec 2006 23:11:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VZe-0008Ff-JE for tls@ietf.org; Fri, 29 Dec 2006 23:11:58 -0500
Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0VZd-0006dE-AZ for tls@ietf.org; Fri, 29 Dec 2006 23:11:58 -0500
Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 25C961CC37; Fri, 29 Dec 2006 13:54:40 -0800 (PST)
To: home_pw@msn.com
Subject: Re: [TLS] Comments on TLS identity protection
In-reply-to: Your message of "Fri, 29 Dec 2006 09:52:43 PST." <BAY103-DAV14881C12253AFFE73420B992C60@phx.gbl>
X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19)
Date: Fri, 29 Dec 2006 13:54:40 -0800
From: EKR <ekr@networkresonance.com>
Message-Id: <20061229215440.25C961CC37@delta.rtfm.com>
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: tls@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

<home_pw@msn.com> wrote:
> TLS does indeed forbid the _negotiation_ of this defined
> ciphersuite. (This is
> why I phrased my claim in terms of SSLv3, which allows it.

Another way of looking at this is that it's a bug in the
SSLv3 spec that was fixed in TLS. Are you aware of any
implementation that in fact allows you to negotiate this
cipher suite?

> In SSLv3 one can choose to changeCipherSuite to a null encryption and
> null mac state, and merely use the fragmentation, sequencing and reassembly
> functions of the SSL protocol machine.

The what? SSL offers no capabilities here that are not offered
by the reliable transport it must ride on top of.

> (Nothing in SSLv3 states how the
> seq_num is calculated , note. It can be simple or fancy (provided it starts
> at zero, when the connection state is initialized or assigned).)

I don't have the v3 spec in front of me, but if that's true, it's
a bug in the spec, IMO.

-Ekr

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