Re: [TLS] Comments on TLS identity protection
EKR <ekr@networkresonance.com> Sat, 30 December 2006 05:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WlM-0000eP-N9; Sat, 30 Dec 2006 00:28:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WlL-0000eH-AA for tls@ietf.org; Sat, 30 Dec 2006 00:28:07 -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 1H0WlJ-0007Dt-Vg for tls@ietf.org; Sat, 30 Dec 2006 00:28:07 -0500
Received: by delta.rtfm.com (Postfix, from userid 1001) id C93061CC24; Fri, 29 Dec 2006 21:26:48 -0800 (PST)
To: home_pw@msn.com
Subject: Re: [TLS] Comments on TLS identity protection
References: <20061229215440.25C961CC37@delta.rtfm.com> <BAY103-DAV4BEA68112CED973F39D9592C50@phx.gbl>
From: EKR <ekr@networkresonance.com>
Date: Fri, 29 Dec 2006 21:26:48 -0800
In-Reply-To: <BAY103-DAV4BEA68112CED973F39D9592C50@phx.gbl> (home pw's message of "Fri, 29 Dec 2006 21:15:56 -0800")
Message-ID: <86ac166jjb.fsf@delta.rtfm.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
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> writes: >> >>> 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. > > Your missing my point. Obviously. > Im not putting SSL record layer over TCP.... My SSL application is not > https, it is > itself an SSL Connection, sending record_layer records data > over... record_types of > an currently active (underlying) TLS Connection. SSL requires that the transport over which it is carried be a reliable stream transport. For starters, it's implicit in the design of the crypto (the use of stream ciphers and CBC chaining between records). >>> (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. > > > Perhaps! > > "Each party maintains separate sequence numbers for transmitted and > received messages for each connection. When a party sends or receives > a change cipher spec message, the appropriate sequence number is set > to zero. Sequence numbers are of type uint64 and may not exceed > 264-1. " > > For TLS1.0, one may assume that increment means uint64++ (which seems > reasonable, when writing a > conformance/value/state checker) I believe that it is the consensus of pretty much all SSLv3 and TLS implementors that it means start at zero and increment by one for all versions of the spec. > FOr SSL3, > its changedfor any variant of the change cipher spec message. For TLS, its > the :first: message under "a particular connection state". If TLS Evidence > changes the notion of Connection state (which it seems to do, being an > extension of connection state machine), we now now have alerts setting > seq_num=0. The anti-replay guarantees of SSL/TLS (and the security guarantees if you have an IV that depends on record seq #) depend on the property that any given set of cryptographic keys may only be used once with a given record sequence number. Since the Evidence extensions do not change the cryptographic keys, they cannot allow the sequence number to be reset. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Comments on TLS identity protection Eric Rescorla
- Re: [TLS] Comments on TLS identity protection Eric Rescorla
- Re: [TLS] Comments on TLS identity protection Martin Rex
- Re: [TLS] Comments on TLS identity protection Martin Rex
- Re: [TLS] Comments on TLS identity protection badra
- Re: [TLS] Comments on TLS identity protection Eric Rescorla
- Re: [TLS] Comments on TLS identity protection Kyle Hamilton
- Re: [TLS] Comments on TLS identity protection Eric Rescorla
- Re: [TLS] Comments on TLS identity protection Martin Rex
- Re: [TLS] Comments on TLS identity protection badra
- RE: [TLS] Comments on TLS identity protection Peter Williams
- Re: [TLS] Comments on TLS identity protection Eric Rescorla
- RE: [TLS] Comments on TLS identity protection Peter Williams
- RE: [TLS] Comments on TLS identity protection Peter Williams
- Re: [TLS] Comments on TLS identity protection badra
- RE: [TLS] Comments on TLS identity protection Pasi.Eronen
- Re: [TLS] Comments on TLS identity protection badra
- RE: [TLS] Comments on TLS identity protection Pasi.Eronen
- Re: [TLS] Comments on TLS identity protection Bodo Moeller
- Re: [TLS] Comments on TLS identity protection badra
- RE: [TLS] Comments on TLS identity protection Pasi.Eronen
- Re: [TLS] Comments on TLS identity protection badra
- RE: [TLS] Comments on TLS identity protection Pasi.Eronen
- Re: [TLS] Comments on TLS identity protection Eric Rescorla
- RE: [TLS] Comments on TLS identity protection Peter Williams
- Re: [TLS] Comments on TLS identity protection badra
- Re: [TLS] Comments on TLS identity protection Eric Rescorla
- Re: [TLS] Comments on TLS identity protection badra
- Re: [TLS] Comments on TLS identity protection Martin Rex
- Re: [TLS] Comments on TLS identity protection Badra
- Re: [TLS] Comments on TLS identity protection Omirjan Batyrbaev
- Re: [TLS] Comments on TLS identity protection home_pw
- Re: [TLS] Comments on TLS identity protection home_pw
- Re: [TLS] Comments on TLS identity protection EKR
- Re: [TLS] Comments on TLS identity protection home_pw
- Re: [TLS] Comments on TLS identity protection home_pw
- Re: [TLS] Comments on TLS identity protection Martin Rex
- RE: [TLS] Comments on TLS identity protection Peter Williams
- Re: [TLS] Comments on TLS identity protection EKR
- Re: [TLS] Comments on TLS identity protection Martin Rex
- Re: [TLS] Comments on TLS identity protection home_pw
- Re: [TLS] Comments on TLS identity protection EKR
- Re: [TLS] Comments on TLS identity protection home_pw
- Re: [TLS] Comments on TLS identity protection EKR
- Re: [TLS] Comments on TLS identity protection home_pw